Hi Kai, Sorry, I think I didn’t fully understand your point at the beginning. What you mean is that the resource server would return the complete `authorization_details` parameter already filled in the WWW-Authenticate header, right?
If that’s the case, I see two issues here... The first one is the limited use cases that can support this, for me, filling the `authorization_details` in the resource server seems too challenging for complex authorizations (the reason for `authorization_details` existence :-)). For instance, in cases like payment processing, the resource server would not know the amount to be paid or the account to be used… This should be filled in on the Client/TPP side when composing the authorization request and asking the customer. The second issue is about sensitive information exposure. If the resource server returns the complete `authorization_details`, there’s a risk of leaking sensitive data. Maybe some malicious client will use this to try to find information about users by abusing unauthorized requests to the resource server. Best regards, From: Kai Lehmann <kai.lehm...@1und1.de> Date: Thursday, 20 March 2025 at 13:16 To: Oliva Fernandez, Jorge <jorge.olivafernan...@santander.co.uk>, Justin Richer <jric...@mit.edu> Cc: oauth@ietf.org <oauth@ietf.org> Subject: [EXT]Re: [OAUTH-WG] 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, from what I understood from the answers, I don’t think that the RS returning a type and the client constructing the authorization_details based on that type and a JSON schema would help in our case. While JSON schema might help in validating the authorization_details type, the client would still need to know what values to insert where in the authorization_details. So with every new RS endpoint introducing requirements for RAR (including new types), the clients would need to be updated. This is something we would like to avoid and that’s why we opt for returning the authorization_details content in its entirety by the RS to be passed along to the AS by the client. It was mentioned that providing JSON objects do not work well as authentication parameters in the HTTP response header and I agree. A base64url encoded JSON would work, though it would require the client to decode this data when crafting the authorization request or if simply passed along, the AS would need to detect the base64 encoding and decode the data itself (second option, however, is not a proper RAR request). Kai From: Oliva Fernandez, Jorge <jorge.olivafernan...@santander.co.uk> Date: Thursday, 20. March 2025 at 13:37 To: Justin Richer <jric...@mit.edu> Cc: Kai Lehmann <kai.lehm...@1und1.de>, oauth@ietf.org <oauth@ietf.org> Subject: Re: [OAUTH-WG] Combining Step Up Auth mechanism with RAR Hi Justin, Thanks for your insights! I see your point and I’m also agree about the challenges of relying on fetchable JSON schema URLs for defining authorization_details types. I understand that using URLs for schemas has challenges, like clients not supporting dynamic fetching or knowing when to treat a type value as a URL, but removing schema-based URLs doesn’t remove the need for coordination, I mean, even with arbitrary string values for type, authorization servers, resource servers, and clients still need a shared way to document and interpret them, or am I missing something in the specification? (Wouldn’t be the first time!) So, while avoiding URLs as type values prevents some of the concerns you raised, it doesn’t solve the fundamental issue, some form of negotiation or specification is still required to ensure interoperability. Whether that’s done through well-defined profiles, standardized type registries, or another approach, the need for a common understanding remains… and as part of this common understanding between AS, RS, and client, it could be included that authorization details types are just URLs that contain the JSON schema, in my opinion. Curious to hear your thoughts on possible ways to address this challenges for implementer other than use URL schemas. Best Regrads. From: Justin Richer <jric...@mit.edu> Date: Thursday, 20 March 2025 at 09:24 To: Oliva Fernandez, Jorge <jorge.olivafernan...@santander.co.uk> Cc: Kai Lehmann <kai.lehm...@1und1.de>, oauth@ietf.org <oauth@ietf.org> Subject: [EXT]Re: [OAUTH-WG] 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. In working on RAR, it was discussed whether to use a URL fetch in the way you’re describing to pass schema data between parties, but that was deliberately cut out. In RFC9396, the `type` value is a string that’s used for disambiguation of the structure of the rest of the object - there are no semantics or additional processing expected. It’s allowed that this have some other layer of meaning, and we talk about it in section 11.3: https://www.rfc-editor.org/rfc/rfc9396.html#name-use-of-machine-readable-typ But, and it’s a pretty big one, you can’t assume that anyone’s going to DO anything with that `type` value without another layer of specification and profiles defining that. And when you do, you need to be careful how that kind of behavior fits in with the larger ecosystem that does NOT assume that kind of structure or behavior. So for example you’ve got a server setup that uses fetchable JSON schema URLs as the `type` value, what happens when you connect with a client who doesn’t know how to process that? Is there some simpler behavior that such a client could possibly do? Or, even more concretely, something that a more statically-configured and less dynamic client could make sense of? You look at the JSON schema world and its relatives (like JSON LD) out in the wild, and a ton of perfectly-working systems fully ignore all the "go fetch the schema dynamically" part, with varying results. A harder question is, what if your AS/RS does NOT use a fetchable JSON schema URL as a `type` value but you’ve got a client that can process those. Does it try to fetch every `type` value as if it’s a URL, or just ones that start with http? What if there’s a `type` value that’s an HTTP URL but isn’t fetchable, it’s just a namespace as recommended by the RFC? Plus there are the security and privacy considerations that pop up any time you have a system that hands a component a URL that it’s supposed to go resolve. All of this isn’t to say that you can’t do it, or even shouldn’t, but that layering this kind of functionality in would need to be done very carefully with well-defined guard rails or else things could fall over sideways pretty quickly. — Justin On Mar 19, 2025, at 3:16 AM, Oliva Fernandez, Jorge <Jorge.OlivaFernandez=40santander.co...@dmarc.ietf.org> wrote: 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<mailto:geo...@practicalidentity.com> <geo...@practicalidentity.com<mailto:geo...@practicalidentity.com>> Date: Tuesday, 18 March 2025 at 12:17 To: Kai Lehmann <kai.lehmann=401und1...@dmarc.ietf.org<mailto:kai.lehmann=401und1...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> <oauth@ietf.org<mailto: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<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<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto: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] 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
