Nick, As Dick indicated below, get a slide deck ready with your ideas, and Hannes and I will make sure to allocate some time during one the OAuth WG sessions to discuss this.
Regards, Rifaat On Sat, Feb 1, 2025 at 6:11 AM Dick Hardt <dick.ha...@gmail.com> wrote: > Hey Nick, note that 2.1 does not introduce the mandate, it is in the OAuth > Security BCP. > > While I agree that a refresh token expiry is handy, an AS can expire both > a refresh token and an access token at any time. It is only an upper bound, > just like the access token expiry. > > If you will be at IETF 122, you could just create some slides explaining > each of your proposals, and use that as a basis for gathering interest from > the WG to work on the proposals. As to drafting a spec, I have confidence > you would be fine! > > /Dick > > On Sat, Feb 1, 2025 at 12:33 AM Nick Watson <nwat...@google.com> wrote: > >> 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
