Building Interactive Authorization on top of first party apps draft#736
Building Interactive Authorization on top of first party apps draft#736mickrau wants to merge 6 commits into
Conversation
fkj
left a comment
fkj
left a comment
There was a problem hiding this comment.
Generally I think this is really nice! It does not feel like a hack, but quite natural. I also think it reads pretty well. I've added a lot of nits and some points for discussion.
@mickrau It would be great if you could take a look and merge the ones you agree with/discard the ones you don't. Sorry it took me so long to review this!
Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>
| This section defines a profile for the OAuth 2.0 for First-Party Applications specification [@!I-D.ietf-oauth-first-party-apps], enabling complex authentication and authorization flows where interaction occurs directly with the Wallet rather than being intermediated by a browser. | ||
| A primary use case is requiring the Presentation of a Credential as a prerequisite for issuing a new Credential. | ||
| Support for the Interactive Authorization Endpoint is OPTIONAL. | ||
| Support for this profile is OPTIONAL. |
There was a problem hiding this comment.
We probably need to add some text about whether Issuers can support First-Party Application profiles outside of this one, particularly as we are using publishing the authorization_challenge_endpoint as the means of demonstrating support.
So adding something like 'Issuers that support First-Party Applications specifications MUST use this profile' (my preference) OR add an issuer metadata independent to the endpoint to indicate support for this profile (i.e supports_interactive_authorization boolean).
There was a problem hiding this comment.
Good point, though it's not clear to me how supporting additional profiles could break anything (unless the other profile e.g. makes something required that is normally optional). The negotiation of interaction types should prevent any issues with supporting other things on the same server that wallets can't use.
Are there other things that might conflict?
3 participants
rough draft for further discussion.
Changes (among others):
status= (require_interaction|ok) and use (HTTP 401 witherror:insufficient_authorization) and (HTTP 200 +authorization_code) insteadI kept the order of the sections so that you can see at a glance what has changed.