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/Groups";, and
"https://apps.example.com/scim/Schemas"; The client would use
"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"; 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: george.fletc...@oath.com
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
