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

[Brian Campbell]

[added a...@ietf.org kinda per suggestion from Mike]

I don't know that there are concerns about “req_aud” per se..  Admittedly, I
did use the word "concerns" but I was more trying to say that referencing
it from the draft-ietf-oauth-resource-indicators document wasn't needed to
address Vittorio's request. And pointing out that “req_aud”  is defined for
the token endpoint while the draft-ietf-oauth-resource-indicators document
also deals with the authorization endpoint so such a reference wouldn't
really work anyway.

I don't know of anyone that just works from the OAuth parameter
registration but maybe I'm just out of touch. And I don't think its a
stretch at all to observe that ACE OAuth and OAuth 2 are different.



On Mon, Jan 28, 2019 at 11:28 AM Mike Jones 
wrote:

> Brian, etc.  If you have concerns about “req_aud”, now’s the time to
> provide that feedback to the ACE WG, as they’re trying to complete that
> draft soon.  Please join the ACE WG mailing list and send your feedback
> there directly.
>
>
>
> You and I may know that ACE OAuth and OAuth 2 are pretty different but
> developers later will just see the OAuth parameter registration and won’t
> realize that it’s coming from a different universe.  If we can harmonize
> things now, we should.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *George Fletcher
> *Sent:* Monday, January 28, 2019 10:05 AM
> *To:* Brian Campbell 
> *Cc:* oauth@ietf.org; Vittorio Bertocci 
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> +1
>
> I came to a similar conclusion over the weekend. If
> https://api.example.com/mail is an allowed location URI, how is it not
> also a logical location considering it's possible there are multiple
> endpoints "below" https://api.example.com/mail? (e.g.
> https://api.example.com/mail/user/mailbox). Also if https://api.example.com
> is really a load balancer that fronts the "
> <https://api.example.com/mail?(e.g.https://api.example.com/mail/user/mailbox).Alsoifhttps://api.example.comisreallyaloadbalancerthatfrontsthe>real"
> endpoints, then it's also "logical" in that context and not an exact
> location.
>
> This brings me to the conclusion that all the resource identifiers are
> "logical" along a range of specificity. How specific a resource is
> identified is really a risk decision and based on the deployment model can
> be managed at either the RS or the AS.
>
> Thanks,
> George
>
> On 1/28/19 9:07 AM, Brian Campbell wrote:
>
> I plan on joining the meeting today at noon eastern time to discuses this
> little ditty. I hope others who have a stake in it can too.
>
>
>
> The proposed changes that Vittorio and I put together can be seen in the
> diff of this pull request
> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I
> even put a xml2rfc'ed text version on
> https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of
> reference. I maintain that is the most straightforward way forward with all
> this. Yet another new additional parameter could be defined for the logical
> case but I struggle to see the value in doing so. The 'resource' is URI
> that points to the resource. The level of specificity of that pointer is
> intentionally a bit fuzzy and application/deployment specific. Is
> https://graph.microsoft.com (mentioned in the documentation previously
> linked) a location or an abstract identifier or both? The document already
> (somewhat awkwardly) describes using a "base URI" for the application or
> resource. Is that a a location or an abstract identifier? Or kinda both?
>
>
>
> In addition to the concerns others have expressed about "req_aud", I"d
> note that draft-ietf-ace-oauth-params defines its use only at the token
> endpoint as one of the "additional parameters for requesting an access
> token from a token endpoint in the ACE framework". Whereas the
> resource-indicators draft scope includes the authorization endpoint too.
> Furthermore, while the ACE WG is building on OAuth, for all intents and
> purposes ACE and regular OAuth are different worlds and I think a reference
> in regular OAuth document like this one to "Additional OAuth Parameters for
> Authorization in Constrained Environments (ACE)" would be a disservice to
> just about everyone.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef  > wrote:
>
> Hannes sent an update to this meeting here:
>
> https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU
>
>
>

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

[Mike Jones]

Brian, etc.  If you have concerns about “req_aud”, now’s the time to provide 
that feedback to the ACE WG, as they’re trying to complete that draft soon.  
Please join the ACE WG mailing list and send your feedback there directly.

You and I may know that ACE OAuth and OAuth 2 are pretty different but 
developers later will just see the OAuth parameter registration and won’t 
realize that it’s coming from a different universe.  If we can harmonize things 
now, we should.

  -- Mike

From: OAuth  On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell 
Cc: oauth@ietf.org; Vittorio Bertocci 
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

+1

I came to a similar conclusion over the weekend. If 
https://api.example.com/mail is an allowed location URI, how is it not also a 
logical location considering it's possible there are multiple endpoints "below" 
https://api.example.com/mail? (e.g. https://api.example.com/mail/user/mailbox). 
Also if https://api.example.com is really a load balancer that fronts the 
"<https://api.example.com/mail?(e.g.https://api.example.com/mail/user/mailbox).Alsoifhttps://api.example.comisreallyaloadbalancerthatfrontsthe>real"
 endpoints, then it's also "logical" in that context and not an exact location.

This brings me to the conclusion that all the resource identifiers are 
"logical" along a range of specificity. How specific a resource is identified 
is really a risk decision and based on the deployment model can be managed at 
either the RS or the AS.

Thanks,
George
On 1/28/19 9:07 AM, Brian Campbell wrote:
I plan on joining the meeting today at noon eastern time to discuses this 
little ditty. I hope others who have a stake in it can too.

The proposed changes that Vittorio and I put together can be seen in the diff 
of this pull request 
https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I even 
put a xml2rfc'ed text version on 
https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of 
reference. I maintain that is the most straightforward way forward with all 
this. Yet another new additional parameter could be defined for the logical 
case but I struggle to see the value in doing so. The 'resource' is URI that 
points to the resource. The level of specificity of that pointer is 
intentionally a bit fuzzy and application/deployment specific. Is 
https://graph.microsoft.com (mentioned in the documentation previously linked) 
a location or an abstract identifier or both? The document already (somewhat 
awkwardly) describes using a "base URI" for the application or resource. Is 
that a a location or an abstract identifier? Or kinda both?

In addition to the concerns others have expressed about "req_aud", I"d note 
that draft-ietf-ace-oauth-params defines its use only at the token endpoint as 
one of the "additional parameters for requesting an access token from a token 
endpoint in the ACE framework". Whereas the resource-indicators draft scope 
includes the authorization endpoint too. Furthermore, while the ACE WG is 
building on OAuth, for all intents and purposes ACE and regular OAuth are 
different worlds and I think a reference in regular OAuth document like this 
one to "Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)" would be a disservice to just about everyone.






On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail..com>> wrote:
Hannes sent an update to this meeting here:
https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU

Regards,
 Rifaat


On Thu, Jan 24, 2019 at 6:20 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The virtual office hours in my calendar start 1/2 hour before that.  If the 
time has changed, can you have the meeting organizer update the calendar entry?

  Thanks,
  -- Mike

From: Rifaat Shekh-Yusef mailto:rifaat.i...@gmail.com>>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher mailto:gffle...@aol.com>>
Cc: Vittorio Bertocci mailto:vitto...@auth0.com>>; Mike 
Jones mailto:michael.jo...@microsoft.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

All,

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG 
Virtual Office meeting.
Feel free to attend the meeting to discuss this topic to try to get to a 
conclusion on this.

Regards,
 Rifaat


On Wed, Jan 23, 2019 at 3:00 PM George Fletcher 
mailto:40aol@dmarc.ietf.org>> wrote:
+1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% 
convinced that '

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

[Brian Campbell]

I plan on joining the meeting today at noon eastern time to discuses this
little ditty. I hope others who have a stake in it can too.

The proposed changes that Vittorio and I put together can be seen in the
diff of this pull request
https://github.com/ietf-oauth-resource-indicators/i-d/pull/1/files and I
even put a xml2rfc'ed text version on
https://github.com/ietf-oauth-resource-indicators/i-d/pull/1 for ease of
reference. I maintain that is the most straightforward way forward with all
this. Yet another new additional parameter could be defined for the logical
case but I struggle to see the value in doing so. The 'resource' is URI
that points to the resource. The level of specificity of that pointer is
intentionally a bit fuzzy and application/deployment specific. Is
https://graph.microsoft.com (mentioned in the documentation previously
linked) a location or an abstract identifier or both? The document already
(somewhat awkwardly) describes using a "base URI" for the application or
resource. Is that a a location or an abstract identifier? Or kinda both?

In addition to the concerns others have expressed about "req_aud", I"d note
that draft-ietf-ace-oauth-params defines its use only at the token endpoint
as one of the "additional parameters for requesting an access token from a
token endpoint in the ACE framework". Whereas the resource-indicators draft
scope includes the authorization endpoint too. Furthermore, while the ACE
WG is building on OAuth, for all intents and purposes ACE and regular OAuth
are different worlds and I think a reference in regular OAuth document like
this one to "Additional OAuth Parameters for Authorization in Constrained
Environments (ACE)" would be a disservice to just about everyone.






On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef 
wrote:

> Hannes sent an update to this meeting here:
> https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU
>
> Regards,
>  Rifaat
>
>
> On Thu, Jan 24, 2019 at 6:20 PM Mike Jones 
> wrote:
>
>> The virtual office hours in my calendar start 1/2 hour before that.  If
>> the time has changed, can you have the meeting organizer update the
>> calendar entry?
>>
>>
>>
>>   Thanks,
>>
>>   -- Mike
>>
>>
>>
>> *From:* Rifaat Shekh-Yusef 
>> *Sent:* Thursday, January 24, 2019 12:46 PM
>> *To:* George Fletcher 
>> *Cc:* Vittorio Bertocci ; Mike Jones <
>> michael.jo...@microsoft.com>; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>> draft-ietf-oauth-resource-indicators-01
>>
>>
>>
>> All,
>>
>>
>>
>> This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled
>> OAuth WG Virtual Office meeting.
>>
>> Feel free to attend the meeting to discuss this topic to try to get to a
>> conclusion on this.
>>
>>
>>
>> Regards,
>>
>>  Rifaat
>>
>>
>>
>>
>>
>> On Wed, Jan 23, 2019 at 3:00 PM George Fletcher > 40aol@dmarc.ietf.org> wrote:
>>
>> +1
>>
>> Also, I don't really like the parameter name 'req_aud' :) I'm not 100%
>> convinced that 'audience' and 'logical resource' are completely overlapping
>> concepts. We can potentially make them completely overlapping but we need
>> text to that effect.
>>
>> I also believe that we don't have a complete solution for all deployments
>> using exact locations (see my previous email).
>>
>> Thanks,
>> George
>>
>> On 1/23/19 2:50 PM, Vittorio Bertocci wrote:
>>
>> As mentioned below, I agree the two can be separated- but I also agree
>> with George on the need to be clear an easy to reference for developers.
>>
>> Just adding a reference to req_aud would just raise the cyclomatic
>> complexity of the specs, which is already unusably high for mere mortals in
>> the OAuth2/OIDC family of specs.
>>
>>
>>
>> One additional complication is that this specification is reusing a
>> parameter that is already used in a *very* large number of production
>> systems (small example here
>> <https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>),
>> and whose concrete semantic happens to be prevalently logic identifier. If
>> the parameter you are defining here has a different semantic, at the very
>> least it would seem good hygiene to rename it to avoid collision and
>> confusion.
>>
>>
>>
>> On Wed, Jan 23, 2019 at 11:03 AM Mike Jones > 40microsoft...

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

[Rifaat Shekh-Yusef]

Hannes sent an update to this meeting here:
https://mailarchive.ietf.org/arch/msg/oauth/v8sUMEBGMC24AdWLewAymP-X4kU

Regards,
 Rifaat


On Thu, Jan 24, 2019 at 6:20 PM Mike Jones 
wrote:

> The virtual office hours in my calendar start 1/2 hour before that.  If
> the time has changed, can you have the meeting organizer update the
> calendar entry?
>
>
>
>   Thanks,
>
>   -- Mike
>
>
>
> *From:* Rifaat Shekh-Yusef 
> *Sent:* Thursday, January 24, 2019 12:46 PM
> *To:* George Fletcher 
> *Cc:* Vittorio Bertocci ; Mike Jones <
> michael.jo...@microsoft.com>; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> All,
>
>
>
> This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled
> OAuth WG Virtual Office meeting.
>
> Feel free to attend the meeting to discuss this topic to try to get to a
> conclusion on this.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Wed, Jan 23, 2019 at 3:00 PM George Fletcher  40aol@dmarc.ietf.org> wrote:
>
> +1
>
> Also, I don't really like the parameter name 'req_aud' :) I'm not 100%
> convinced that 'audience' and 'logical resource' are completely overlapping
> concepts. We can potentially make them completely overlapping but we need
> text to that effect.
>
> I also believe that we don't have a complete solution for all deployments
> using exact locations (see my previous email).
>
> Thanks,
> George
>
> On 1/23/19 2:50 PM, Vittorio Bertocci wrote:
>
> As mentioned below, I agree the two can be separated- but I also agree
> with George on the need to be clear an easy to reference for developers.
>
> Just adding a reference to req_aud would just raise the cyclomatic
> complexity of the specs, which is already unusably high for mere mortals in
> the OAuth2/OIDC family of specs.
>
>
>
> One additional complication is that this specification is reusing a
> parameter that is already used in a *very* large number of production
> systems (small example here
> <https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>),
> and whose concrete semantic happens to be prevalently logic identifier. If
> the parameter you are defining here has a different semantic, at the very
> least it would seem good hygiene to rename it to avoid collision and
> confusion.
>
>
>
> On Wed, Jan 23, 2019 at 11:03 AM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
> I agree with John’s logic.  The physical resource and logical resource
> should use different identifiers.  Fortunately, we already have “resource”
> and “req_aud” for these parameters.  I believe we’re good to go, as-is.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *John Bradley
> *Sent:* Wednesday, January 23, 2019 10:56 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> I don't think they are necessarily mutually exclusive, that is why I think
> there is value in allowing them to be specified separately.
>
> As an AS in the distributed OAuth case knowing that a client interacting
> with RS https://fire.hhs.com as the resource wants a OAuth token with an
> audience of HHS and a scope of read.
>
> Without proof of possession we need to keep bad RS from asking for tokens
> with scopes and audiences of other RS that can be replayed.
>
> I really like keeping the resource simple and unspoofable, it is the URI
> of the RS where you are presenting the AT.
>
> I prefer to keep that separate from the logical resource that may span
> more than one RS endpoint.
>
> Merging the two and we are probably back at the AS looking into the URI to
> figure out which one it is.  I think that is harder for implementations and
> more likely to have security issues down the road.
>
> John B.
>
> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
>
> Hi all,
>
> thanks for you patience. Brian and myself iterated on modifying the text
> to cover the logical identifier use case, highlighting the security
> implications of going that route. You can find the revised text in
> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml,
> see the commits in the history from January 21 for the specific changes.
>
> Note: I also had a chat with John offline, and he expressed the desire to
> split the resource parameter in two distinct parameters to better signal
> the intended usage. I am s

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

[Mike Jones]

The virtual office hours in my calendar start 1/2 hour before that.  If the 
time has changed, can you have the meeting organizer update the calendar entry?

  Thanks,
  -- Mike

From: Rifaat Shekh-Yusef 
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher 
Cc: Vittorio Bertocci ; Mike Jones 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

All,

This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG 
Virtual Office meeting.
Feel free to attend the meeting to discuss this topic to try to get to a 
conclusion on this.

Regards,
 Rifaat


On Wed, Jan 23, 2019 at 3:00 PM George Fletcher 
mailto:40aol@dmarc.ietf.org>> wrote:
+1

Also, I don't really like the parameter name 'req_aud' :) I'm not 100% 
convinced that 'audience' and 'logical resource' are completely overlapping 
concepts. We can potentially make them completely overlapping but we need text 
to that effect.

I also believe that we don't have a complete solution for all deployments using 
exact locations (see my previous email).

Thanks,
George
On 1/23/19 2:50 PM, Vittorio Bertocci wrote:
As mentioned below, I agree the two can be separated- but I also agree with 
George on the need to be clear an easy to reference for developers.
Just adding a reference to req_aud would just raise the cyclomatic complexity 
of the specs, which is already unusably high for mere mortals in the 
OAuth2/OIDC family of specs.

One additional complication is that this specification is reusing a parameter 
that is already used in a very large number of production systems (small 
example 
here<https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>),
 and whose concrete semantic happens to be prevalently logic identifier. If the 
parameter you are defining here has a different semantic, at the very least it 
would seem good hygiene to rename it to avoid collision and confusion.

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with John’s logic.  The physical resource and logical resource should 
use different identifiers.  Fortunately, we already have “resource” and 
“req_aud” for these parameters.  I believe we’re good to go, as-is.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01


I don't think they are necessarily mutually exclusive, that is why I think 
there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with 
RS https://fire.hhs.com as the resource wants a OAuth token with an audience of 
HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with 
scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the 
RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more 
than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to 
figure out which one it is.  I think that is harder for implementations and 
more likely to have security issues down the road.

John B.
On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to 
cover the logical identifier use case, highlighting the security implications 
of going that route. You can find the revised text in 
https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml,
 see the commits in the history from January 21 for the specific changes.
Note: I also had a chat with John offline, and he expressed the desire to split 
the resource parameter in two distinct parameters to better signal the intended 
usage. I am sure he can elaborate. I have nothing against it in principle, as 
long as we leave nothing as exercise to the reader and we are very clear on 
usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian 
about it. If the discussion stretches further, I would suggest we pause it and 
let him enjoy his time off for the rest of the week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however 
this week he is in vacation hence it might take few days before we come back to 
the list with something.
Cheers,

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

[Vittorio Bertocci]

As mentioned below, I agree the two can be separated- but I also agree with
George on the need to be clear an easy to reference for developers.
Just adding a reference to req_aud would just raise the cyclomatic
complexity of the specs, which is already unusably high for mere mortals in
the OAuth2/OIDC family of specs.

One additional complication is that this specification is reusing a
parameter that is already used in a *very* large number of production
systems (small example here
<https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>),
and whose concrete semantic happens to be prevalently logic identifier. If
the parameter you are defining here has a different semantic, at the very
least it would seem good hygiene to rename it to avoid collision and
confusion.

On Wed, Jan 23, 2019 at 11:03 AM Mike Jones  wrote:

> I agree with John’s logic.  The physical resource and logical resource
> should use different identifiers.  Fortunately, we already have “resource”
> and “req_aud” for these parameters.  I believe we’re good to go, as-is.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * John Bradley
> *Sent:* Wednesday, January 23, 2019 10:56 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> I don't think they are necessarily mutually exclusive, that is why I think
> there is value in allowing them to be specified separately.
>
> As an AS in the distributed OAuth case knowing that a client interacting
> with RS https://fire.hhs.com as the resource wants a OAuth token with an
> audience of HHS and a scope of read.
>
> Without proof of possession we need to keep bad RS from asking for tokens
> with scopes and audiences of other RS that can be replayed.
>
> I really like keeping the resource simple and unspoofable, it is the URI
> of the RS where you are presenting the AT.
>
> I prefer to keep that separate from the logical resource that may span
> more than one RS endpoint.
>
> Merging the two and we are probably back at the AS looking into the URI to
> figure out which one it is.  I think that is harder for implementations and
> more likely to have security issues down the road.
>
> John B.
>
> On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
>
> Hi all,
>
> thanks for you patience. Brian and myself iterated on modifying the text
> to cover the logical identifier use case, highlighting the security
> implications of going that route. You can find the revised text in
> https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml,
> see the commits in the history from January 21 for the specific changes.
>
> Note: I also had a chat with John offline, and he expressed the desire to
> split the resource parameter in two distinct parameters to better signal
> the intended usage. I am sure he can elaborate. I have nothing against it
> in principle, as long as we leave nothing as exercise to the reader and we
> are very clear on usage (e.g. mutual exclusivity, etc) but didn't have a
> chance to speak w Brian about it. If the discussion stretches further, I
> would suggest we pause it and let him enjoy his time off for the rest of
> the week.
>
>
>
> On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef 
> wrote:
>
> Thank you guys!
>
>
>
> On Monday, January 21, 2019, Vittorio Bertocci  wrote:
>
> Hi Rifaat,
>
> absolutely. Brian and myself already started working on some language,
> however this week he is in vacation hence it might take few days before we
> come back to the list with something.
>
> Cheers,
>
> V.
>
>
>
> On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef 
> wrote:
>
> Brian, Vittorio,
>
>
>
> To move this discussion forward, can you guys suggest some text to make
> the logical identifier usage clearer?
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
> As I suggested before, I do think that's within the bounds of the draft's
> definition of 'resource' as a URI. And that perhaps all that's needed is
> some minor adjustment and/or augmentation of some text to make it more
> clear.
>
>
>
> On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci 
> wrote:
>
> [sent to John only by mistake, resending to the ML]
>
>
>
> In Azure AD v1 & ADFS, that's resource. It could be used for both network
> and logical ids, with the concrete usage in the wild I described earlier.
>
> In Azure AD v2, the resource as explicit parameter (network, logic or
> otherwise) is gone an

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

[Mike Jones]

I agree with John’s logic.  The physical resource and logical resource should 
use different identifiers.  Fortunately, we already have “resource” and 
“req_aud” for these parameters.  I believe we’re good to go, as-is.

   -- Mike

From: OAuth  On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01


I don't think they are necessarily mutually exclusive, that is why I think 
there is value in allowing them to be specified separately.

As an AS in the distributed OAuth case knowing that a client interacting with 
RS https://fire.hhs.com as the resource wants a OAuth token with an audience of 
HHS and a scope of read.

Without proof of possession we need to keep bad RS from asking for tokens with 
scopes and audiences of other RS that can be replayed.

I really like keeping the resource simple and unspoofable, it is the URI of the 
RS where you are presenting the AT.

I prefer to keep that separate from the logical resource that may span more 
than one RS endpoint.

Merging the two and we are probably back at the AS looking into the URI to 
figure out which one it is.  I think that is harder for implementations and 
more likely to have security issues down the road.

John B.
On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to 
cover the logical identifier use case, highlighting the security implications 
of going that route. You can find the revised text in 
https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml,
 see the commits in the history from January 21 for the specific changes.
Note: I also had a chat with John offline, and he expressed the desire to split 
the resource parameter in two distinct parameters to better signal the intended 
usage. I am sure he can elaborate. I have nothing against it in principle, as 
long as we leave nothing as exercise to the reader and we are very clear on 
usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian 
about it. If the discussion stretches further, I would suggest we pause it and 
let him enjoy his time off for the rest of the week.

On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however 
this week he is in vacation hence it might take few days before we come back to 
the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Brian, Vittorio,

To move this discussion forward, can you guys suggest some text to make the 
logical identifier usage clearer?

Regards,
 Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
 wrote:
As I suggested before, I do think that's within the bounds of the draft's 
definition of 'resource' as a URI. And that perhaps all that's needed is some 
minor adjustment and/or augmentation of some text to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
[sent to John only by mistake, resending to the ML]


In Azure AD v1 & ADFS, that's resource. It could be used for both network and 
logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or 
otherwise) is gone and is expressed as part of the scope string of all the 
scopes requested for a given resource- but it still exist in practice tho as it 
still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

What is the parameter that Microsoft is using?
On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my 
former position I wasn't monitoring those discussions hence I didn't have a 
chance to offer feedback. When I saw something that gave me the impression 
might lead to issues, and given that I worked with actual deployments and 
developers using a similar parameter for a long time, I thought prudent to 
bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the 
concept of logical resource in a standard compliant way, hence it doesn't 
strictly matter whether the definition of the corresponding parameter lives in 
oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons 
for which the spec was created apply to both the network addressable and t

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

[Vittorio Bertocci]

e only difference comes at token usage time, with the network 
>>>>>> addressable
>>>>>> case giving more guarantees that the token will go to its intended
>>>>>> recipient, but the request and audience restriction syntax seems to be
>>>>>> exactly the same.
>>>>>> On top of this: in the 99.999% of the scenarios I encountered in the
>>>>>> wild in the last 5 years of using the resource parameter in the MS
>>>>>> ecosystem, the resource identifier was known at design time: the 
>>>>>> developer
>>>>>> discovered it out of band and placed it in the app config at deployment
>>>>>> time. Those aren't fringe cases I occasionally encountered: the resource
>>>>>> parameter in Azure AD v1 and ADFS was mandatory, hence literally every
>>>>>> solution i saw or touched used it. As Brian suggested, this is a scenario
>>>>>> where the security advantages of the network addressable case aren't as
>>>>>> pronounced as in the case in which the client discovers the resource
>>>>>> identifier at runtime. This isn't just because there is no specification
>>>>>> suggesting location should be explicitly indicated, it's because there 
>>>>>> are
>>>>>> many practical advantages at development and deployment time to be able 
>>>>>> to
>>>>>> use logical identifiers- and if the *concrete *security advantages
>>>>>> don't apply to the their case, people will simply not comply.
>>>>>>
>>>>>> In summary: creating two different parameters in two different
>>>>>> documents is better than ignoring he logical identifier case altogether,
>>>>>> however I think that not acknowledging the logical id case
>>>>>> in oauth-resource-indicators is going to create confusion and ultimately
>>>>>> not be as useful to the developer community as it could be.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt  wrote:
>>>>>>
>>>>>>> +1 to Mike and John’s comments.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones <
>>>>>>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>> I also agree that “resource” should be a specific
>>>>>>> network-addressable URL whereas a separate audience parameter (like 
>>>>>>> “aud”
>>>>>>> in JWTs) can refer to one or more logical resources.  They are 
>>>>>>> different,
>>>>>>> if related, things.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note that the ACE WG is proposing to register a logical audience
>>>>>>> parameter “req_aud” in
>>>>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>>>>>>> based on feedback from OAuth WG members.  This is a general OAuth
>>>>>>> parameter, which any OAuth deployment will be able to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I therefore believe that no changes are needed to
>>>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work is
>>>>>>> already happening in another draft.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   -- Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* OAuth  *On Behalf Of * John Bradley
>>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>>>>> *To:* Brian Campbell 
>>>>>>> *Cc:* Vittorio Bertocci ; IETF
>>>>>>> oauth WG 
>>>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We need to decide if we want to make a change.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For security we are l

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

[Mike Jones]

I think that a non-normative reference to  “req_aud” in 
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be added to 
the resource indicators doc to inform developers that req_aud is also available 
to then, and then we should call it a day.

-- Mike

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, January 21, 2019 5:36 PM
To: Vittorio Bertocci 
Cc: Brian Campbell ; IETF oauth WG 

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

Thank you guys!


On Monday, January 21, 2019, Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however 
this week he is in vacation hence it might take few days before we come back to 
the list with something.
Cheers,
V.

On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Brian, Vittorio,

To move this discussion forward, can you guys suggest some text to make the 
logical identifier usage clearer?

Regards,
 Rifaat


On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
 wrote:
As I suggested before, I do think that's within the bounds of the draft's 
definition of 'resource' as a URI. And that perhaps all that's needed is some 
minor adjustment and/or augmentation of some text to make it more clear.

On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's resource. It could be used for both network and 
logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or 
otherwise) is gone and is expressed as part of the scope string of all the 
scopes requested for a given resource- but it still exist in practice tho as it 
still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

What is the parameter that Microsoft is using?
On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my 
former position I wasn't monitoring those discussions hence I didn't have a 
chance to offer feedback. When I saw something that gave me the impression 
might lead to issues, and given that I worked with actual deployments and 
developers using a similar parameter for a long time, I thought prudent to 
bring this up. I really appreciate Rifaat's stance on this. End of preamble.

Ultimately my goal is for developers to have guidance on how to work with the 
concept of logical resource in a standard compliant way, hence it doesn't 
strictly matter whether the definition of the corresponding parameter lives in 
oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons 
for which the spec was created apply to both the network addressable and the 
logical resource types: knowing what keys to use to encrypt the token, 
constrain access tokens to the intended audience, avoiding overloading scopes 
with resource indicating parts... those all apply to network addressable and 
logic identifiers alike. And both parameters are expected to result in audience 
restricted tokens. It seems the only difference comes at token usage time, with 
the network addressable case giving more guarantees that the token will go to 
its intended recipient, but the request and audience restriction syntax seems 
to be exactly the same.
On top of this: in the 99.999% of the scenarios I encountered in the wild in 
the last 5 years of using the resource parameter in the MS ecosystem, the 
resource identifier was known at design time: the developer discovered it out 
of band and placed it in the app config at deployment time. Those aren't fringe 
cases I occasionally encountered: the resource parameter in Azure AD v1 and 
ADFS was mandatory, hence literally every solution i saw or touched used it. As 
Brian suggested, this is a scenario where the security advantages of the 
network addressable case aren't as pronounced as in the case in which the 
client discovers the resource identifier at runtime. This isn't just because 
there is no specification suggesting location should be explicitly indicated, 
it's because there are many practical advantages at development and deployment 
time to be able to use logical identifiers- and if the concrete security 
advantages don't apply to the their case, people will simply not comply.

In summary: creating two different parameters in two different documents is 
better than ignoring he logical identifier case altogether, however I think 
that not acknowledging the logical id case in oauth-resource-indicators is 
going to create confusion and ultimately

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

[Rifaat Shekh-Yusef]

xplicitly indicated, it's because there are
>>>>> many practical advantages at development and deployment time to be able to
>>>>> use logical identifiers- and if the *concrete *security advantages
>>>>> don't apply to the their case, people will simply not comply.
>>>>>
>>>>> In summary: creating two different parameters in two different
>>>>> documents is better than ignoring he logical identifier case altogether,
>>>>> however I think that not acknowledging the logical id case
>>>>> in oauth-resource-indicators is going to create confusion and ultimately
>>>>> not be as useful to the developer community as it could be.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt  wrote:
>>>>>
>>>>>> +1 to Mike and John’s comments.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones >>>>> c...@dmarc.ietf.org> wrote:
>>>>>>
>>>>>> I also agree that “resource” should be a specific network-addressable
>>>>>> URL whereas a separate audience parameter (like “aud” in JWTs) can refer 
>>>>>> to
>>>>>> one or more logical resources.  They are different, if related, things.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that the ACE WG is proposing to register a logical audience
>>>>>> parameter “req_aud” in https://tools.ietf.org/html/
>>>>>> draft-ietf-ace-oauth-params-01 - partly based on feedback from OAuth
>>>>>> WG members.  This is a general OAuth parameter, which any OAuth 
>>>>>> deployment
>>>>>> will be able to use.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I therefore believe that no changes are needed to
>>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work
>>>>>> is already happening in another draft.
>>>>>>
>>>>>>
>>>>>>
>>>>>>   -- Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* OAuth  *On Behalf Of * John Bradley
>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>>>> *To:* Brian Campbell 
>>>>>> *Cc:* Vittorio Bertocci ; IETF
>>>>>> oauth WG 
>>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>>
>>>>>>
>>>>>>
>>>>>> We need to decide if we want to make a change.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For security we are location centric.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I prefer to keep resource location separate from logical audience
>>>>>> that can be a scope or other parameter.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If becomes harder for people to use the parameter correctly if we are
>>>>>> too flexible.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would rather have a separate logical audience parameter if we think
>>>>>> we want one.
>>>>>>
>>>>>>
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <
>>>>>> bcampb...@pingidentity.com wrote:
>>>>>>
>>>>>> No apology needed, Rifaat. And I apologize if what I said came off
>>>>>> the wrong way. I was just trying to make light of the situation.. And I
>>>>>> agree that we should not be hamstrung by the process and there are times
>>>>>> when it makes sense to be flexible with things.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <
>>>>>> rifaat.i...@gmail.com> wrote:
>>>>>>
>>>>>> Sorry Brian, I was not clear with my statement.
>>>>>>
>>>>>> I meant to say that we 

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

[Vittorio Bertocci]

ts is better than ignoring he logical identifier case altogether,
>>>> however I think that not acknowledging the logical id case
>>>> in oauth-resource-indicators is going to create confusion and ultimately
>>>> not be as useful to the developer community as it could be.
>>>>
>>>>
>>>>
>>>> On Sat, Jan 19, 2019 at 12:38 Phil Hunt  wrote:
>>>>
>>>>> +1 to Mike and John’s comments.
>>>>>
>>>>> Phil
>>>>>
>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones <
>>>>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>>>>
>>>>> I also agree that “resource” should be a specific network-addressable
>>>>> URL whereas a separate audience parameter (like “aud” in JWTs) can refer 
>>>>> to
>>>>> one or more logical resources.  They are different, if related, things.
>>>>>
>>>>>
>>>>>
>>>>> Note that the ACE WG is proposing to register a logical audience
>>>>> parameter “req_aud” in
>>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>>>>> based on feedback from OAuth WG members.  This is a general OAuth
>>>>> parameter, which any OAuth deployment will be able to use.
>>>>>
>>>>>
>>>>>
>>>>> I therefore believe that no changes are needed to
>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work is
>>>>> already happening in another draft.
>>>>>
>>>>>
>>>>>
>>>>>   -- Mike
>>>>>
>>>>>
>>>>>
>>>>> *From:* OAuth  *On Behalf Of * John Bradley
>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>>> *To:* Brian Campbell 
>>>>> *Cc:* Vittorio Bertocci ; IETF
>>>>> oauth WG 
>>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>>>> draft-ietf-oauth-resource-indicators-01
>>>>>
>>>>>
>>>>>
>>>>> We need to decide if we want to make a change.
>>>>>
>>>>>
>>>>>
>>>>> For security we are location centric.
>>>>>
>>>>>
>>>>>
>>>>> I prefer to keep resource location separate from logical audience that
>>>>> can be a scope or other parameter.
>>>>>
>>>>>
>>>>>
>>>>> If becomes harder for people to use the parameter correctly if we are
>>>>> too flexible.
>>>>>
>>>>>
>>>>>
>>>>> I would rather have a separate logical audience parameter if we think
>>>>> we want one.
>>>>>
>>>>>
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <
>>>>> bcampb...@pingidentity.com wrote:
>>>>>
>>>>> No apology needed, Rifaat. And I apologize if what I said came off the
>>>>> wrong way. I was just trying to make light of the situation.. And I agree
>>>>> that we should not be hamstrung by the process and there are times when it
>>>>> makes sense to be flexible with things.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <
>>>>> rifaat.i...@gmail.com> wrote:
>>>>>
>>>>> Sorry Brian, I was not clear with my statement.
>>>>>
>>>>> I meant to say that we should not allow the process to prevent the WG
>>>>> from producing a quality document without issues, assuming there is an
>>>>> issue in the first place.
>>>>>
>>>>> Ideally we want to get these identified during the WGLC, but things
>>>>> happen and sometimes the WG misses something.
>>>>>
>>>>>
>>>>>
>>>>> I hear you and agree that this make things difficult for authors. We
>>>>> will make sure that this does not become the norm, and we will try to 
>>>>> stick
>>>>> to the process as much as possible.
>>>>>
>>>>>
>>>>>
>>>>> Regard

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

[Rifaat Shekh-Yusef]

.@dmarc.ietf.org> wrote:
>>>>
>>>> I also agree that “resource” should be a specific network-addressable
>>>> URL whereas a separate audience parameter (like “aud” in JWTs) can refer to
>>>> one or more logical resources.  They are different, if related, things..
>>>>
>>>>
>>>>
>>>> Note that the ACE WG is proposing to register a logical audience
>>>> parameter “req_aud” in
>>>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>>>> based on feedback from OAuth WG members.  This is a general OAuth
>>>> parameter, which any OAuth deployment will be able to use.
>>>>
>>>>
>>>>
>>>> I therefore believe that no changes are needed to
>>>> draft-ietf-oauth-resource-indicators, as the logical audience work is
>>>> already happening in another draft.
>>>>
>>>>
>>>>
>>>>   -- Mike
>>>>
>>>>
>>>>
>>>> *From:* OAuth  *On Behalf Of * John Bradley
>>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>>> *To:* Brian Campbell 
>>>> *Cc:* Vittorio Bertocci ; IETF
>>>> oauth WG 
>>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>>> draft-ietf-oauth-resource-indicators-01
>>>>
>>>>
>>>>
>>>> We need to decide if we want to make a change.
>>>>
>>>>
>>>>
>>>> For security we are location centric.
>>>>
>>>>
>>>>
>>>> I prefer to keep resource location separate from logical audience that
>>>> can be a scope or other parameter.
>>>>
>>>>
>>>>
>>>> If becomes harder for people to use the parameter correctly if we are
>>>> too flexible.
>>>>
>>>>
>>>>
>>>> I would rather have a separate logical audience parameter if we think
>>>> we want one.
>>>>
>>>>
>>>>
>>>> John B.
>>>>
>>>>
>>>>
>>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <
>>>> bcampb...@pingidentity.com wrote:
>>>>
>>>> No apology needed, Rifaat. And I apologize if what I said came off the
>>>> wrong way. I was just trying to make light of the situation.. And I agree
>>>> that we should not be hamstrung by the process and there are times when it
>>>> makes sense to be flexible with things.
>>>>
>>>>
>>>>
>>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <
>>>> rifaat.i...@gmail.com> wrote:
>>>>
>>>> Sorry Brian, I was not clear with my statement.
>>>>
>>>> I meant to say that we should not allow the process to prevent the WG
>>>> from producing a quality document without issues, assuming there is an
>>>> issue in the first place.
>>>>
>>>> Ideally we want to get these identified during the WGLC, but things
>>>> happen and sometimes the WG misses something.
>>>>
>>>>
>>>>
>>>> I hear you and agree that this make things difficult for authors. We
>>>> will make sure that this does not become the norm, and we will try to stick
>>>> to the process as much as possible.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>  Rifaat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <
>>>> bcampb...@pingidentity.com> wrote:
>>>>
>>>> Thanks Rifaat. Process is as process does, right? I do kinda want to
>>>> grumble about WGCL having passed already but that's mostly because replying
>>>> to these kinds of threads is hard for me and I'll just get over it...
>>>>
>>>>
>>>>
>>>> As far as I understand things, the security concerns come into play
>>>> when the client is being told the by the resource how to identity the
>>>> resource like is described in
>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using
>>>> the actual location in that context ,along with some other checks
>>>> prescribed in that draft, prevents the kind of issues John described
>>>> earlier in the thread.

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

[John Bradley]

ld be added and/or adjusted so the resource-indicators
>>> draft would be a little more open/clear about the parameter value
>>> potentially being more of a logical or abstract identifier and not
>>> necessarily a network addressable URL?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <
>>> rifaat.i...@gmail.com> wrote:
>>>
>>> I wouldn't worry too much about the process.
>>>
>>> If it makes sense to update the document, then feel free to do that.
>>>
>>>
>>>
>>> Regards,
>>>
>>>  Rifaat
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:
>>>
>>> Yes the logical resource can be provided by "scope"
>>>
>>>
>>>
>>> Some implementations like Ping and Auth0 have been adding another
>>> parameter "aud" to identify the logical resource and then using scopes to
>>> define permissions to the resource.
>>>
>>>
>>>
>>> Fortunately, we are using a different parameter name so not stepping on
>>> that..
>>>
>>>
>>>
>>> We could go back and try to add text explaining the difference, but we
>>> are quite late in the process.
>>>
>>>
>>>
>>> I agree that a logical resource parameter may be helpful, but perhaps it
>>> should be a separate draft.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
>>> richa...@amazon.com> wrote:
>>>
>>> Doesn’t the “scope” parameter already provide a means of specifying a
>>> logical identifier?
>>>
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of Vittorio Bertocci
>>> >
>>> *Date: *Friday, January 18, 2019 at 5:47 AM
>>> *To: *John Bradley 
>>> *Cc: *IETF oauth WG 
>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
>>> draft-ietf-oauth-resource-indicators-01
>>>
>>>
>>>
>>> Thanks John for the background.
>>>
>>> I agree that from the client validation PoV, having an identifier
>>> corresponding to a location makes things more solid.
>>>
>>> That said: the use of logical identifiers is widespread, as it has
>>> significant practical advantages (think of services that assign generated
>>> hosting URLs only at deployment time, or services that are somehow grouped
>>> under the same logical audience across regions/environment/deployments)..
>>> People won't stop using logical identifiers, because they often have no
>>> alternative (generating new audiences on the fly at the AS every time you
>>> do a deployment and get assigned a new URL can be unfeasible). Leaving a
>>> widely used approach as exercise to the reader seems a disservice to the
>>> community, given that this might lead to vendors (for example Microsoft and
>>> Auth0) keeping their own proprietary parameters, or developers misusing the
>>> ones in place; would make it hard for SDK developers to provide libraries
>>> that work out of the box with different ASes; and so on.
>>>
>>> Would it be feasible to add such parameter directly in this spec? That
>>> would eliminate the interop issues, and also gives us a chance to fully
>>> warn people about the security shortcomings of choosing that approach.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley  wrote:
>>>
>>> We have discussed this.
>>>
>>> Audiences can certainly be logical identifiers.
>>>
>>> This however is a more specific location.  The AS is free to map the
>>> location into some abstract audience in the AT.
>>>
>>> From a security point of view once the client starts asking for logical
>>> resources it can be tricked into asking for the wrong one as a bad resource
>>> can always lie about what logical resource it is.
>>>
>>> If we were to change it, how a client would validate it becomes
>>> challenging to impossible.
>>>
>>> The AS is free to do whatever mapping of locations to 

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

[Brian Campbell]

- partly
>>> based on feedback from OAuth WG members.  This is a general OAuth
>>> parameter, which any OAuth deployment will be able to use.
>>>
>>>
>>>
>>> I therefore believe that no changes are needed to
>>> draft-ietf-oauth-resource-indicators, as the logical audience work is
>>> already happening in another draft.
>>>
>>>
>>>
>>>   -- Mike
>>>
>>>
>>>
>>> *From:* OAuth  *On Behalf Of * John Bradley
>>> *Sent:* Saturday, January 19, 2019 9:01 AM
>>> *To:* Brian Campbell 
>>> *Cc:* Vittorio Bertocci ; IETF
>>> oauth WG 
>>> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
>>> draft-ietf-oauth-resource-indicators-01
>>>
>>>
>>>
>>> We need to decide if we want to make a change.
>>>
>>>
>>>
>>> For security we are location centric.
>>>
>>>
>>>
>>> I prefer to keep resource location separate from logical audience that
>>> can be a scope or other parameter.
>>>
>>>
>>>
>>> If becomes harder for people to use the parameter correctly if we are
>>> too flexible.
>>>
>>>
>>>
>>> I would rather have a separate logical audience parameter if we think we
>>> want one.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <
>>> bcampb...@pingidentity.com wrote:
>>>
>>> No apology needed, Rifaat. And I apologize if what I said came off the
>>> wrong way. I was just trying to make light of the situation.. And I agree
>>> that we should not be hamstrung by the process and there are times when it
>>> makes sense to be flexible with things.
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <
>>> rifaat.i...@gmail.com> wrote:
>>>
>>> Sorry Brian, I was not clear with my statement.
>>>
>>> I meant to say that we should not allow the process to prevent the WG
>>> from producing a quality document without issues, assuming there is an
>>> issue in the first place.
>>>
>>> Ideally we want to get these identified during the WGLC, but things
>>> happen and sometimes the WG misses something.
>>>
>>>
>>>
>>> I hear you and agree that this make things difficult for authors. We
>>> will make sure that this does not become the norm, and we will try to stick
>>> to the process as much as possible.
>>>
>>>
>>>
>>> Regards,
>>>
>>>  Rifaat
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <
>>> bcampb...@pingidentity.com> wrote:
>>>
>>> Thanks Rifaat. Process is as process does, right? I do kinda want to
>>> grumble about WGCL having passed already but that's mostly because replying
>>> to these kinds of threads is hard for me and I'll just get over it...
>>>
>>>
>>>
>>> As far as I understand things, the security concerns come into play when
>>> the client is being told the by the resource how to identity the resource
>>> like is described in
>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using
>>> the actual location in that context ,along with some other checks
>>> prescribed in that draft, prevents the kind of issues John described
>>> earlier in the thread.
>>>
>>> In cases where the client knows the resource a priori or out-of-band or
>>> configured or whatever, I don't think the same security concerns arise. And
>>> using such a known value, be it an actual location or logical
>>> representation, would be okay.
>>>
>>> The resource-indicators draft is admittedly somewhat location-centric in
>>> how it talks about the value of the 'resource' parameter. But ultimately it
>>> defines it as an absolute URI that indicates the location of the target
>>> service or resource where access is being requested. A location can be
>>> varying shades of abstract and I'd say that using a URI as 'resource'
>>> parameter value that's a logical identifier that points to some resource is
>>> well within the bounds of the draft.
>>>
>>>
>>>
>>> So maybe the draft is okay as is?
>&

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

[Vittorio Bertocci]

[sent to John only by mistake, resending to the ML]

In Azure AD v1 & ADFS, that's resource. It could be used for both network
and logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or
otherwise) is gone and is expressed as part of the scope string of all the
scopes requested for a given resource- but it still exist in practice tho
as it still end up in the resulting aud of the issued token.
This is 9 months old info hence

On Sun, Jan 20, 2019 at 17:58 John Bradley  wrote:

> What is the parameter that Microsoft is using?
> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
>
> First of all, it wasn't my intent to disrupt the established process. In
> my former position I wasn't monitoring those discussions hence I didn't
> have a chance to offer feedback. When I saw something that gave me the
> impression might lead to issues, and given that I worked with actual
> deployments and developers using a similar parameter for a long time, I
> thought prudent to bring this up. I really appreciate Rifaat's stance on
> this. End of preamble.
>
> Ultimately my goal is for developers to have guidance on how to work with
> the concept of logical resource in a standard compliant way, hence it
> doesn't strictly matter whether the definition of the corresponding
> parameter lives in oauth-resource-indicators or elsewhere.
> That said. Reading through the draft, it would appear that most of the
> reasons for which the spec was created apply to both the network
> addressable and the logical resource types: knowing what keys to use to
> encrypt the token, constrain access tokens to the intended audience,
> avoiding overloading scopes with resource indicating parts... those all
> apply to network addressable and logic identifiers alike. And both
> parameters are expected to result in audience restricted tokens. It seems
> the only difference comes at token usage time, with the network addressable
> case giving more guarantees that the token will go to its intended
> recipient, but the request and audience restriction syntax seems to be
> exactly the same.
> On top of this: in the 99.999% of the scenarios I encountered in the wild
> in the last 5 years of using the resource parameter in the MS ecosystem,
> the resource identifier was known at design time: the developer discovered
> it out of band and placed it in the app config at deployment time. Those
> aren't fringe cases I occasionally encountered: the resource parameter in
> Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or
> touched used it. As Brian suggested, this is a scenario where the security
> advantages of the network addressable case aren't as pronounced as in the
> case in which the client discovers the resource identifier at runtime. This
> isn't just because there is no specification suggesting location should be
> explicitly indicated, it's because there are many practical advantages at
> development and deployment time to be able to use logical identifiers- and
> if the *concrete *security advantages don't apply to the their case,
> people will simply not comply.
>
> In summary: creating two different parameters in two different documents
> is better than ignoring he logical identifier case altogether, however I
> think that not acknowledging the logical id case
> in oauth-resource-indicators is going to create confusion and ultimately
> not be as useful to the developer community as it could be.
>
>
>
> On Sat, Jan 19, 2019 at 12:38 Phil Hunt  wrote:
>
>> +1 to Mike and John’s comments.
>>
>> Phil
>>
>> On Jan 19, 2019, at 12:34 PM, Mike Jones <
>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>
>> I also agree that “resource” should be a specific network-addressable URL
>> whereas a separate audience parameter (like “aud” in JWTs) can refer to one
>> or more logical resources.  They are different, if related, things.
>>
>>
>>
>> Note that the ACE WG is proposing to register a logical audience
>> parameter “req_aud” in
>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>> based on feedback from OAuth WG members.  This is a general OAuth
>> parameter, which any OAuth deployment will be able to use.
>>
>>
>>
>> I therefore believe that no changes are needed to
>> draft-ietf-oauth-resource-indicators, as the logical audience work is
>> already happening in another draft.
>>
>>
>>
>>   -- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * John Bradley
>> *Sent:* Saturday, January 19, 2019 9:01 AM
>> *To:*

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

[John Bradley]

What is the parameter that Microsoft is using?

On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. 
In my former position I wasn't monitoring those discussions hence I 
didn't have a chance to offer feedback. When I saw something that gave 
me the impression might lead to issues, and given that I worked with 
actual deployments and developers using a similar parameter for a long 
time, I thought prudent to bring this up. I really appreciate Rifaat's 
stance on this. End of preamble.


Ultimately my goal is for developers to have guidance on how to work 
with the concept of logical resource in a standard compliant way, 
hence it doesn't strictly matter whether the definition of the 
corresponding parameter lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the 
reasons for which the spec was created apply to both the network 
addressable and the logical resource types: knowing what keys to use 
to encrypt the token, constrain access tokens to the intended 
audience, avoiding overloading scopes with resource indicating 
parts... those all apply to network addressable and logic identifiers 
alike. And both parameters are expected to result in audience 
restricted tokens. It seems the only difference comes at token usage 
time, with the network addressable case giving more guarantees that 
the token will go to its intended recipient, but the request and 
audience restriction syntax seems to be exactly the same.
On top of this: in the 99.999% of the scenarios I encountered in the 
wild in the last 5 years of using the resource parameter in the MS 
ecosystem, the resource identifier was known at design time: the 
developer discovered it out of band and placed it in the app config at 
deployment time. Those aren't fringe cases I occasionally encountered: 
the resource parameter in Azure AD v1 and ADFS was mandatory, hence 
literally every solution i saw or touched used it. As Brian suggested, 
this is a scenario where the security advantages of the network 
addressable case aren't as pronounced as in the case in which the 
client discovers the resource identifier at runtime. This isn't just 
because there is no specification suggesting location should be 
explicitly indicated, it's because there are many practical advantages 
at development and deployment time to be able to use logical 
identifiers- and if the /concrete /security advantages don't apply to 
the their case, people will simply not comply.


In summary: creating two different parameters in two different 
documents is better than ignoring he logical identifier case 
altogether, however I think that not acknowledging the logical id case 
in oauth-resource-indicators is going to create confusion and 
ultimately not be as useful to the developer community as it could be.




On Sat, Jan 19, 2019 at 12:38 Phil Hunt <mailto:phil.h...@oracle.com>> wrote:


+1 to Mike and John’s comments.

Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> wrote:


I also agree that “resource” should be a specific
network-addressable URL whereas a separate audience parameter
(like “aud” in JWTs) can refer to one or more logical resources. 
They are different, if related, things.

Note that the ACE WG is proposing to register a logical audience
parameter “req_aud” in
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 -
partly based on feedback from OAuth WG members.  This is a
general OAuth parameter, which any OAuth deployment will be able
to use.

I therefore believe that no changes are needed to
draft-ietf-oauth-resource-indicators, as the logical audience
work is already happening in another draft.

-- Mike

*From:* OAuth mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley
*Sent:* Saturday, January 19, 2019 9:01 AM
*To:* Brian Campbell mailto:bcampb...@pingidentity.com>>
*Cc:* Vittorio Bertocci mailto:Vittorio=40auth0@dmarc.ietf.org>>; IETF oauth WG
mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] Shepherd write-up for
    draft-ietf-oauth-resource-indicators-01

We need to decide if we want to make a change.

For security we are location centric.

I prefer to keep resource location separate from logical audience
that can be a scope or other parameter.

If becomes harder for people to use the parameter correctly if we
are too flexible.

I would rather have a separate logical audience parameter if we
think we want one.

John B.

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell
mailto:bcampb...@pingidentity.com>
wrote:

No apology needed, Rifaat. And I apologize if what I said
came off the wrong way. I was just trying to make light of
the situation.. A

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

[Vittorio Bertocci]

First of all, it wasn't my intent to disrupt the established process. In my
former position I wasn't monitoring those discussions hence I didn't have a
chance to offer feedback. When I saw something that gave me the impression
might lead to issues, and given that I worked with actual deployments and
developers using a similar parameter for a long time, I thought prudent to
bring this up. I really appreciate Rifaat's stance on this. End of preamble..

Ultimately my goal is for developers to have guidance on how to work with
the concept of logical resource in a standard compliant way, hence it
doesn't strictly matter whether the definition of the corresponding
parameter lives in oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the
reasons for which the spec was created apply to both the network
addressable and the logical resource types: knowing what keys to use to
encrypt the token, constrain access tokens to the intended audience,
avoiding overloading scopes with resource indicating parts... those all
apply to network addressable and logic identifiers alike. And both
parameters are expected to result in audience restricted tokens. It seems
the only difference comes at token usage time, with the network addressable
case giving more guarantees that the token will go to its intended
recipient, but the request and audience restriction syntax seems to be
exactly the same.
On top of this: in the 99.999% of the scenarios I encountered in the wild
in the last 5 years of using the resource parameter in the MS ecosystem,
the resource identifier was known at design time: the developer discovered
it out of band and placed it in the app config at deployment time. Those
aren't fringe cases I occasionally encountered: the resource parameter in
Azure AD v1 and ADFS was mandatory, hence literally every solution i saw or
touched used it. As Brian suggested, this is a scenario where the security
advantages of the network addressable case aren't as pronounced as in the
case in which the client discovers the resource identifier at runtime. This
isn't just because there is no specification suggesting location should be
explicitly indicated, it's because there are many practical advantages at
development and deployment time to be able to use logical identifiers- and
if the *concrete *security advantages don't apply to the their case, people
will simply not comply.

In summary: creating two different parameters in two different documents is
better than ignoring he logical identifier case altogether, however I think
that not acknowledging the logical id case in oauth-resource-indicators is
going to create confusion and ultimately not be as useful to the developer
community as it could be.



On Sat, Jan 19, 2019 at 12:38 Phil Hunt  wrote:

> +1 to Mike and John’s comments.
>
> Phil
>
> On Jan 19, 2019, at 12:34 PM, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> I also agree that “resource” should be a specific network-addressable URL
> whereas a separate audience parameter (like “aud” in JWTs) can refer to one
> or more logical resources.  They are different, if related, things.
>
>
>
> Note that the ACE WG is proposing to register a logical audience parameter
> “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 -
> partly based on feedback from OAuth WG members.  This is a general OAuth
> parameter, which any OAuth deployment will be able to use.
>
>
>
> I therefore believe that no changes are needed to
> draft-ietf-oauth-resource-indicators, as the logical audience work is
> already happening in another draft.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * John Bradley
> *Sent:* Saturday, January 19, 2019 9:01 AM
> *To:* Brian Campbell 
> *Cc:* Vittorio Bertocci ; IETF oauth
> WG 
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> We need to decide if we want to make a change.
>
>
>
> For security we are location centric.
>
>
>
> I prefer to keep resource location separate from logical audience that can
> be a scope or other parameter.
>
>
>
> If becomes harder for people to use the parameter correctly if we are too
> flexible.
>
>
>
> I would rather have a separate logical audience parameter if we think we
> want one.
>
>
>
> John B.
>
>
>
> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell  wrote:
>
> No apology needed, Rifaat. And I apologize if what I said came off the
> wrong way. I was just trying to make light of the situation.. And I agree
> that we should not be hamstrung by the process and there are times when it
> makes sense to be flexible with things.
>
>
>
> On Fri, Ja

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

[Phil Hunt]

+1 to Mike and John’s comments. 

Phil

> On Jan 19, 2019, at 12:34 PM, Mike Jones 
>  wrote:
> 
> I also agree that “resource” should be a specific network-addressable URL 
> whereas a separate audience parameter (like “aud” in JWTs) can refer to one 
> or more logical resources.  They are different, if related, things.
>  
> Note that the ACE WG is proposing to register a logical audience parameter 
> “req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - 
> partly based on feedback from OAuth WG members.  This is a general OAuth 
> parameter, which any OAuth deployment will be able to use.
>  
> I therefore believe that no changes are needed to 
> draft-ietf-oauth-resource-indicators, as the logical audience work is already 
> happening in another draft.
>  
>   -- Mike
>  
> From: OAuth  On Behalf Of John Bradley
> Sent: Saturday, January 19, 2019 9:01 AM
> To: Brian Campbell 
> Cc: Vittorio Bertocci ; IETF oauth WG 
> 
> Subject: Re: [OAUTH-WG] Shepherd write-up for 
> draft-ietf-oauth-resource-indicators-01
>  
> We need to decide if we want to make a change.  
>  
> For security we are location centric.  
>  
> I prefer to keep resource location separate from logical audience that can be 
> a scope or other parameter.  
>  
> If becomes harder for people to use the parameter correctly if we are too 
> flexible.  
>  
> I would rather have a separate logical audience parameter if we think we want 
> one.  
>  
> John B. 
>  
> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell  wrote:
> No apology needed, Rifaat. And I apologize if what I said came off the wrong 
> way. I was just trying to make light of the situation. And I agree that we 
> should not be hamstrung by the process and there are times when it makes 
> sense to be flexible with things.
>  
> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef  
> wrote:
> Sorry Brian, I was not clear with my statement.
> I meant to say that we should not allow the process to prevent the WG from 
> producing a quality document without issues, assuming there is an issue in 
> the first place.
> Ideally we want to get these identified during the WGLC, but things happen 
> and sometimes the WG misses something. 
>  
> I hear you and agree that this make things difficult for authors. We will 
> make sure that this does not become the norm, and we will try to stick to the 
> process as much as possible.
>  
> Regards,
>  Rifaat
>  
>  
> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell  
> wrote:
> Thanks Rifaat. Process is as process does, right? I do kinda want to grumble 
> about WGCL having passed already but that's mostly because replying to these 
> kinds of threads is hard for me and I'll just get over it...
>  
> As far as I understand things, the security concerns come into play when the 
> client is being told the by the resource how to identity the resource like is 
> described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and 
> using the actual location in that context ,along with some other checks 
> prescribed in that draft, prevents the kind of issues John described earlier 
> in the thread. 
> 
> In cases where the client knows the resource a priori or out-of-band or 
> configured or whatever, I don't think the same security concerns arise. And 
> using such a known value, be it an actual location or logical representation, 
> would be okay.
> 
> The resource-indicators draft is admittedly somewhat location-centric in how 
> it talks about the value of the 'resource' parameter. But ultimately it 
> defines it as an absolute URI that indicates the location of the target 
> service or resource where access is being requested. A location can be 
> varying shades of abstract and I'd say that using a URI as 'resource' 
> parameter value that's a logical identifier that points to some resource is 
> well within the bounds of the draft.
>  
> So maybe the draft is okay as is?
>  
> Or perhaps that's too much to be left as an exerciser to the reader?  And 
> some text should be added and/or adjusted so the resource-indicators draft 
> would be a little more open/clear about the parameter value potentially being 
> more of a logical or abstract identifier and not necessarily a network 
> addressable URL?
>  
>  
>  
> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef  
> wrote:
> I wouldn't worry too much about the process.
> If it makes sense to update the document, then feel free to do that.
>  
> Regards,
>  Rifaat
>  
>  
> On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:
> Yes the logical resource can be provided by &

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

[Mike Jones]

I also agree that “resource” should be a specific network-addressable URL 
whereas a separate audience parameter (like “aud” in JWTs) can refer to one or 
more logical resources.  They are different, if related, things.

Note that the ACE WG is proposing to register a logical audience parameter 
“req_aud” in https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - 
partly based on feedback from OAuth WG members.  This is a general OAuth 
parameter, which any OAuth deployment will be able to use.

I therefore believe that no changes are needed to 
draft-ietf-oauth-resource-indicators, as the logical audience work is already 
happening in another draft.

  -- Mike

From: OAuth  On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell 
Cc: Vittorio Bertocci ; IETF oauth WG 

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

We need to decide if we want to make a change.

For security we are location centric.

I prefer to keep resource location separate from logical audience that can be a 
scope or other parameter.

If becomes harder for people to use the parameter correctly if we are too 
flexible.

I would rather have a separate logical audience parameter if we think we want 
one.

John B.

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell 
mailto:bcampb...@pingidentity.com> wrote:
No apology needed, Rifaat. And I apologize if what I said came off the wrong 
way. I was just trying to make light of the situation. And I agree that we 
should not be hamstrung by the process and there are times when it makes sense 
to be flexible with things.

On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Sorry Brian, I was not clear with my statement.
I meant to say that we should not allow the process to prevent the WG from 
producing a quality document without issues, assuming there is an issue in the 
first place.
Ideally we want to get these identified during the WGLC, but things happen and 
sometimes the WG misses something.

I hear you and agree that this make things difficult for authors. We will make 
sure that this does not become the norm, and we will try to stick to the 
process as much as possible.

Regards,
 Rifaat


On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat. Process is as process does, right? I do kinda want to grumble 
about WGCL having passed already but that's mostly because replying to these 
kinds of threads is hard for me and I'll just get over it...

As far as I understand things, the security concerns come into play when the 
client is being told the by the resource how to identity the resource like is 
described in https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and 
using the actual location in that context ,along with some other checks 
prescribed in that draft, prevents the kind of issues John described earlier in 
the thread.

In cases where the client knows the resource a priori or out-of-band or 
configured or whatever, I don't think the same security concerns arise. And 
using such a known value, be it an actual location or logical representation, 
would be okay.

The resource-indicators draft is admittedly somewhat location-centric in how it 
talks about the value of the 'resource' parameter. But ultimately it defines it 
as an absolute URI that indicates the location of the target service or 
resource where access is being requested. A location can be varying shades of 
abstract and I'd say that using a URI as 'resource' parameter value that's a 
logical identifier that points to some resource is well within the bounds of 
the draft.

So maybe the draft is okay as is?

Or perhaps that's too much to be left as an exerciser to the reader?  And some 
text should be added and/or adjusted so the resource-indicators draft would be 
a little more open/clear about the parameter value potentially being more of a 
logical or abstract identifier and not necessarily a network addressable URL?



On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
I wouldn't worry too much about the process.
If it makes sense to update the document, then feel free to do that.

Regards,
 Rifaat


On Fri, Jan 18, 2019 at 3:08 PM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
Yes the logical resource can be provided by "scope"

Some implementations like Ping and Auth0 have been adding another parameter 
"aud" to identify the logical resource and then using scopes to define 
permissions to the resource.

Fortunately, we are using a different parameter name so not stepping on that..

We could go back and try to add text explaining the difference, but we are 
quite late in the process.

I agree that a logical resource parameter may be helpful, but perhaps it should 
be a separate draft.

John B.

On Fri, Jan

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

[John Bradley]

We need to decide if we want to make a change.

For security we are location centric.

I prefer to keep resource location separate from logical audience that can
be a scope or other parameter.

If becomes harder for people to use the parameter correctly if we are too
flexible.

I would rather have a separate logical audience parameter if we think we
want one.

John B.

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell  No apology needed, Rifaat. And I apologize if what I said came off the
> wrong way. I was just trying to make light of the situation. And I agree
> that we should not be hamstrung by the process and there are times when it
> makes sense to be flexible with things.
>
> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef 
> wrote:
>
>> Sorry Brian, I was not clear with my statement.
>> I meant to say that we should not allow the process to prevent the WG
>> from producing a quality document without issues, assuming there is an
>> issue in the first place.
>> Ideally we want to get these identified during the WGLC, but things
>> happen and sometimes the WG misses something.
>>
>> I hear you and agree that this make things difficult for authors. We will
>> make sure that this does not become the norm, and we will try to stick to
>> the process as much as possible.
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Thanks Rifaat. Process is as process does, right? I do kinda want to
>>> grumble about WGCL having passed already but that's mostly because replying
>>> to these kinds of threads is hard for me and I'll just get over it...
>>>
>>> As far as I understand things, the security concerns come into play when
>>> the client is being told the by the resource how to identity the resource
>>> like is described in
>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using
>>> the actual location in that context ,along with some other checks
>>> prescribed in that draft, prevents the kind of issues John described
>>> earlier in the thread.
>>>
>>> In cases where the client knows the resource a priori or out-of-band or
>>> configured or whatever, I don't think the same security concerns arise. And
>>> using such a known value, be it an actual location or logical
>>> representation, would be okay.
>>>
>>> The resource-indicators draft is admittedly somewhat location-centric in
>>> how it talks about the value of the 'resource' parameter. But ultimately it
>>> defines it as an absolute URI that indicates the location of the target
>>> service or resource where access is being requested. A location can be
>>> varying shades of abstract and I'd say that using a URI as 'resource'
>>> parameter value that's a logical identifier that points to some resource is
>>> well within the bounds of the draft.
>>>
>>> So maybe the draft is okay as is?
>>>
>>> Or perhaps that's too much to be left as an exerciser to the reader?
>>> And some text should be added and/or adjusted so the resource-indicators
>>> draft would be a little more open/clear about the parameter value
>>> potentially being more of a logical or abstract identifier and not
>>> necessarily a network addressable URL?
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <
>>> rifaat.i...@gmail.com> wrote:
>>>
>>>> I wouldn't worry too much about the process.
>>>> If it makes sense to update the document, then feel free to do that.
>>>>
>>>> Regards,
>>>>  Rifaat
>>>>
>>>>
>>>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:
>>>>
>>>>> Yes the logical resource can be provided by "scope"
>>>>>
>>>>> Some implementations like Ping and Auth0 have been adding another
>>>>> parameter "aud" to identify the logical resource and then using scopes to
>>>>> define permissions to the resource.
>>>>>
>>>>> Fortunately, we are using a different parameter name so not stepping
>>>>> on that..
>>>>>
>>>>> We could go back and try to add text explaining the difference, but we
>>>>> are quite late in the process.
>>>>>
>>>>> I agree that a logical resource parameter may be helpful, but perhaps
>>>>> it should be a separate draft.
>>>>

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

[Rifaat Shekh-Yusef]

Sorry Brian, I was not clear with my statement.
I meant to say that we should not allow the process to prevent the WG from
producing a quality document without issues, assuming there is an issue in
the first place.
Ideally we want to get these identified during the WGLC, but things happen
and sometimes the WG misses something.

I hear you and agree that this make things difficult for authors. We will
make sure that this does not become the norm, and we will try to stick to
the process as much as possible.

Regards,
 Rifaat


On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell 
wrote:

> Thanks Rifaat. Process is as process does, right? I do kinda want to
> grumble about WGCL having passed already but that's mostly because replying
> to these kinds of threads is hard for me and I'll just get over it...
>
> As far as I understand things, the security concerns come into play when
> the client is being told the by the resource how to identity the resource
> like is described in
> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the
> actual location in that context ,along with some other checks prescribed in
> that draft, prevents the kind of issues John described earlier in the
> thread.
>
> In cases where the client knows the resource a priori or out-of-band or
> configured or whatever, I don't think the same security concerns arise. And
> using such a known value, be it an actual location or logical
> representation, would be okay.
>
> The resource-indicators draft is admittedly somewhat location-centric in
> how it talks about the value of the 'resource' parameter. But ultimately it
> defines it as an absolute URI that indicates the location of the target
> service or resource where access is being requested. A location can be
> varying shades of abstract and I'd say that using a URI as 'resource'
> parameter value that's a logical identifier that points to some resource is
> well within the bounds of the draft.
>
> So maybe the draft is okay as is?
>
> Or perhaps that's too much to be left as an exerciser to the reader?  And
> some text should be added and/or adjusted so the resource-indicators draft
> would be a little more open/clear about the parameter value potentially
> being more of a logical or abstract identifier and not necessarily a
> network addressable URL?
>
>
>
> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef 
> wrote:
>
>> I wouldn't worry too much about the process.
>> If it makes sense to update the document, then feel free to do that.
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:
>>
>>> Yes the logical resource can be provided by "scope"
>>>
>>> Some implementations like Ping and Auth0 have been adding another
>>> parameter "aud" to identify the logical resource and then using scopes to
>>> define permissions to the resource.
>>>
>>> Fortunately, we are using a different parameter name so not stepping on
>>> that..
>>>
>>> We could go back and try to add text explaining the difference, but we
>>> are quite late in the process.
>>>
>>> I agree that a logical resource parameter may be helpful, but perhaps it
>>> should be a separate draft.
>>>
>>> John B.
>>>
>>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
>>> richa...@amazon.com> wrote:
>>>
>>>> Doesn’t the “scope” parameter already provide a means of specifying a
>>>> logical identifier?
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Annabelle Richard Backman
>>>>
>>>> AWS Identity
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *OAuth  on behalf of Vittorio Bertocci
>>>> 
>>>> *Date: *Friday, January 18, 2019 at 5:47 AM
>>>> *To: *John Bradley 
>>>> *Cc: *IETF oauth WG 
>>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
>>>> draft-ietf-oauth-resource-indicators-01
>>>>
>>>>
>>>>
>>>> Thanks John for the background.
>>>>
>>>> I agree that from the client validation PoV, having an identifier
>>>> corresponding to a location makes things more solid.
>>>>
>>>> That said: the use of logical identifiers is widespread, as it has
>>>> significant practical advantages (think of services that assign generated
>>>> hosting URLs only at deployment time, or services that are somehow grouped
>>>> under the same logical aud

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

[Brian Campbell]

Thanks Rifaat. Process is as process does, right? I do kinda want to
grumble about WGCL having passed already but that's mostly because replying
to these kinds of threads is hard for me and I'll just get over it...

As far as I understand things, the security concerns come into play when
the client is being told the by the resource how to identity the resource
like is described in
https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and using the
actual location in that context ,along with some other checks prescribed in
that draft, prevents the kind of issues John described earlier in the
thread.

In cases where the client knows the resource a priori or out-of-band or
configured or whatever, I don't think the same security concerns arise. And
using such a known value, be it an actual location or logical
representation, would be okay.

The resource-indicators draft is admittedly somewhat location-centric in
how it talks about the value of the 'resource' parameter. But ultimately it
defines it as an absolute URI that indicates the location of the target
service or resource where access is being requested. A location can be
varying shades of abstract and I'd say that using a URI as 'resource'
parameter value that's a logical identifier that points to some resource is
well within the bounds of the draft.

So maybe the draft is okay as is?

Or perhaps that's too much to be left as an exerciser to the reader?  And
some text should be added and/or adjusted so the resource-indicators draft
would be a little more open/clear about the parameter value potentially
being more of a logical or abstract identifier and not necessarily a
network addressable URL?



On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef 
wrote:

> I wouldn't worry too much about the process.
> If it makes sense to update the document, then feel free to do that.
>
> Regards,
>  Rifaat
>
>
> On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:
>
>> Yes the logical resource can be provided by "scope"
>>
>> Some implementations like Ping and Auth0 have been adding another
>> parameter "aud" to identify the logical resource and then using scopes to
>> define permissions to the resource.
>>
>> Fortunately, we are using a different parameter name so not stepping on
>> that..
>>
>> We could go back and try to add text explaining the difference, but we
>> are quite late in the process.
>>
>> I agree that a logical resource parameter may be helpful, but perhaps it
>> should be a separate draft.
>>
>> John B.
>>
>> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
>> richa...@amazon.com> wrote:
>>
>>> Doesn’t the “scope” parameter already provide a means of specifying a
>>> logical identifier?
>>>
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of Vittorio Bertocci
>>> 
>>> *Date: *Friday, January 18, 2019 at 5:47 AM
>>> *To: *John Bradley 
>>> *Cc: *IETF oauth WG 
>>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
>>> draft-ietf-oauth-resource-indicators-01
>>>
>>>
>>>
>>> Thanks John for the background.
>>>
>>> I agree that from the client validation PoV, having an identifier
>>> corresponding to a location makes things more solid.
>>>
>>> That said: the use of logical identifiers is widespread, as it has
>>> significant practical advantages (think of services that assign generated
>>> hosting URLs only at deployment time, or services that are somehow grouped
>>> under the same logical audience across regions/environment/deployments)..
>>> People won't stop using logical identifiers, because they often have no
>>> alternative (generating new audiences on the fly at the AS every time you
>>> do a deployment and get assigned a new URL can be unfeasible). Leaving a
>>> widely used approach as exercise to the reader seems a disservice to the
>>> community, given that this might lead to vendors (for example Microsoft and
>>> Auth0) keeping their own proprietary parameters, or developers misusing the
>>> ones in place; would make it hard for SDK developers to provide libraries
>>> that work out of the box with different ASes; and so on.
>>>
>>> Would it be feasible to add such parameter directly in this spec? That
>>> would eliminate the interop issues, and also gives us a chance to fully
>>> warn people about the security shortcomings of choosing that approach.
>>>
>>>
>

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

[Rifaat Shekh-Yusef]

I wouldn't worry too much about the process.
If it makes sense to update the document, then feel free to do that.

Regards,
 Rifaat


On Fri, Jan 18, 2019 at 3:08 PM John Bradley  wrote:

> Yes the logical resource can be provided by "scope"
>
> Some implementations like Ping and Auth0 have been adding another
> parameter "aud" to identify the logical resource and then using scopes to
> define permissions to the resource.
>
> Fortunately, we are using a different parameter name so not stepping on
> that..
>
> We could go back and try to add text explaining the difference, but we are
> quite late in the process.
>
> I agree that a logical resource parameter may be helpful, but perhaps it
> should be a separate draft.
>
> John B.
>
> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
>
>> Doesn’t the “scope” parameter already provide a means of specifying a
>> logical identifier?
>>
>>
>>
>> --
>>
>> Annabelle Richard Backman
>>
>> AWS Identity
>>
>>
>>
>>
>>
>> *From: *OAuth  on behalf of Vittorio Bertocci
>> 
>> *Date: *Friday, January 18, 2019 at 5:47 AM
>> *To: *John Bradley 
>> *Cc: *IETF oauth WG 
>> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
>> draft-ietf-oauth-resource-indicators-01
>>
>>
>>
>> Thanks John for the background.
>>
>> I agree that from the client validation PoV, having an identifier
>> corresponding to a location makes things more solid.
>>
>> That said: the use of logical identifiers is widespread, as it has
>> significant practical advantages (think of services that assign generated
>> hosting URLs only at deployment time, or services that are somehow grouped
>> under the same logical audience across regions/environment/deployments).
>> People won't stop using logical identifiers, because they often have no
>> alternative (generating new audiences on the fly at the AS every time you
>> do a deployment and get assigned a new URL can be unfeasible). Leaving a
>> widely used approach as exercise to the reader seems a disservice to the
>> community, given that this might lead to vendors (for example Microsoft and
>> Auth0) keeping their own proprietary parameters, or developers misusing the
>> ones in place; would make it hard for SDK developers to provide libraries
>> that work out of the box with different ASes; and so on.
>>
>> Would it be feasible to add such parameter directly in this spec? That
>> would eliminate the interop issues, and also gives us a chance to fully
>> warn people about the security shortcomings of choosing that approach.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 17, 2019 at 4:32 PM John Bradley  wrote:
>>
>> We have discussed this.
>>
>> Audiences can certainly be logical identifiers.
>>
>> This however is a more specific location.  The AS is free to map the
>> location into some abstract audience in the AT.
>>
>> From a security point of view once the client starts asking for logical
>> resources it can be tricked into asking for the wrong one as a bad resource
>> can always lie about what logical resource it is.
>>
>> If we were to change it, how a client would validate it becomes
>> challenging to impossible.
>>
>> The AS is free to do whatever mapping of locations to identifiers it
>> needs for access tokens.
>>
>> Some implementations may want to keep additional parameters like logical
>> audience, but that should be separate from resource.
>>
>> John B.
>>
>> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
>>
>> Hi Vittorio,
>>
>>
>>
>> The text you quoted is copied form the abstract of the draft itself.
>>
>>
>>
>>
>>
>> *Authors,*
>>
>>
>>
>> Should the draft be updated to cover the logical identifier case?
>>
>>
>>
>> Regards,
>>
>>  Rifaat
>>
>>
>>
>>
>>
>> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci 
>> wrote:
>>
>> Hi Rifaat,
>>
>> one detail. The tech summary says
>>
>>
>>
>> An extension to the OAuth 2.0 Authorization Framework defining request
>>
>> parameters that enable a client to explicitly signal to an authorization 
>> server
>>
>> about the *location* of the protected resource(s) to which it is requesting
>>
>> access.
>>
>> But at least in the Microsoft implementati

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

[John Bradley]

Yes the logical resource can be provided by "scope"

Some implementations like Ping and Auth0 have been adding another parameter
"aud" to identify the logical resource and then using scopes to define
permissions to the resource.

Fortunately, we are using a different parameter name so not stepping on
that..

We could go back and try to add text explaining the difference, but we are
quite late in the process.

I agree that a logical resource parameter may be helpful, but perhaps it
should be a separate draft.

John B.

On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> Doesn’t the “scope” parameter already provide a means of specifying a
> logical identifier?
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Vittorio Bertocci
> 
> *Date: *Friday, January 18, 2019 at 5:47 AM
> *To: *John Bradley 
> *Cc: *IETF oauth WG 
> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> Thanks John for the background.
>
> I agree that from the client validation PoV, having an identifier
> corresponding to a location makes things more solid.
>
> That said: the use of logical identifiers is widespread, as it has
> significant practical advantages (think of services that assign generated
> hosting URLs only at deployment time, or services that are somehow grouped
> under the same logical audience across regions/environment/deployments).
> People won't stop using logical identifiers, because they often have no
> alternative (generating new audiences on the fly at the AS every time you
> do a deployment and get assigned a new URL can be unfeasible). Leaving a
> widely used approach as exercise to the reader seems a disservice to the
> community, given that this might lead to vendors (for example Microsoft and
> Auth0) keeping their own proprietary parameters, or developers misusing the
> ones in place; would make it hard for SDK developers to provide libraries
> that work out of the box with different ASes; and so on.
>
> Would it be feasible to add such parameter directly in this spec? That
> would eliminate the interop issues, and also gives us a chance to fully
> warn people about the security shortcomings of choosing that approach.
>
>
>
>
>
>
>
> On Thu, Jan 17, 2019 at 4:32 PM John Bradley  wrote:
>
> We have discussed this.
>
> Audiences can certainly be logical identifiers.
>
> This however is a more specific location.  The AS is free to map the
> location into some abstract audience in the AT.
>
> From a security point of view once the client starts asking for logical
> resources it can be tricked into asking for the wrong one as a bad resource
> can always lie about what logical resource it is.
>
> If we were to change it, how a client would validate it becomes
> challenging to impossible.
>
> The AS is free to do whatever mapping of locations to identifiers it needs
> for access tokens.
>
> Some implementations may want to keep additional parameters like logical
> audience, but that should be separate from resource.
>
> John B.
>
> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
>
> Hi Vittorio,
>
>
>
> The text you quoted is copied form the abstract of the draft itself.
>
>
>
>
>
> *Authors,*
>
>
>
> Should the draft be updated to cover the logical identifier case?
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci 
> wrote:
>
> Hi Rifaat,
>
> one detail. The tech summary says
>
>
>
> An extension to the OAuth 2.0 Authorization Framework defining request
>
> parameters that enable a client to explicitly signal to an authorization 
> server
>
> about the *location* of the protected resource(s) to which it is requesting
>
> access.
>
> But at least in the Microsoft implementation, the resource identifier
> doesn't *have* to be a network addressable URL (and if it is, it doesn't
> strictly need to match the actual resource location). It can be a logical
> identifier, tho using the actual resource location there has benefits
> (domain ownership check, prevention of token forwarding etc).
>
> Same for Auth0, the audience parameter is a logical identifier rather than
> a location.
>
>
>
>
>
>
>
> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
>
>
> The following is the first shepherd write-up for
> the draft-ietf-oauth-resource-indicators-01 document.
>
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>
>
>

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

[Richard Backman, Annabelle]

Doesn’t the “scope” parameter already provide a means of specifying a logical 
identifier?

--
Annabelle Richard Backman
AWS Identity


From: OAuth  on behalf of Vittorio Bertocci 

Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01

Thanks John for the background.
I agree that from the client validation PoV, having an identifier corresponding 
to a location makes things more solid.
That said: the use of logical identifiers is widespread, as it has significant 
practical advantages (think of services that assign generated hosting URLs only 
at deployment time, or services that are somehow grouped under the same logical 
audience across regions/environment/deployments). People won't stop using 
logical identifiers, because they often have no alternative (generating new 
audiences on the fly at the AS every time you do a deployment and get assigned 
a new URL can be unfeasible). Leaving a widely used approach as exercise to the 
reader seems a disservice to the community, given that this might lead to 
vendors (for example Microsoft and Auth0) keeping their own proprietary 
parameters, or developers misusing the ones in place; would make it hard for 
SDK developers to provide libraries that work out of the box with different 
ASes; and so on.
Would it be feasible to add such parameter directly in this spec? That would 
eliminate the interop issues, and also gives us a chance to fully warn people 
about the security shortcomings of choosing that approach.



On Thu, Jan 17, 2019 at 4:32 PM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

We have discussed this.

Audiences can certainly be logical identifiers.

This however is a more specific location.  The AS is free to map the location 
into some abstract audience in the AT.

From a security point of view once the client starts asking for logical 
resources it can be tricked into asking for the wrong one as a bad resource can 
always lie about what logical resource it is.

If we were to change it, how a client would validate it becomes challenging to 
impossible.

The AS is free to do whatever mapping of locations to identifiers it needs for 
access tokens.

Some implementations may want to keep additional parameters like logical 
audience, but that should be separate from resource.

John B.
On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.


Authors,

Should the draft be updated to cover the logical identifier case?

Regards,
 Rifaat


On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci 
mailto:vitto...@auth0.com>> wrote:
Hi Rifaat,
one detail. The tech summary says


An extension to the OAuth 2.0 Authorization Framework defining request

parameters that enable a client to explicitly signal to an authorization server

about the location of the protected resource(s) to which it is requesting

access.
But at least in the Microsoft implementation, the resource identifier doesn't 
have to be a network addressable URL (and if it is, it doesn't strictly need to 
match the actual resource location). It can be a logical identifier, tho using 
the actual resource location there has benefits (domain ownership check, 
prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier rather than a 
location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
All,

The following is the first shepherd write-up for the 
draft-ietf-oauth-resource-indicators-01 document.
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/

Please, take a look and let me know if I missed anything.

Regards,
 Rifaat

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



___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

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

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

[Vittorio Bertocci]

Thanks John for the background.
I agree that from the client validation PoV, having an identifier
corresponding to a location makes things more solid.
That said: the use of logical identifiers is widespread, as it has
significant practical advantages (think of services that assign generated
hosting URLs only at deployment time, or services that are somehow grouped
under the same logical audience across regions/environment/deployments).
People won't stop using logical identifiers, because they often have no
alternative (generating new audiences on the fly at the AS every time you
do a deployment and get assigned a new URL can be unfeasible). Leaving a
widely used approach as exercise to the reader seems a disservice to the
community, given that this might lead to vendors (for example Microsoft and
Auth0) keeping their own proprietary parameters, or developers misusing the
ones in place; would make it hard for SDK developers to provide libraries
that work out of the box with different ASes; and so on.
Would it be feasible to add such parameter directly in this spec? That
would eliminate the interop issues, and also gives us a chance to fully
warn people about the security shortcomings of choosing that approach.



On Thu, Jan 17, 2019 at 4:32 PM John Bradley  wrote:

> We have discussed this.
>
> Audiences can certainly be logical identifiers.
>
> This however is a more specific location.  The AS is free to map the
> location into some abstract audience in the AT.
>
> From a security point of view once the client starts asking for logical
> resources it can be tricked into asking for the wrong one as a bad resource
> can always lie about what logical resource it is.
>
> If we were to change it, how a client would validate it becomes
> challenging to impossible.
>
> The AS is free to do whatever mapping of locations to identifiers it needs
> for access tokens.
>
> Some implementations may want to keep additional parameters like logical
> audience, but that should be separate from resource.
>
> John B.
> On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:
>
> Hi Vittorio,
>
> The text you quoted is copied form the abstract of the draft itself.
>
>
> *Authors,*
>
> Should the draft be updated to cover the logical identifier case?
>
> Regards,
>  Rifaat
>
>
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci 
> wrote:
>
>> Hi Rifaat,
>> one detail. The tech summary says
>>
>> An extension to the OAuth 2.0 Authorization Framework defining request
>> parameters that enable a client to explicitly signal to an authorization 
>> server
>> about the *location* of the protected resource(s) to which it is requesting
>> access.
>>
>> But at least in the Microsoft implementation, the resource identifier
>> doesn't *have* to be a network addressable URL (and if it is, it doesn't
>> strictly need to match the actual resource location). It can be a logical
>> identifier, tho using the actual resource location there has benefits
>> (domain ownership check, prevention of token forwarding etc).
>> Same for Auth0, the audience parameter is a logical identifier rather
>> than a location.
>>
>>
>>
>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> The following is the first shepherd write-up for
>>> the draft-ietf-oauth-resource-indicators-01 document.
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>>>
>>> Please, take a look and let me know if I missed anything.
>>>
>>> Regards,
>>>  Rifaat
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

We have discussed this.

Audiences can certainly be logical identifiers.

This however is a more specific location.  The AS is free to map the 
location into some abstract audience in the AT.


From a security point of view once the client starts asking for logical 
resources it can be tricked into asking for the wrong one as a bad 
resource can always lie about what logical resource it is.


If we were to change it, how a client would validate it becomes 
challenging to impossible.


The AS is free to do whatever mapping of locations to identifiers it 
needs for access tokens.


Some implementations may want to keep additional parameters like logical 
audience, but that should be separate from resource.


John B.

On 1/17/2019 9:56 AM, Rifaat Shekh-Yusef wrote:

Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.

*
*
*Authors,*

Should the draft be updated to cover the logical identifier case?

Regards,
 Rifaat


On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci > wrote:


Hi Rifaat,
one detail. The tech summary says

An extension to the OAuth 2.0 Authorization Framework defining request
parameters that enable a client to explicitly signal to an authorization 
server
about the*location*  of the protected resource(s) to which it is requesting
access.

But at least in the Microsoft implementation, the resource
identifier doesn't /have/ to be a network addressable URL (and if
it is, it doesn't strictly need to match the actual resource
location). It can be a logical identifier, tho using the actual
resource location there has benefits (domain ownership check,
prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier
rather than a location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef
mailto:rifaat.i...@gmail.com>> wrote:

All,

The following is the first shepherd write-up for
the draft-ietf-oauth-resource-indicators-01 document.

https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/

Please, take a look and let me know if I missed anything.

Regards,
 Rifaat

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


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

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

[Rifaat Shekh-Yusef]

Hi Vittorio,

The text you quoted is copied form the abstract of the draft itself.


*Authors,*

Should the draft be updated to cover the logical identifier case?

Regards,
 Rifaat


On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci 
wrote:

> Hi Rifaat,
> one detail. The tech summary says
>
> An extension to the OAuth 2.0 Authorization Framework defining request
> parameters that enable a client to explicitly signal to an authorization 
> server
> about the *location* of the protected resource(s) to which it is requesting
> access.
>
> But at least in the Microsoft implementation, the resource identifier
> doesn't *have* to be a network addressable URL (and if it is, it doesn't
> strictly need to match the actual resource location). It can be a logical
> identifier, tho using the actual resource location there has benefits
> (domain ownership check, prevention of token forwarding etc).
> Same for Auth0, the audience parameter is a logical identifier rather than
> a location.
>
>
>
> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> The following is the first shepherd write-up for
>> the draft-ietf-oauth-resource-indicators-01 document.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>>
>> Please, take a look and let me know if I missed anything.
>>
>> Regards,
>>  Rifaat
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertocci]

Hi Rifaat,
one detail. The tech summary says

An extension to the OAuth 2.0 Authorization Framework defining request
parameters that enable a client to explicitly signal to an authorization server
about the *location* of the protected resource(s) to which it is requesting
access.

But at least in the Microsoft implementation, the resource identifier
doesn't *have* to be a network addressable URL (and if it is, it doesn't
strictly need to match the actual resource location). It can be a logical
identifier, tho using the actual resource location there has benefits
(domain ownership check, prevention of token forwarding etc).
Same for Auth0, the audience parameter is a logical identifier rather than
a location.



On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> The following is the first shepherd write-up for
> the draft-ietf-oauth-resource-indicators-01 document.
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>
> Please, take a look and let me know if I missed anything.
>
> Regards,
>  Rifaat
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

Thanks Filip!

I will update the write-up accordingly.

Regards,
 Rifaat


On Wed, Jan 16, 2019 at 4:51 PM Filip Skokan  wrote:

> Hello Rifaat,
>
> The Auth0 link points to a different implementation. Here are  two correct
> entries replacing the one you wrote down.
>
> So
>
> * Auth0 has an implementation but with a different parameter name
> ("audience"):
> https://auth0.com/docs/api/authentication#authorize-application
>
> * Node.JS Open Source oidc-provider implements the draft in full
>
> https://github.com/panva/node-oidc-provider/blob/master/docs/configuration.md#featuresresourceindicators
>
> Sorry if my message caused confusion before.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 16 Jan 2019 at 22:33, Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> The following is the first shepherd write-up for
>> the draft-ietf-oauth-resource-indicators-01 document.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>>
>> Please, take a look and let me know if I missed anything.
>>
>> Regards,
>>  Rifaat
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Filip Skokan]

Hello Rifaat,

The Auth0 link points to a different implementation. Here are  two correct
entries replacing the one you wrote down.

So

* Auth0 has an implementation but with a different parameter name
("audience"):
https://auth0.com/docs/api/authentication#authorize-application

* Node.JS Open Source oidc-provider implements the draft in full
https://github.com/panva/node-oidc-provider/blob/master/docs/configuration.md#featuresresourceindicators

Sorry if my message caused confusion before.

S pozdravem,
*Filip Skokan*


On Wed, 16 Jan 2019 at 22:33, Rifaat Shekh-Yusef 
wrote:

> All,
>
> The following is the first shepherd write-up for
> the draft-ietf-oauth-resource-indicators-01 document.
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
>
> Please, take a look and let me know if I missed anything.
>
> Regards,
>  Rifaat
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

All,

The following is the first shepherd write-up for
the draft-ietf-oauth-resource-indicators-01 document.
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/

Please, take a look and let me know if I missed anything.

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