[Query] Best approach to amend authorization_details

[VimukthiRajapaksha]

Hi,

The "Minimal Implementation Support" section[1] requires us to "merge requested and preexisting authorization details". Let's suppose that an authorization code grant flow goes like this:

1. A user has already authorized a client with a valid access token to access their basic profile information.
2. The client now wants to request access to the user's bank account details.
3. The client includes a new authorization details type in its authorization request to request the user's bank account details.
4. The authorization server merges the requested authorization details with the preexisting authorization details.
5. The authorization server then prompts the user to consent to the new permission to access their bank account details.
6. If the user consents, the authorization server will issue a new access token to the client that includes the permission to access the user's bank account details.

To complete the step 4, the authorization server needs to send a unique ID in the token response in step 1. The client must then include the same unique ID in the new authorization request mentioned in step 3 to refer the preexisting authorization details. Is this the intended approach, or is there a better way to amend authorization_details?

[1] https://datatracker.ietf.org/doc/html/rfc9396#section-11.2

Thanks,
Vimukthi

[tlodderstedt]

Hi,

in order to be able to merge and ask the user, the merge must happen during authorization request processing. There is no way in OAuth so far to let client identify the set if pre-existing permissions using a authorization request parameter. The AS may determine the pre-existing set of permissions based on the identifier of the authenticated user and the identifier of the requesting client.

There is a proposed extension for explicitely managing grants that is being specified at OpenID Foundation: https://openid.net/specs/oauth-v2-grant-management-ID1.html

hope that helps,
Torsten.

[VimukthiRajapaksha]

Hi Torsten,

Thank you for taking the time to respond and for providing the resources.

The RFC 9396 specification states that "merge requested and preexisting authorization details" as a minimum implementation requirement[1]. Let's assume that an authorization server supports concurrent grants[2]. In order to update those grants, does the AS have to support both RFC 9396 and "Grant Management for OAuth 2.0" specifications?

Additionally, could you please let us know when the "Grant Management for OAuth 2.0" RFC is expected to be published?

[1] https://datatracker.ietf.org/doc/html/rfc9396#name-minimal-implementation-supp
[2] https://openid.net/specs/fapi-grant-management-01.html#name-support-for-concurrent-gran

Thank you,
Vimukthi

[VimukthiRajapaksha]

Hi @tlodderstedt / Team,

Kind reminder

Thanks,
Vimukthi

[tlodderstedt]

RFC 9396 does not take a position on how the AS manages grants.
re Grant Management: I'm waiting for feedback from the FAPI WG on the current timeline for publication.

[VimukthiRajapaksha]

Hi @tlodderstedt,

I apologize if there has been a miscommunication.
In some cases such as concurrent grants, the AS needs to keep track of a unique ID to identify and update existing authorization_details. Is it possible to combine RFC 9396 with another specification, such as the "Grant Management for OAuth 2.0" specification, to maintain this unique ID? Are these scenarios supposed to be handled in this way?

Thank you,
Vimukthi

[tlodderstedt]

sure, you can combine RFC 9396 with grant management. We did the grant management spec to offer deployments a way to support explicit management of grants.

[dpostnikov]

Grant management was designed to enable fine grained authorisation requirements of open data ecosystems. Our primary use case required to combine it with the use of RAR (RFC9396). This is almost the same use case yours, described above @VimukthiRajapaksha.

Grant management is stable implementers draft now and waiting for implementations before moving towards final.