Thanks for the context, Dick. Given that, I agree that the majority of my suggestions aren't in scope for 2.1. I do think that refresh_token_expires_in is worthy of continued discussion for 2.1, however, given that 2.1 introduces a mandate for either RT rotation or binding for public clients. refresh_token_expires_in can be directly related to rotation. However, I can continue that discussion on the github thread <https://github.com/oauth-wg/oauth-v2-1/issues/187#issuecomment-2350781735> that Warren linked.
Rifaat: I will be attending IETF 122 in person, and I would definitely be interested in a session on possible inclusions for a hypothetical 2.2 spec or standalone extensions. Given that I have no prior experience writing specs, I'm not sure I'd be able to draft something presentable. Nick On Thu, Jan 30, 2025 at 8:19 AM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote: > Hi Nick, > > +1 to what Dick stated below. > > The best way forward is for you to write a draft, present and discuss it > during one of the coming IETF meetings. > The next meeting is IETF122 in Bangkok; if you cannot attend in person, > you can present remotely. > https://www.ietf.org/meeting/122/ > > Regards, > Rifaat > > > On Thu, Jan 30, 2025 at 11:08 AM Dick Hardt <dick.ha...@gmail.com> wrote: > >> Nick: Thanks for providing your feedback. This is the perfect medium for >> discussions on IETF standards. >> >> A condition in the working group in agreeing to work on OAuth 2.1 was >> that it did not introduce anything new -- it was to capture and condense >> the collection of published OAuth 2.0 related documents so that >> implementers had a single core reference that did not have outdated >> information. >> >> Given that, we won't be able to include them in OAuth 2.1. While the >> suggestion to file the issues on GitHub by Warren is well intended -- we >> are only working on improving the draft language to provide better clarity >> -- not on normative changes that are not already specified >> >> I'm sure that your suggestions are reasonable and are based on your >> operating experience and are worthy of discussion. >> >> I'm not sure what the best path forward is for your suggestions -- >> typically it would be a draft that would provide normative language, and >> the additional codes would be added to the appropriate IANA registries, >> which are referenced in OAuth 2.1 >> >> /Dick >> >> >> >> On Thu, Jan 30, 2025 at 10:39 AM Warren Parad <wparad= >> 40rhosys...@dmarc.ietf.org> wrote: >> >>> Rather than trying to hash each of these out here over email, which is a >>> poor mechanism for it, I would recommend commenting on the github repo with >>> exactly the problem, eg "the user story" that encourages the need for >>> having each of these. However I would caution right now the stories you are >>> providing aren't strong. Additionally this is 2.1 no OAuth 3.0, it's >>> semantic for a reason, the focus is on security improvements. So I might >>> recommend, out of the ones you've provided, focusing on only the top one or >>> two most critically important for you in your current situation that have >>> real security implications or currently impossibly challenging problems for >>> RS/Users/Clients <https://rs.corp.google.com/Users/Clients>. >>> >>> Just as a for example: >>> >>>> but it allows them to optimize the experience in the happy path (token >>>> expires when stated). >>> >>> >>> So what? Why does it matter? "better optimize" How exactly? What's the >>> alternative? If Google and Microsoft want to expose potential privacy data >>> for unauthenticated users, they definitely can, but I will personally die >>> on this hill. Until the user is authenticated, exposing any data regarding >>> the user could not be more wrong. If AS still want to do it, nothing is >>> stopping them, but we shouldn't add nonsense to a standard that will cause >>> people who follow it to be—more confused and less secure. >>> >>> Concrete examples go a long way to fruitful discussion otherwise the >>> discussion is only academic and lacks any real impact. >>> >>> On Thu, Jan 30, 2025 at 12:32 AM Nick Watson <nwatson= >>> 40google....@dmarc.ietf.org> wrote: >>> >>>> For refresh_token_expires_in, the argument seems to hinge on the idea >>>> that "client can't do anything useful with the knowledge of the refresh >>>> token expiration time". But that isn't the case, as we have received >>>> several requests from clients to expose this information so that the client >>>> can remind the user to do a renewal/reconsent ahead of time to prevent >>>> disruption of service. It's not to say that the client is off the hook from >>>> handling expired tokens, but it allows them to optimize the experience in >>>> the happy path (token expires when stated). >>>> >>>> For 3.2.4 access_denied, yes it would be a 403 for AS-initiated >>>> denials, but there's no corresponding spec-defined error code for it. Given >>>> that access_denied is already defined for authorization response for AS or >>>> user denials, it provides parity with that. >>>> >>>> For 3.2.4 additional error code, the only thing I had in mind is that >>>> some RPs pop something up to the user asking them to reconsider granting >>>> access, if denied. An AS-initiated error signal would indicate that >>>> wouldn't help. I don't feel that strongly about this one, though. Curious >>>> to hear if anyone else has use cases. >>>> >>>> display_uri - I had it in mind entirely for things that the user should >>>> see and/or do, so the AS isn't conveying any instructions to the RP beyond >>>> "please open this URL if possible so the user can see it". Reauth and >>>> richer errors were the two things I thought of; other people may have >>>> other use cases. If we wanted to support a real recovery flow, then that >>>> would certainly need more details for RP-AS communication. >>>> >>>> For scope in 4.1.2, I do think it's very useful to at least define this >>>> parameter here, even if with MAY. RPs could, for example, tell the user >>>> which features will be disabled given their choices, and give them an >>>> option to redo consent. (I don't think that's malicious or pleading.) It >>>> will also be useful during the transition phase from 2.0 to 2.1 for >>>> authorization servers that still support the implicit flow for backwards >>>> compatibility reasons. >>>> >>>> Nick >>>> >>>> On Wed, Jan 29, 2025 at 2:37 PM Warren Parad <wparad= >>>> 40rhosys...@dmarc.ietf.org> wrote: >>>> >>>>> For the 3.2.3 Token Response, I believe it is quite clear why that >>>>> should be rejected via this great response from Aaron: >>>>> https://github.com/oauth-wg/oauth-v2-1/issues/187#issuecomment-2350781735 >>>>> >>>>> For 3.2.4 access_denied, I believe the current solution is a 401 or >>>>> 403 status code, isn't it? Adding error codes to that response is a bit >>>>> unnecessary, I would say. >>>>> >>>>> For 3.2.4 additional error codes don't seem appropriate as the client >>>>> can't do anything different; this just requires forcing them to explicitly >>>>> handle each of these. Less error codes are better unless there is a >>>>> specific different flow we expect the client to go through. Do you believe >>>>> there is a user relevant flow that would be different based on the >>>>> different error codes? >>>>> >>>>> I like the 3.2.4 display_uri concept, but it is rife with two problems >>>>> in practice: >>>>> >>>>> - The solution is usually for an owner of the client to do >>>>> something related to the AS, not the user who receives the error, so it >>>>> doesn't do any good returning it, AND it is often exposing something >>>>> about >>>>> the flow to the user that shouldn't be exposed. >>>>> - The actual instructions that might need to be conveyed are more >>>>> complex than just a single parameter. Right now this information would >>>>> be >>>>> included in the error_description is valuable, I don't see automation >>>>> being >>>>> able to do anything clever if this was exposed differently, do you? >>>>> >>>>> For the 4.1.2 The authorization response is just a *code* and not >>>>> complete, focing authorization servers to unnecessarily look up this >>>>> information doesn't make sense. It could be MAY at best for me. Did you >>>>> mean to add this to the 3.2.3 Token Response, and it is already exactly >>>>> defined like this: >>>>> >>>>> RECOMMENDED, if identical to the scope requested by the client; >>>>>> otherwise, REQUIRED. The scope of the access token as described by >>>>>> Section >>>>>> 1.4.1. >>>>> >>>>> >>>>> If you did intend for it to be added to the 4.1.2 I'm going to have >>>>> to hard disagree, this is exposing information at a time before it is >>>>> absolutely necessary. The Token doesn't exist before here, so there is >>>>> nothing the client could do anyway. Is there a reason you would see >>>>> absolutely needing to know this information before the auth_code flow is >>>>> complete? Surely even if the user rejected some scopes, you still want to >>>>> complete the flow and capture the access_token and refresh_token that the >>>>> AS is going to generate, right? That feels like a better moment to direct >>>>> the user through some other flow. However even if we embrace the idea of >>>>> returning the scopes on the redirect back in the authorization response, I >>>>> can't see what a client would do. The only thing they could attempt to do >>>>> is plead with the user to accept those scopes. That's a pretty malicious >>>>> thing to do, the user already rejected those scopes, forcing them through >>>>> the exact same flow again is not something that makes sense, at least to >>>>> me, but it isn't the case that this should be SHOULD let alone MUST. >>>>> >>>>> I hope each of my concerns are clear, but I'm happy to try to explain >>>>> any of them in more detail. >>>>> >>>>> - Warren >>>>> >>>>> On Wed, Jan 29, 2025 at 11:13 PM Nick Watson <nwatson= >>>>> 40google....@dmarc.ietf.org> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am new to IETF so apologies if I'm not doing this correctly. I had >>>>>> a few suggestions for things to add to the 2.1 spec based on scenarios >>>>>> encountered from running a large authorization server. Let me know your >>>>>> thoughts or if I should be using a different channel (like github) to >>>>>> contribute issues/suggestions. >>>>>> >>>>>> -- >>>>>> >>>>>> In “3.2.3. Token Response”, I think it’s worth defining a refresh >>>>>> token expiration parameter. This could be useful both for refresh token >>>>>> rotation (as discussed in section 4.3.1.) as well as supporting user >>>>>> selection of shorter-lived access. A quick search suggests that there’s >>>>>> some existing usage of refresh_token_expires_in as a parameter name >>>>>> (Microsoft, GitHub). >>>>>> >>>>>> In “3.2.4. Error Response”, it would be worth adding access_denied as >>>>>> a valid error code here for cases where the authorization server denies >>>>>> the >>>>>> request. (For example, an enterprise user granted access in the past, but >>>>>> their admin has since disabled the client or scope for their org.) >>>>>> >>>>>> In “3.2.4. Error Response” and “4.1.2.1. Error Response”, is it worth >>>>>> adding another error code like access_denied_by_authorization_server (bad >>>>>> name, I know) for cases where the authorization server feels it’s useful >>>>>> and appropriate to distinguish between resource owner denial and >>>>>> authorization server denial? This may not be needed as authorization >>>>>> servers are already free to define their own error code extensions, but a >>>>>> single umbrella error code could be useful for simpler implementations. >>>>>> >>>>>> In “3.2.4. Error Response” (and maybe also 5.3.1), it would be useful >>>>>> to have some sort of “display_uri” parameter that the authorization >>>>>> server >>>>>> can provide for RPs to open in a browser if they are able. This >>>>>> display_uri >>>>>> could be used to show a richer error to the resource owner or even be >>>>>> used >>>>>> for recovery (e.g. reauth). We could also try to spec out what a >>>>>> full-blown >>>>>> token endpoint-initiated recovery flow might look like. >>>>>> >>>>>> In “4.1.2. Authorization Response”, I think we should say that the >>>>>> authorization server MUST return a scope parameter if the RP included >>>>>> scope >>>>>> in the request and the granted scopes differ from the requested scopes. >>>>>> This allows RPs to be informed if the resource owner only grants partial >>>>>> consent. >>>>>> >>>>>> - Nick Watson >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>> 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 >> > -- Nick Watson | Software Engineer | nwat...@google.com | (781) 608-3352
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
