Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud

Brian Campbell <> Thu, 07 February 2019 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4094A129C6A for <>; Thu, 7 Feb 2019 13:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4n0pSJNtQH7j for <>; Thu, 7 Feb 2019 13:28:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85770129A87 for <>; Thu, 7 Feb 2019 13:28:30 -0800 (PST)
Received: by with SMTP id a6so3665042itl.4 for <>; Thu, 07 Feb 2019 13:28:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9JgyolgrytpShL8YvUvaBeFAg8iNTemmVj5Cl16YTfk=; b=QGxwj9zfAOUH9ObSOtc5pTch/2VTQ1tovlv/wPI1/m5u1WFwwEiWOH1JHFnusRHfNd prnIJWtL8QZroitAoxloWzWZueQ/t+yNRenUf/wigZXcTr4GvekOhvppi5oYcztDP8/D 35fe/r39B9ZemJJXuhOPKnrUwcszD6h0sHVFM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9JgyolgrytpShL8YvUvaBeFAg8iNTemmVj5Cl16YTfk=; b=DXqN9HJI6i/2C2DtDD8FYHXHdk6rFr5dZZZ+78twguJ5UutY5uMyO6DNoeCHXywxoQ drZ9htO5UKjir5WQQod//6+CSg1RrRRkNGwxF+5GOl5D3M2Bq82XuyLI/OaJRWl/FEHu aBe07HxR6Tlr84CJkRLv1frKAii8/xqKN+E7qlipTeIlDJZQP3n/sU98oesiffl62OUO LDRQ8CoYJTNSQWJ/1vr8ktoYlRZxhqyU3jewqeyMg1hQQnfAJUfj1IfbUUFDj3t0ozBa Eb+YU/etMO19ZwC5t4b3AX4P6m6isSM6Vx10QdEaHybUlSQyOrLlzFOjENLMLJBgNPpU A0+g==
X-Gm-Message-State: AHQUAuart49TZbbPU9lUucajk6jW2DkVe3VwPDlxk17+jyLkOMkrrDa5 mX9Lvvan62BJwE12kcpmcVe33BvQ+bGVfQePlkHBSOYcRdCVqu49OhbZ16hQoeeCQQGvIf0q1EK /FDmb4j0wjKY=
X-Google-Smtp-Source: AHgI3IYWmN9ZwU61nwa81ZQiTIDr8ryzhLXrlDVsxwBfS5uDyREq6VDd60T9c0Va9d+EHtXvlZloA41ByQY0gGUTXv4=
X-Received: by 2002:a5d:8597:: with SMTP id f23mr10866259ioj.238.1549574909542; Thu, 07 Feb 2019 13:28:29 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Thu, 7 Feb 2019 14:28:02 -0700
Message-ID: <>
To: Filip Skokan <>, Benjamin Kaduk <>, Eric Rescorla <>
Cc: Hannes Tschofenig <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000096edf05815486ca"
Archived-At: <>
Subject: Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Feb 2019 21:28:33 -0000

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

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 or
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 <> 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 <
> <>> 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
> _______________________________________________
> Ace mailing list

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