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 8 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 is an extension of the traditional Authorization Endpoint defined in [@!RFC6749], enabling complex authentication and authorization flows where interaction occurs directly with the Wallet rather than being intermediated by a browser. | ||
| 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. |
There was a problem hiding this comment.
I think the first section should mention that this profile is not a "first party" use case, but in the third party context.
There was a problem hiding this comment.
The profile should have a short summary of the additions/changes over vanilla FiPA:
- third party context
- adding interaction_types negotiation
- registering two interaction types: openID4VP & redirect_to_web
- allowing for custom interaction types
There was a problem hiding this comment.
| A primary use case is requiring the Presentation of a Credential as a prerequisite for issuing a new Credential. | |
| A primary use case is requiring the Presentation of a Credential as a prerequisite for issuing a new Credential. | |
| This profile introduces an interaction type negotiation mechanism and registers two initial interaction types: one enabling credential presentation, and another allowing the authorization flow to continue within a browser. This profile is also extensible, permitting the introduction of custom interaction types. | |
| Interactive Authorization typically involves a third-party scenario where the Wallet Provider and the Authorization Server are distinct entities. Consequently, the trust mechanisms specified in this specification and in [@!OpenID4VP] SHOULD be established to mitigate security and privacy risks. |
@paulbastian what about this?
| ### Interaction Required Response {#iae-interaction-required-response} | ||
|
|
||
| By setting `status` to `require_interaction` in the response, the Authorization Server requests an additional user interaction. | ||
| By setting `error_code` to `insufficient_authorization` in the response with HTTP response code 401 `Unauthorized`, the Authorization Server requests an additional user interaction. |
There was a problem hiding this comment.
HTTP 401 differs from FiPA
| By setting `error_code` to `insufficient_authorization` in the response with HTTP response code 401 `Unauthorized`, the Authorization Server requests an additional user interaction. | |
| By setting `error_code` to `insufficient_authorization` in the response with HTTP response code 400 `Bad Request`, the Authorization Server requests an additional user interaction. |
There was a problem hiding this comment.
wg call:
- http 401 could make sense to differentiate real errors (400) from insufficient authorization (401)
- should be raised to FiPA
There was a problem hiding this comment.
I would also prefer 401, as used in the example B.2 in FiPA
here the related FiPA issue, raised by @paulbastian
|
|
||
| ``` | ||
| HTTP/1.1 200 OK | ||
| HTTP/1.1 401 Unauthorized |
There was a problem hiding this comment.
| HTTP/1.1 401 Unauthorized | |
| HTTP/1.1 400 Bad Request |
|
|
||
| ``` | ||
| HTTP/1.1 200 OK | ||
| HTTP/1.1 401 Unauthorized |
There was a problem hiding this comment.
| HTTP/1.1 401 Unauthorized | |
| HTTP/1.1 400 Bad Request |
| | **endpoint** | `interactive_authorization_endpoint` parameter in AS Metadata | `authorization_challenge_endpoint` parameter in AS Metadata | | | ||
| | **requests** | (Initial and Follow-Up) Interactive Authorization Request | Authorization Challenge Request, Intermediate Requests are out of scope and must be defined by profile, `authorization_challenge_endpoint` can be reused) | How to specify intermediate requests? IAE distinguishes Follow-up by the presence of `auth_session`, whereas in FPA, `auth_session` can also be present in the initial request. | | ||
| | **responses** | Interaction Required Response, Authorization Code Response, Interactive Authorization Error Response | Authorization Code Response, Error Response (includes requests for more information) | | | ||
| | **scope** | implementation ready specification that defines two interaction types (`urn:openid:dcp:iae:openid4vp_presentation`, `urn:openid:dcp:iae:redirect_to_web`) | defines basic mechanics + `redirect_to_web` option. In order to successfully implement this specification, the Authorization Server will need to define its own specific profile |
There was a problem hiding this comment.
I'd like to recommend that redirect_to_web be renamed to method_via_web. This separates the behavior of this profile from the redirect_to_web behavior defined in FiPA as the two are semantically different.
There was a problem hiding this comment.
I agree. We should define "our own" version of redirect_to_web. Note that this table is more of an overview made as preparatory work.
In the actual text, the interaction type is currently named urn:openid:dcp:ia:redirect_to_web, but we might want to rename it to make the separation clearer.
There was a problem hiding this comment.
i have no strong opinion on whether to use urn:openid:dcp:ia:redirect_to_web or urn:openid:dcp:ia:method_via_web. If there was consensus/no objection during the call, I can gladly change it.
| #### Redirect to Web {#ia-redirect-to-web} | ||
|
|
||
| If the type is `urn:openid:dcp:iae:redirect_to_web`, the Authorization Server is indicating that the authorization process must continue via interactions with the user in a web browser. | ||
| If the type is `urn:openid:dcp:ia:redirect_to_web`, the Authorization Server is indicating that the authorization process must continue via interactions with the user in a web browser. This is used as a step in the interactive authorization process, while Section 5.2.2.1.1 of [@!I-D.ietf-oauth-first-party-apps] is a fallback to traditional authorization that replaces the entirety of the Interactive Authorization process. |
There was a problem hiding this comment.
@gffletch suggesting to change "redirect_to_web" to something else to make it more different from FiPA
Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> Co-authored-by: Paul Bastian <paul.bastian@posteo.de> Co-authored-by: Micha Kraus <7931215+mickrau@users.noreply.github.com>
|
Thank you for the feedback. I have resolved most of the suggestions. Aside from a few editorial todos, there are two open questions left to address:
|
I think yes, since people might forget about the URN prefix and think it's the same thing. A completely different name avoids confusion.
I think 401 makes more sense when considering the HTTP semantics. |
6 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.