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 <[email protected]> On Behalf Of George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz <[email protected]>; [email protected]; [email protected]
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
--
Identity Standards Architect
Verizon Media Work:
[email protected]<mailto:[email protected]>
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
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 protected]
https://www.ietf.org/mailman/listinfo/oauth
