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
