MSC4363: OAuth step up authentication#4363
MSC4363: OAuth step up authentication#4363Johennes wants to merge 10 commits intomatrix-org:mainfrom
Conversation
Johennes
changed the title
Signed-off-by: Johannes Marbach <[email protected]>
Johennes
force-pushed
the
johannes/oauth-step-up-authentication
branch
from
5769520 to
fd17d14
Compare
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (ideally multiple)
- Server
Signed-off-by: Johannes Marbach <[email protected]>
Signed-off-by: Johannes Marbach <[email protected]>
Signed-off-by: Johannes Marbach <[email protected]>
Signed-off-by: Johannes Marbach <[email protected]>
Signed-off-by: Johannes Marbach <[email protected]>
zecakeh
left a comment
zecakeh
left a comment
There was a problem hiding this comment.
Just a couple of nits on the wording.
Co-authored-by: Kévin Commaille <[email protected]>
Co-authored-by: Kévin Commaille <[email protected]>
Co-authored-by: Hugh Nimmo-Smith <[email protected]>
Signed-off-by: Johannes Marbach <[email protected]>
| ### Cross-signing key reset | ||
|
|
||
| Implementations MAY use this proposal to replace UIA when the client has obtained its access token | ||
| via the OAuth APIs. The only endpoint currently using UIA for which this is relevant is | ||
| [/_matrix/client/v3/keys/device_signing/upload]. |
There was a problem hiding this comment.
We could consider introducing a dedicated scope to support this. Though I think it is not strictly needed. The only advantage I can think of is that clients could request the scope ahead of hitting the endpoint.
|
|
||
| ### Cross-signing key reset | ||
|
|
||
| Implementations MAY use this proposal to replace UIA when the client has obtained its access token |
There was a problem hiding this comment.
Problem: when the homeserver receives a request to POST /_matrix/client/v3/keys/device_signing/upload, how does it know whether it should respond with the m.oauth flow stage from MSC4312, or the new M_INSUFFICIENT_USER_AUTHENTICATION errcode?
We would want the server to be backwards compatible with older clients, so I think the server needs to know what the client supports.
So, basically some kind of versioning:
- query param?
- body param?
/_matrix/client/v3/keys/device_signing/upload->/_matrix/client/v4/keys/device_signing/upload?
There was a problem hiding this comment.
There is also the possibility of returning both MSCs fields in the body of the response, since there are no conflicts with the keys.
A client that doesn't support this MSC should be able to handle the UIA fields, and a client that supports this MSC will prefer to handle these new fields.
4 participants
Rendered