You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The identity server should authenticate the request in one of two ways:
The request is signed by the homeserver which controls the user_id.
The request includes the sid and client_secret parameters, as per /3pid/bind, which proves ownership of the 3PID.
Is this a second level of authentication, meaning that you still need an Identity Service API access token?
Also, concerning the first method of authentication: should the request be signed using the same scheme as the federation API? Or should it be as mentioned in the spec appendices?
The text was updated successfully, but these errors were encountered:
Frinksy
added
the
clarification
An area where the expected behaviour is understood, but the spec could do with being more explicit
label
Jun 16, 2021
Is this a second level of authentication, meaning that you still need an Identity Service API access token?
it looks like Sydent doesn't require an access_token for this endpoint (despite the swagger for the API saying it does). I'm not entirely sure if that means that it's Sydent or the spec that is wrong.
That bit of swagger was added in matrix-org/matrix-spec-proposals#2254, with reference to MSC2140. The MSC says "Any request to any endpoint within /_matrix/identity/v2 ... MAY return an error with M_UNAUTHORIZED errcode with HTTP status code 401. This indicates that the user must authenticate with OpenID and supply a valid access_token" (my emphasis). So perhaps it's intended to be implementation-specific.
Link to problem area:
https://matrix.org/docs/spec/identity_service/r0.3.0#post-matrix-identity-v2-3pid-unbind
Issue
The spec says:
Is this a second level of authentication, meaning that you still need an Identity Service API access token?
Also, concerning the first method of authentication: should the request be signed using the same scheme as the federation API? Or should it be as mentioned in the spec appendices?
The text was updated successfully, but these errors were encountered: