I also agree that scope, max_age, and acr_values are insufficiently expressive to cover all cases that arise in practice. I think we need something more freeform like the ability for the AS or RS to provide an arbitrary set of query parameters to pass to the authorization endpoint (or maybe just a single encoded parameter like authorization_state). I also think this should be supported on token endpoint calls. (Why should the AS issue an access token if it already knows the token cannot be used?)
Nick On Wed, Mar 19, 2025 at 3:17 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 <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 > --
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
