Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[George Fletcher <[e-mail]>]

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: [e-mail]
Mobile: [phone]           Twitter: http://twitter.com/gffletch
Office: [phone]           Photos: http://georgefletcher.photography