Hi Kai, Some time ago we asked a similar question in this mailing list about a standard way to use the WWW-Authenticate header to indicate the requirement of 'authorization_details' to the client. If I remember correctly, the response was that when discussing this option while defining the RFC, it was noted that headers do not support JSON structures very well, which is true.
However, an idea that we had is to use JSON schemas to define the authorization details type, as suggested in section "11.3. Use of Machine-Readable Type Schemas" of RFC 9396. This means that the authorization detail types could be a URL (as in the 'Figure 4' example of RFC 9396) where you can publish the JSON schema. Knowing the authorization detail type, the client can resolve the URL to get the documentation about the JSON structure. By combining this solution with the Step Up Auth Challenge Protocol, you don't need to return a JSON structure in the 'WWW-Authenticate' header. Instead, you could include an additional parameter indicating the authorization detail type required, which is at the same time the schema that describes the structure of the JSON for the authorization request. As per RFC 9470, "Note that while this specification only defines usage of the above auth-params with the insufficient_user_authentication error code, it does not preclude future specifications or profiles from defining their usage with other error codes." You could extend the specification with custom error codes and parameters… Best regards. From: geo...@practicalidentity.com <geo...@practicalidentity.com> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann <kai.lehmann=401und1...@dmarc.ietf.org> Cc: oauth@ietf.org <oauth@ietf.org> Subject: [EXT][OAUTH-WG] Re: Combining Step Up Auth mechanism with RAR CAUTION: This message is from an EXTERNAL sender – be vigilant, particularly with links and attachments. If you suspect it, report it immediately using the phishing button. Hi Kai, I recently saw a proposal to extend the Step-Up mechanism by returning a body with the WWW-Authenticate header. This could work for what you are looking to do in returning a RAR authorization_details JSON object that the client can then pass to the AS. My only concern with this is whether most clients will know to look for a body with a WWW-Authenticate header and whether the browser will make the body available to a browser based client. I agree that Step-Up flows need more options than max_age, scope and acr_values. Thanks, George -- George Fletcher Practical Identity LLC On Mar 18, 2025, at 4:59 AM, Kai Lehmann <kai.lehmann=401und1...@dmarc.ietf.org> wrote: Hi, we are considering usign RAR to have a fine-grained authorization mechanism with additional user interactins during the authentication/authorization steps based on the authorization requested by the client. Our main concern is how the client would know when it needs access tokens with specific RAR content and when it can simply use standard scope based access tokens. We thought about using a similar method as is described in the Step Up Auth Challenge Protocol. When requesting a specific resource, a resource server could use this protocol to tell the client that it needs an access token with specific authorization_details which the client can then obtain before requesting the resource again. Another option would be to use something based on Protected Resource Metadata. However, here the Resource Server cannot craft a specific authorization_details it needs for a specific resource as it this usually depends on the request data which is not available at this point. Is there something defined to close this gap which we are just not aware of? Best regards, kai _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org Emails aren't always secure, and they may be intercepted or changed after they've been sent. Santander doesn't accept liability if this happens. If you think someone may have interfered with this email, please get in touch with the sender another way. This message doesn't create or change any contract. Santander doesn't accept responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored. If you've received this email by mistake, please let the sender know at once that it's gone to the wrong person and then destroy it without copying, using, or telling anyone about its contents. Santander UK plc. Registered Office: 2 Triton Square, Regent's Place, London, NW1 3AN, United Kingdom. Registered Number 2294747. Registered in England and Wales. https://www.santander.co.uk. Telephone 0800 389 7000. Calls may be recorded or monitored. Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Our Financial Services Register number is 106054. You can check this on the Financial Services Register by visiting the FCA’s website https://www.fca.org.uk/register. Santander and the flame logo are registered trademarks. Ref:[PDB#1-4B]
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
