Subject: [OAUTH-WG] Resource, Audience, and req_aud

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Feb 2019 15:24:43 +0000

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.

---

From: Filip Skokan <[email-masked]>
Date: Thu, 7 Feb 2019 16:37:53 +0100

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 <[email-masked]>
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.
>
>
>
>    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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 7 Feb 2019 10:57:47 -0500

+1 for rationalizing this! :)

On 2/7/19 10:24 AM, Hannes Tschofenig wrote:
> ace-oauth-params drafts I am wondering whether it is really necessary 
> to have different functionality in ACE vs. in OAuth for basic parameters.
>
>     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.
>     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
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Feb 2019 16:05:20 +0000

Since the authors of the token exchange draft have asked IANA for an early registration of the parameters I get the impression that the question is more “ does the resource indicator spec need to define the resource parameter (or rather reference the resource and audience parameters from the token exchange spec)”?

From: Filip Skokan <[email-masked]>
Sent: Donnerstag, 7. Februar 2019 16:38
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [OAUTH-WG] Resource, Audience, and req_aud

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
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.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Feb 2019 14:28:02 -0700

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 <[email-masked]> wrote:

> On Thu, 7 Feb 2019 at 16:25, Hannes Tschofenig <[email-masked]
> <[email-masked]>> wrote:
>
>> Hi all,
>>
>>
>>

-- 
_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._

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 9 Feb 2019 16:31:33 -0600

> 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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Feb 2019 06:07:03 -0700

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.