Then I think we have a bigger issue:(
To me the point of the "resource-indicators" spec is to define semantics
around how a client can request that tokens be "constrained" in where
they can be used. If it is not going to define the actual 'resource'
parameter and rather use the registered value from the token-exchange
spec, then it seems like the resource-indicators spec has the wrong
title. Instead it should be about "constraining where a token can be
used" and in that view should describe how to use either the 'audience'
or 'resource' parameter. I believe we need clear guidance for when to
use one over the other (if possible).
It is then left up to the AS to determine whether it is going to support
just 'audience', just 'resource' or both when constraining tokens.
We should also provide some "best practice" guidance on how resource
servers can ensure these tokens are for them. In a wide eco-system
deployment where a resource server is supporting multiple authorization
servers, this could get complicated for the resource server. The
resource-indicators spec implies that the AS should use the resource
parameter to set the 'audience' of the returned access_token. There is
no guidance for what a AS should return from the /introspection endpoint
in regards to the "constrained" token. Do both 'resource' and 'audience'
values get returned in the "aud" claim?
Thanks,
George
On 2/7/19 11:26 AM, Hannes Tschofenig wrote:
Hi George,
The IANA registry does not indicate in what context these parameters
are supposed to be used. To me it feels totally normal to use the
audience parameter instead of the resource parameter when I have a
logical name.
Stuffing everything into a URI is possible but in certain scenarios
may feel quite unnatural. It must have felt unnatural already to the
group when working on the token exchange spec…
Ciao
Hannes
*From:*George Fletcher <gffle...@aol.com>
*Sent:* Donnerstag, 7. Februar 2019 17:06
*To:* Hannes Tschofenig <hannes.tschofe...@arm.com>; Ludwig Seitz
<ludwig.se...@ri.se>; a...@ietf.org; oauth@ietf.org
*Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for
draft-ietf-oauth-resource-indicators-01
This is true... however, to my knowledge there is no support for this
parameter outside of the token-exchange spec. Just because it is
documented as an OAuth parameter I don't consider it usable in other
contexts unless spec'd to do so. If we want to use 'audience' for
logical audience names when binding audiences to tokens, then we need
a spec for that (or add it to the resource-indicators spec).
Personally, I see a lot of overlap even between the 'audience' and
'resource' parameters. I'd really prefer we just have one parameter
that can be either logical or specific. As outlined in this thread,
'https://api.exampl.com' to me is a logical representation of the
resource if the "real" endpoint(s) are
"https://api.example.com/mail/user/inbox";
<https://api.example.com/mail/user/inbox>, ...
Thanks,
George
On 2/7/19 10:16 AM, Hannes Tschofenig wrote:
Hi George,
* I believe that since the latest draft of the resource
indicators spec [1] allows for abstract identifiers, and since
a URN is also a URI, you could easily use a URN syntax to
accomplish the use case outlined in your email.
After re-reading the token exchange draft I realized that we have
already defined a separate parameter for “abstract”, or logical,
names via the audience parameter. Here is the definition:
audience
OPTIONAL. The logical name of the target service where the
client
intends to use the requested security token. This serves a
purpose similar to the "resource" parameter, but with the client
providing a logical name rather than a location. Interpretation
of the name requires that the value be something that both the
client and the authorization server understand. An OAuth client
identifier, a SAML entity identifier [OASIS.saml-core-2.0-os
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OASIS.saml-core-2.0-os>],
an
OpenID Connect Issuer Identifier [OpenID.Core
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OpenID.Core>],
or a URI are
examples of things that might be used as "audience" parameter
values. Multiple "audience" parameters may be used to indicate
that the issued token is intended to be used at the multiple
audiences listed. The "audience" and "resource" parameters
may be
used together to indicate multiple target services with a mix of
logical names and locations.
Ciao
Hannes
*From:*Ace <ace-boun...@ietf.org> <mailto:ace-boun...@ietf.org>
*On Behalf Of * George Fletcher
*Sent:* Dienstag, 29. Januar 2019 14:15
*To:* Ludwig Seitz <ludwig.se...@ri.se>
<mailto:ludwig.se...@ri.se>; a...@ietf.org <mailto:a...@ietf.org>;
oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for
draft-ietf-oauth-resource-indicators-01
Thank you so much for the background!
I believe that since the latest draft of the resource indicators
spec [1] allows for abstract identifiers, and since a URN is also
a URI, you could easily use a URN syntax to accomplish the use
case outlined in your email.
resource=urn:x-mydevices:temperatureSensorGroup4711
The spec currently outlines examples where the "resource
identifier" is not a "single resource" in the context of a fully
qualified API endpoint.
Another example, for an API like SCIM [RFC7644
<https://tools.ietf.org/html/rfc7644>] that has
multiple endpoints such as"https://apps.example.com/scim/Users";
<https://apps.example.com/scim/Users>,
"https://apps.example.com/scim/Groups";
<https://apps.example.com/scim/Groups>, and
"https://apps.example.com/scim/Schemas";
<https://apps.example.com/scim/Schemas> The client would use
"https://apps.example.com/scim/"; <https://apps.example.com/scim/>
as the resource so that the issued
access token is valid for all the endpoints of the SCIM API.
Using "https://apps.example.com/scim";
<https://apps.example.com/scim> is semantically equivalent to
using "temperatureSensorGroup4711", at least to me:)
Thanks,
George
[1]
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
On 1/29/19 2:56 AM, Ludwig Seitz wrote:
On 28/01/2019 23:12, George Fletcher wrote:
I also don't know that this raises to the level of
"concern" but I find the parameter name of "req_aud" odd.
Given that the parameter in the resource-indicators spec
is 'resource' why not use a parameter name of 'audience'.
That said, I have not read the thread on the ACE working
group list so there could be very good reasons for the
chosen name:)
I do think that there is a lot of overlap (in most cases)
between 'resource' and 'audience' and having two
parameters that cover a lot of the same semantics is going
to be confusing for developers. When calling an API at a
resource server, the 'audience' and the 'resource' are
pretty equivalent. Maybe in other use cases they are
distinctly separate?
To give you all the background of "req_aud" from ACE (sorry
for the long text):
Originally in ACE we had defined the "aud" parameter for
requests to the token endpoint with the semantics that the
client was requesting a token for a certain audience (i.e.
requesting that the AS copy the "aud" parameter value into the
"aud" claim value of the token).
We were then told that this collided with a use of "aud" in
OAuth, that specifies the intended audience of Authorization
Servers (if I remember correctly), so we decided to rename our
parameter to "req_aud" for "requested audience".
Mike Jones then made us aware of the work on resource
indicators, but upon closer examination I found the "resource"
parameter to be more limited than the "req_aud", since
resource specifically states:
"Its value MUST be an absolute URI ... the "resource"
parameter URI value is an identifier representing the identity
of the resource"
My interpretation of this is that "resource" refers to a
single resource, which is more constrained than the definition
of the "aud" claim from 7519, which uses a StringOrURI value.
For example my intent was to use "aud" and "req_aud" for group
identifiers ("temperatureSensorGroup4711") and other non-uri
strings (hash-of-public-key), which I cannot do with
"resource". We therefore decided to keep the "req_aud"
parameter in draft-ietf-ace-oauth-params, even though is
clearly overlaps with "resource".
Any comments and suggestions about that line of reasoning
(especially from the OAuth point of view) are very welcome.
/Ludwig
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
