Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud
Right, I was just trying to recount what had happened and say that it was my understanding that the URI registrations were the ones you'd expressed concern with and moved to early registration while the topic of this thread was about parameter names. I guess it doesn't really matter but it seemed like a distinction worth making when I wrote that last week. On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk wrote: > On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > > > The token-exchange draft defines both the "resource" and "audience" > > parameters for use in the context of a > > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to > the > > token endpoint. There is a lot of overlap between "resource" and > "audience" > > and I'm not sure there was necessarily a good reason to have the two but > it > > just kind of unfolded that way (the use of a client ID as an audience is > > one case that's mentioned that isn't a URI). That document is in IESG > > evaluation (which is towards the end of the RFC process) and had a few > > DISCUSS ballot positions raised against it. Resulting from one of those > > DISCUSSes, which was unrelated to "resource"/"audience" but rather > because > > of the OAuth URIs as far as I understand, one of the IESG members steered > > us in the direction of, and facilitated, the early registration requests. > > That was me. The conclusion to go for early registration was not (AFAICT) > out of a desire to get the actual value registered more quickly than it > would have been otherwise (which should be pretty fast, since IANA > generally makes the live registries reflect changes shortly after IESG > approval, not even waiting for AUTH48 or final RFC publication), but just > from it seeming to be the least-effort way to approve and publish the > document while still following the required process. (Basically, the I-D > sent to the IESG was "codepoint squatting", having text in the document > that claims that a specific URI value will be used, but with no guarantee > from IANA that that specific value will end up being the one registered. > I didn't think the IESG should grant its seal of approval to a document > that was jumping the process in that way, and the other options we could > think of would require fairly invasive changes to the text that would > just have to be undone by the RFC Editor.) > > -Ben > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud
On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote: > > The token-exchange draft defines both the "resource" and "audience" > parameters for use in the context of a > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the > token endpoint. There is a lot of overlap between "resource" and "audience" > and I'm not sure there was necessarily a good reason to have the two but it > just kind of unfolded that way (the use of a client ID as an audience is > one case that's mentioned that isn't a URI). That document is in IESG > evaluation (which is towards the end of the RFC process) and had a few > DISCUSS ballot positions raised against it. Resulting from one of those > DISCUSSes, which was unrelated to "resource"/"audience" but rather because > of the OAuth URIs as far as I understand, one of the IESG members steered > us in the direction of, and facilitated, the early registration requests. That was me. The conclusion to go for early registration was not (AFAICT) out of a desire to get the actual value registered more quickly than it would have been otherwise (which should be pretty fast, since IANA generally makes the live registries reflect changes shortly after IESG approval, not even waiting for AUTH48 or final RFC publication), but just from it seeming to be the least-effort way to approve and publish the document while still following the required process. (Basically, the I-D sent to the IESG was "codepoint squatting", having text in the document that claims that a specific URI value will be used, but with no guarantee from IANA that that specific value will end up being the one registered. I didn't think the IESG should grant its seal of approval to a document that was jumping the process in that way, and the other options we could think of would require fairly invasive changes to the text that would just have to be undone by the RFC Editor.) -Ben ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud
For better or worse there is a long and winding road that has led to where we are now with these parameters. And there has been plenty of misunderstanding, miscommunication, dysfunction, questionable decisions, and general SDO process along the way that/'s helped get to this point. I've certainly been a party to much of that so I'm not trying to point fingers here. And I'm not going to try and recount all that's happened - just the parts that (I think) are useful or relvent at this point. And really I'm just wanting to say that it has been pretty messy getting to the mess we have now. The token-exchange draft defines both the "resource" and "audience" parameters for use in the context of a "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to the token endpoint. There is a lot of overlap between "resource" and "audience" and I'm not sure there was necessarily a good reason to have the two but it just kind of unfolded that way (the use of a client ID as an audience is one case that's mentioned that isn't a URI). That document is in IESG evaluation (which is towards the end of the RFC process) and had a few DISCUSS ballot positions raised against it. Resulting from one of those DISCUSSes, which was unrelated to "resource"/"audience" but rather because of the OAuth URIs as far as I understand, one of the IESG members steered us in the direction of, and facilitated, the early registration requests. So token-exchange is currently requesting registration of (among other things) the "resource" and "audience" parameters at the token endpoint and the document describes their use only in the context of a token request with a "urn:ietf:params:oauth:grant-type:token-exchange" grant type. I strongly disagree with the idea, in theory or practice, that a parameter suddenly becomes meaningful and usable outside the context of its definition just by showing up in the registry. While the idea has been floating around for a long time, the actual resource-indicators draft as a WG item is considerably more recent than token-exchange. The resource-indicators draft defines the "resource" parameter as generally applicable for all requests to the token endpoint and the authorization endpoint. The meaning of "resource" in resource-indicators is consistent/compatible with the meaning in token-exchange but resource-indicators defines a broader more generalized usage of it. There's some TODO text in the IANA section that tries to capture that situation https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-4.1 and I was hopeful that the actual registration could be handled/updated to reflect the situation in a sane way. Recently the language in the resource-indicators draft was changed/softened a bit to clarify that the value of the "resource" parameter is a URI which can be an abstract identifier for the target resource and doesn't necessarily have to correspond to a network addressable location. I believe that's still very much compatible with it's usage and definition in token-exchange but it does, to Filip's point, shine some light on the question of the value of, or need for, the separate "audience" parameter at all. I'm less familiar with the happenings in ACE but there seems to have been some desire for a parameter that is somewhat similar. As far as I can tell, the intended usage has been for the token endpoint only. I believe it had the name "aud" at one point. It was pointed out that OAuth ran into conceptual problems with "aud" as a parameter name at the authorization endpoint because of a name conflict when used in conjunction with signed authorization requests made via redirection though the browser to the authorization endpoint with the likes of https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17 or https://openid.net/specs/openid-connect-core-1_0.html#RequestObject. Although the ACE "aud" parameter wasn't defined for the authorization endpoint AFAIK the name was changed to "req_aud" to avoid potential future collision and/or confusion (I think anyway). That's the state of things right now as best I understand and can articulate. So where does that leave us? My preference (I think anyway after thinking about it for hours while writing this email) would be to remove the "audience" parameter from token-exchange. And to have token-exchange defer to resource-indicators for the core definition and registration of the "resource" parameter while just having text describing how it's used in the token-exchange context for ease of reading and understanding. A URN scheme could be prescribed in token-exchange for how to convey a client ID in a URI (something like "urn:ietf:params:oauth:client_id:" using the subnamespace procured by RFC 6755). ACE could also reference resource-indicators and utilize the "resource" parameter rather than "req_aud" - to do so it seems it would also need to provide guidance or definition on how to place arbitrary string values into a URI. Regardless of
Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud
+1 for rationalizing this! :) On 2/7/19 10:24 AM, Hannes Tschofenig wrote: Hi all, after re-reading token exchange, the resource indicator, and the ace-oauth-params drafts I am wondering whether it is really necessary to have different functionality in ACE vs. in OAuth for basic parameters. Imagine I use an Authorization Server and I support devices that use CoAP and HTTP. 1. If a device uses CoAP then it has to use the req_aud parameter to indicate to the authorization server that it wants to talk to a specific resource server. It would either put a URI or a logical name there. 2. If a device uses HTTP then it has to use either the resource parameter to indicate to the authorization server that it wants to talk to a resource server, which is identified using a URI, or the audience parameter, if it uses a logical name. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
