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:<value>" 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 keeping the "audience" parameter or not, it would seem to make some sense to have token-exchange defer to resource-indicators for the core definition and registration of the "resource" parameter. But the drafts are at different stages in the process (in the wrong order) and I'm way out of my depth in understanding what can and can't be done with references to documents that aren't as far along towards being RFC. I'm not even sure how much change is possible/allowed to token-exchange at this point, given that it's almost done. An alternative is to leave "resource" and "audience" in token-exchange and have it do the registrations. Then have resource-indicators expand the "resource" registration to add "authorization request" as a usage location (and maybe update the additional context of use too). ACE could use "audience" rather than "req_aud" and further define it for general use and do a similar kind of expanded registration request for "audience" to account for its more generalized definition. There are, of course, other alternatives too. But that's more than enough typing from me for the time being. On Thu, Feb 7, 2019 at 8:38 AM Filip Skokan <panva...@gmail.com> wrote: > To add to that, > > 3. If a device uses HTTP Token Exchange it can use both resource and > audience parameters. > > With the recent discussion and changes to the language in the resource > indicators draft, does the token exchange spec need a unique audience > parameter? > > S pozdravem, > *Filip Skokan* > > > On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig <hannes..tschofe...@arm.com > <hannes.tschofe...@arm.com>> 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. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- _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
