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

[George Fletcher]

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 
*Sent:* Donnerstag, 7. Februar 2019 17:06
*To:* Hannes Tschofenig ; Ludwig Seitz 
; 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  <mailto:ace-boun...@ietf.org>
*On Behalf Of * George Fletcher
*Sent:* Dienstag, 29. Janua

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

[Hannes Tschofenig]

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 
Sent: Donnerstag, 7. Februar 2019 17:06
To: Hannes Tschofenig ; Ludwig Seitz 
; 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 <mailto:ace-boun...@ietf.org> On Behalf Of 
George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz <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 wrot

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

[George Fletcher]

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;, ...


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  *On Behalf Of *George Fletcher
*Sent:* Dienstag, 29. Januar 2019 14:15
*To:* Ludwig Seitz ; a...@ietf.org; 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

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

[Hannes Tschofenig]

Hi Ludwig,

the issue is that folks in the OAuth group have defined two parameters, namely 
resource (for URIs) and audience (for logical names), and in ACE there is only 
one doing both.

To me this appears to be sub-optimal to have different ways to accomplish the 
same goal just based on the protocol the information is exchanged.

Which route is better? I don't care.

Ciao
Hannes



-Original Message-
From: Ludwig Seitz 
Sent: Donnerstag, 7. Februar 2019 16:29
To: Hannes Tschofenig ; a...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

On 07/02/2019 16:15, Hannes Tschofenig wrote:
> Hi Ludwig,
>
>> My interpretation of this is that "resource" refers to a single resource
>
> No. Here is the text from token exchange (see last sentence):
>
> resource
[...]
> Multiple "resource" parameters may be used to indicate
>that the issued token is intended to be used at the multiple
>resources listed.
>

Enumerating the audience is not the same as addressing it by a group name.

I agree that without too much stretching of the definition of the
resource parameter I could use URIs as group identifiers, however the
audience claim is defined to be "StringOrURI" so if someone defines an
audience identified by a String that is not an URI how does a client ask
for that with the resource parameter?

Or in short: Why don't you make your resource parameter mirror the "aud"
claim?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

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

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

[Ludwig Seitz]

On 07/02/2019 16:15, Hannes Tschofenig wrote:

Hi Ludwig,


My interpretation of this is that "resource" refers to a single resource


No. Here is the text from token exchange (see last sentence):

resource

[...]

Multiple "resource" parameters may be used to indicate
   that the issued token is intended to be used at the multiple
   resources listed.



Enumerating the audience is not the same as addressing it by a group name.

I agree that without too much stretching of the definition of the 
resource parameter I could use URIs as group identifiers, however the 
audience claim is defined to be "StringOrURI" so if someone defines an 
audience identified by a String that is not an URI how does a client ask 
for that with the resource parameter?


Or in short: Why don't you make your resource parameter mirror the "aud" 
claim?


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Hannes Tschofenig]

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  On Behalf Of George Fletcher
Sent: Dienstag, 29. Januar 2019 14:15
To: Ludwig Seitz ; a...@ietf.org; 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 "r

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

[Hannes Tschofenig]

Hi Ludwig,

> My interpretation of this is that "resource" refers to a single resource

No. Here is the text from token exchange (see last sentence):

   resource
  OPTIONAL.  Indicates the location of the target service or
  resource where the client intends to use the requested security
  token.  This enables the authorization server to apply policy as
  appropriate for the target, such as determining the type and
  content of the token to be issued or if and how the token is to be
  encrypted.  In many cases, a client will not have knowledge of the
  logical organization of the systems with which it interacts and
  will only know the location of the service where it intends to use
  the token.  The "resource" parameter allows the client to indicate
  to the authorization server where it intends to use the issued
  token by providing the location, typically as an https URL, in the
  token exchange request in the same form that will be used to
  access that resource.  The authorization server will typically
  have the capability to map from a resource URI value to an
  appropriate policy.  The value of the "resource" parameter MUST be
  an absolute URI, as specified by Section 4.3 of [RFC3986], which
  MAY include a query component and MUST NOT include a fragment
  component.  Multiple "resource" parameters may be used to indicate
  that the issued token is intended to be used at the multiple
  resources listed.

Ciao
Hannes


-Original Message-
From: OAuth  On Behalf Of Ludwig Seitz
Sent: Dienstag, 29. Januar 2019 08:56
To: a...@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

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


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
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

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

[George Fletcher]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Ludwig Seitz]

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


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth