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. >> >> 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
