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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 16 Jan 2019 16:32:28 -0500

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

---

From: Filip Skokan <[email-masked]>
Date: Wed, 16 Jan 2019 22:51:12 +0100

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 <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 16 Jan 2019 16:53:30 -0500

Thanks Filip!

I will update the write-up accordingly.

Regards,
 Rifaat

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 17 Jan 2019 10:18:55 -0300

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.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 17 Jan 2019 12:56:32 -0500

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

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Jan 2019 11:31:46 -0800

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:
> *
> *
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Rifaat,
>     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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         All,
>
>         [email-masked] <mailto:[email-masked]>

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 18 Jan 2019 10:46:29 -0300

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 <[email-masked]> wrote:

> resources it can be tricked into asking for the wrong one as a bad resource
> can always lie about what logical resource it is.
>
> The AS is free to do whatever mapping of locations to identifiers it needs
> for access tokens.
>
>> Same for Auth0, the audience parameter is a logical identifier rather
>> than a location.
>>
>>
>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 18 Jan 2019 19:37:19 +0000

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

--
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of Vittorio Bertocci <Vittorio=[email-masked]>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <[email-masked]>
Cc: IETF oauth WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

We have discussed this.

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.

Authors,

Regards,
 Rifaat

On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rifaat,
one detail. The tech summary says

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 <[email-masked]<mailto:[email-masked]>> 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/

Regards,
 Rifaat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf..org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Jan 2019 17:07:52 -0300

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 <
[email-masked]> wrote:

> *From: *OAuth <[email-masked]> on behalf of Vittorio Bertocci
> <Vittorio=[email-masked]>
> *Date: *Friday, January 18, 2019 at 5:47 AM
> *To: *John Bradley <[email-masked]>
> *Cc: *IETF oauth WG <[email-masked]>
> *Subject: *Re: [OAUTH-WG] Shepherd write-up for
> draft-ietf-oauth-resource-indicators-01
>
>
>
> https://www.ietf..org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 18 Jan 2019 15:18:21 -0500

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 <[email-masked]> wrote:

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 18 Jan 2019 15:35:30 -0700

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 <[email-masked]>
wrote:

>> We could go back and try to add text explaining the difference, but we
>> are quite late in the process.
>>
>>> 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).
>>>
>>> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <
>>> [email-masked]> wrote:
>>>
>>> All,
>>>
>>>
>>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 18 Jan 2019 20:22:23 -0500

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 <[email-masked]>
wrote:

>>>> Some implementations may want to keep additional parameters like
>>>> logical audience, but that should be separate from resource.
>>>>
>>>> John B.
>>>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Brian Campbell <[email-masked]>
Date: Sat, 19 Jan 2019 07:41:31 -0700

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 <[email-masked]>
wrote:

>> 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.
>>
>>>> I agree that a logical resource parameter may be helpful, but perhaps
>>>> it should be a separate draft.
>>>>
>>>> John B.
>>>>
>>>>> 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

---

From: John Bradley <[email-masked]>
Date: Sat, 19 Jan 2019 14:00:48 -0300

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 <[email-masked]
wrote:

>> 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.
>>
>> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <
>> [email-masked]> wrote:
>>
>>> 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 <
>>>>> Fortunately, we are using a different parameter name so not stepping
>>>>> on that..
>>>>>
>>>>>> *From: *OAuth <[email-masked]> on behalf of Vittorio
>>>>>> Bertocci <Vittorio=[email-masked]>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 19 Jan 2019 20:34:13 +0000

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 <[email-masked]> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <[email-masked]>
Cc: Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

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 <[email-masked]<mailto:[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Doesn’t the “scope” parameter already provide a means of specifying a logical identifier?

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

We have discussed this.

John B.

Authors,

Regards,
 Rifaat

access.

Regards,
 Rifaat

OAuth mailing list

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Phil Hunt <[email-masked]>
Date: Sat, 19 Jan 2019 12:38:43 -0800

+1 to Mike and John’s comments. 

Phil

> On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <[email-masked] wrote:
> On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef <[email-masked]> wrote:
> On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell <[email-masked]> wrote:
> On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef <[email-masked]> wrote:
> On Fri, Jan 18, 2019 at 4:38 PM Richard Backman, Annabelle <[email-masked]> wrote:
> On Thu, Jan 17, 2019 at 8:19 AM Vittorio Bertocci <[email-masked]> wrote:
> Hi Rifaat,
> On Wed, Jan 16, 2019 at 6:32 PM Rifaat Shekh-Yusef <[email-masked]> wrote:
> All,
>  
> https://www.ietf..org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Sun, 20 Jan 2019 15:59:39 -0800

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 <[email-masked]> wrote:

> On Jan 19, 2019, at 12:34 PM, Mike Jones <
> Michael.Jones=[email-masked]> 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 <[email-masked]> *On Behalf Of * John Bradley
> *Sent:* Saturday, January 19, 2019 9:01 AM
> *To:* Brian Campbell <[email-masked]>
> *Cc:* Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth
> WG <[email-masked]>
> *Subject:* Re: [OAUTH-WG] Shepherd write-up for
> wrong way. I was just trying to make light of the situation.. And I agree
> <Vittorio=[email-masked] <[email-masked]>>
> review, use, distribution or disclosure by others is strictly prohibited..

---

From: John Bradley <[email-masked]>
Date: Sun, 20 Jan 2019 17:58:32 -0800

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.
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Jan 19, 2019, at 12:34 PM, Mike Jones
>     <Michael.Jones=[email-masked]
>     <mailto:Michael.Jones=[email-masked]>> 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.
>>
>>     draft-ietf-oauth-resource-indicators, as the logical audience
>>     work is already happening in another draft.
>>
>>     -- Mike
>>
>>     *From:* OAuth <[email-masked]
>>     <mailto:[email-masked]>> *On Behalf Of * John Bradley
>>     *To:* Brian Campbell <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* Vittorio Bertocci <Vittorio=[email-masked]
>>     <mailto:Vittorio=[email-masked]>>; IETF oauth WG
>>     <[email-masked] <mailto:[email-masked]>>
>>     On Sat, Jan 19, 2019, 11:41 AM Brian Campbell
>>     <[email-masked] <mailto:[email-masked]>
>>     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
>>             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
>>             <[email-masked]
>>             <mailto:[email-masked]>> 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.
>>
>>                 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
>>                 <[email-masked]
>>                     On Fri, Jan 18, 2019 at 3:08 PM John Bradley
>>                     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                         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 <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>                             Doesn’t the “scope” parameter already
>>                             provide a means of specifying a logical
>>                             identifier?
>>
>>                             -- 
>>
>>                             *From: *OAuth <[email-masked]
>>                             <mailto:[email-masked]>> on
>>                             behalf of Vittorio Bertocci
>>                             <Vittorio=[email-masked]
>>                             <mailto:[email-masked]>>
>>                             *To: *John Bradley <[email-masked]
>>                             <mailto:[email-masked]>>
>>                             *Cc: *IETF oauth WG <[email-masked]
>>                             <mailto:[email-masked]>>
>>                             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 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 <[email-masked]
>>                             <mailto:[email-masked]>> wrote:
>>
>>                                 We have discussed this.
>>
>>                                 If we were to change it, how a client
>>                                 would validate it becomes challenging
>>                                 to impossible.
>>
>>                                     The text you quoted is copied
>>                                     form the abstract of the draft
>>                                     itself.
>>
>>                                     *Authors,*
>>
>>                                     On Thu, Jan 17, 2019 at 8:19 AM
>>                                     Vittorio Bertocci
>>                                     <[email-masked]
>>                                         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.
>>
>>                                         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.
>>
>>                                         <[email-masked]
>>                                         <mailto:[email-masked]>>
>>                                         wrote:
>>
>>                                             All,
>>
>>                                             The following is the
>>                                             first shepherd write-up
>>                                             for
>>                                             Please, take a look and
>>                                             let me know if I missed
>>                                             anything.
>>                                             <mailto:[email-masked]>
>>                 */CONFIDENTIALITY NOTICE: This email may contain
>>                 confidential and privileged material for the sole use
>>                 of the intended recipient(s). Any review, use,
>>                 distribution or disclosure by others is strictly
>>                 prohibited.  If you have received this communication
>>                 in error, please notify the sender immediately by
>>                 e-mail and delete the message and any file
>>                 attachments from your computer. Thank you./*
>>
>>
>>         */CONFIDENTIALITY NOTICE: This email may contain confidential
>>         and privileged material for the sole use of the intended
>>         recipient(s). Any review, use, distribution or disclosure by
>>         others is strictly prohibited..  If you have received this
>>         communication in error, please notify the sender immediately
>>         by e-mail and delete the message and any file attachments
>>         from your computer. Thank you./*
>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Sun, 20 Jan 2019 18:39:06 -0800

[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 <[email-masked]> 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.
>
> 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.
>
>
>
>> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 - partly
>> based on feedback from OAuth WG members.  This is a general OAuth
>> *Cc:* Vittorio Bertocci <Vittorio=[email-masked]>; IETF
>> oauth WG <[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 21 Jan 2019 08:31:39 -0700

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 <[email-masked]>
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.
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>

---

From: John Bradley <[email-masked]>
Date: Mon, 21 Jan 2019 12:52:48 -0300

Thanks,   This is the first mention that I have heard that resource was
already in use by someone.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 21 Jan 2019 12:34:54 -0500

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 <bcampbell=
[email-masked]> wrote:

>> 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.
>>> with the concept of logical resource in a standard compliant way, hence it
>>> 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.
>>>
>>>> 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
>>>> 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
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 21 Jan 2019 16:38:47 -0800

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 <[email-masked]>
wrote:

> Brian, Vittorio,
>
> To move this discussion forward, can you guys suggest some text to make
> the logical identifier usage clearer?
>
> Regards,
>  Rifaat
>
>
>>>> In my former position I wasn't monitoring those discussions hence I didn't
>>>> documents is better than ignoring he logical identifier case altogether,
>>>> however I think that not acknowledging the logical id case
>>>>> 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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 21 Jan 2019 20:35:49 -0500

Thank you guys!

On Monday, January 21, 2019, Vittorio Bertocci <[email-masked]> 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.
>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> draft-ietf-oauth-resource-indicators, as the logical audience work
>>>>>> is already happening in another draft.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                                           -- Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Bertocci <Vittorio=[email-masked]
>>>>>> <[email-masked]>>

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Jan 2019 18:19:31 +0000

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 <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Monday, January 21, 2019 5:36 PM
To: Vittorio Bertocci <[email-masked]>
Cc: Brian Campbell <bcampbell=[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

Thank you guys!

On Monday, January 21, 2019, Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <bcampbell=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
+1 to Mike and John’s comments.
Phil

On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> 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.

                                                          -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <Vittorio=[email-masked]<mailto:Vittorio=[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

John B.

On Sat, Jan 19, 2019, 11:41 AM Brian Campbell <[email-masked]<mailto:[email-masked]> 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.

Regards,
 Rifaat

Regards,
 Rifaat

John B.

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>

We have discussed this.

John B.

Authors,

Regards,
 Rifaat

access.

Regards,
 Rifaat

OAuth mailing list

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited...  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 23 Jan 2019 08:44:43 -0800

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 <[email-masked]>
wrote:

>>>>>> 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
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-distributed-01 and
>>>>>>> using the actual location in that context ,along with some other checks
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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).
>>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Wed, 23 Jan 2019 12:24:47 -0500

I worry about these kind of references because it does not give clear 
guidance to developers on what to do. It also significantly increases 
the complexity of implementing something correctly because of all the 
specs that have to be followed in order to understand the full picture 
of what's required. The current "spec set" is already pretty large for 
someone starting out with OAuth2/JOSE/etc.

I'd much prefer we add non-normative guidance in the current doc to make 
the use case for logical resource identifiers clear as that will most 
likely lead to better implementations and deployments.

Thanks,
George

On 1/22/19 1:19 PM, Mike Jones wrote:
>
> I think that a non-normative reference to  “req_aud” in 
> https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 
> <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 <[email-masked]> *On Behalf Of * Rifaat Shekh-Yusef
> *Sent:* Monday, January 21, 2019 5:36 PM
> *To:* Vittorio Bertocci <[email-masked]>
> *Cc:* Brian Campbell <bcampbell=[email-masked]>; 
> IETF oauth WG <[email-masked]>
>     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
>         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
>         <bcampbell=[email-masked]
>         <mailto:[email-masked]>> 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
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 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.
>
>                 On Sun, Jan 20, 2019 at 17:58 John Bradley
>                         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
>                         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,
>                         In summary: creating two different parameters
>                         in two different documents is better than
>                         ignoring he logical identifier case
>                         in oauth-resource-indicators is going to
>                         create confusion and ultimately not be as
>                         useful to the developer community as it could be.
>
>                                 “req_aud” in
>                                 https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01
>                                 - partly based on feedback from OAuth
>                                 <mailto:[email-masked]>> *On
>                                 Behalf Of *John Bradley
>                                 <mailto:Vittorio=[email-masked]>>;
>                                 IETF oauth WG <[email-masked]
>                                 <mailto:[email-masked]>>
>                                 I prefer to keep resource location
>                                 separate from logical audience that
>                                 can be a scope or other parameter.
>
>                                 I would rather have a separate logical
>                                 audience parameter if we think we want
>                                 one.
>
>                                 John B.
>
>                                 <mailto:[email-masked]> wrote:
>
>                                     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.
>
>                                     <mailto:[email-masked]>> wrote:
>
>                                         but things happen and
>                                         sometimes the WG misses
>                                         something.
>                                             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
>                                             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
>                                             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.
>
>                                             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
>                                             identifier and not
>                                                 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
>                                                 <[email-masked]
>                                                     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
>                                                     different parameter
>                                                     name so not
>                                                     stepping on that..
>                                                     We could go back
>                                                     and try to add
>                                                     text explaining
>                                                     the difference,
>                                                     but we are quite
>                                                     I agree that a
>                                                     logical resource
>                                                     parameter may be
>                                                     helpful, but
>                                                     perhaps it should
>                                                     be a separate draft.
>                                                     On Fri, Jan 18,
>                                                     2019 at 4:38 PM
>                                                     Richard Backman,
>                                                     Annabelle
>                                                     <[email-masked]
>                                                         Doesn’t the
>                                                         “scope”
>                                                         parameter
>                                                         already
>                                                         provide a
>                                                         means of
>                                                         specifying a
>                                                         logical
>                                                         Annabelle
>                                                         Richard Backman
>                                                         <mailto:[email-masked]>>
>                                                         on behalf of
>                                                         Vittorio
>                                                         Bertocci
>                                                         *Date:
>                                                         *Friday,
>                                                         January 18,
>                                                         2019 at 5:47 AM
>                                                         *To: *John
>                                                         *Cc: *IETF
>                                                         oauth WG
>                                                         *Subject: *Re:
>                                                         [OAUTH-WG]
>                                                         Shepherd
>                                                         write-up for
>                                                         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
>                                                         <[email-masked]
>                                                             We have
>                                                             discussed
>                                                             this.
>                                                             Audiences
>                                                             can
>                                                             certainly
>                                                             be logical
>                                                             identifiers.
>                                                             This
>                                                             however is
>                                                             a more
>                                                             specific
>                                                             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.
>                                                             On
>                                                             1/17/2019
>                                                             9:56 AM,
>                                                             Shekh-Yusef
>                                                                 Hi
>                                                                 Vittorio,
>                                                                 The
>                                                                 text
>                                                                 you
>                                                                 quoted
>                                                                 is
>                                                                 copied
>                                                                 form
>                                                                 the
>                                                                 abstract
>                                                                 of the
>                                                                 draft
>                                                                 Should
>                                                                 the
>                                                                 draft
>                                                                 be
>                                                                 updated
>                                                                 to
>                                                                 cover
>                                                                 the
>                                                                 logical
>                                                                 identifier
>                                                                 case?
>                                                                 On
>                                                                 Thu,
>                                                                 Jan
>                                                                 17,
>                                                                 2019
>                                                                 at
>                                                                 8:19
>                                                                 AM
>                                                                 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
>                                                                     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
>                                                                     Auth0,
>                                                                     the
>                                                                     audience
>                                                                     parameter
>                                                                     is
>                                                                     a
>                                                                     logical
>                                                                     identifier
>                                                                     rather
>                                                                     than
>                                                                     a
>                                                                     On
>                                                                     Wed,
>                                                                     Jan
>                                                                     16,
>                                                                     2019
>                                                                     at
>                                                                     6:32
>                                                                     PM
>                                                                     Shekh-Yusef
>                                                                         The
>                                                                         following
>                                                                         is
>                                                                         the
>                                                                         first
>                                                                         shepherd
>                                                                         write-up
>                                                                         Please,
>                                                                         take
>                                                                         a
>                                                                         look
>                                                                         and
>                                                                         let me
>                                                                         know
>                                                                         if
>                                                                         I
>                                                                         missed
>                                                                         OAuth
>                                                                         mailing
>                                                                         list
>                                                             OAuth
>                                                             mailing list
>                                             confidential and
>                                             privileged material for
>                                             the sole use of the
>                                             intended recipient(s). Any
>                                             review, use, distribution
>                                             or disclosure by others is
>                                             strictly prohibited. If
>                                             you have received this
>                                             communication in error,
>                                             please notify the sender
>                                             immediately by e-mail and
>                                             delete the message and any
>                                             file attachments from your
>                                             computer. Thank you./*
>
>
>                                     */CONFIDENTIALITY NOTICE: This
>                                     email may contain confidential and
>                                     privileged material for the sole
>                                     use of the intended recipient(s).
>                                     Any review, use, distribution or
>                                     disclosure by others is strictly
>                                     prohibited.. If you have received
>                                     this communication in error,
>                                     please notify the sender
>                                     immediately by e-mail and delete
>                                     the message and any file
>             confidential and privileged material for the sole use of
>             the intended recipient(s). Any review, use, distribution
>             or disclosure by others is strictly prohibited...  If you
>             have received this communication in error, please notify
>             the sender immediately by e-mail and delete the message
>             and any file attachments from your computer. Thank
>             you./*_______________________________________________
>             OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Wed, 23 Jan 2019 15:56:25 -0300

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 
> 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 
>         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.
>
>                 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.
>
>                     In Azure AD v1 & ADFS, that's resource. It could
>                     be used for both network and logical ids, with the
>                     (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.
>>                         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
>>                         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.
>>                         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
>>>                             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.
>>>
>>>                             - partly based on feedback from OAuth WG
>>>                             members. This is a general OAuth
>>>                             draft-ietf-oauth-resource-indicators, as
>>>                             the logical audience work is already
>>>                             happening in another draft.
>>>
>>>                             -- Mike
>>>
>>>                             Behalf Of * John Bradley
>>>                             separate from logical audience that can
>>>                             If becomes harder for people to use the
>>>                             parameter correctly if we are too flexible.
>>>
>>>                             audience parameter if we think we want one.
>>>
>>>                             John B.
>>>
>>>                                 agree that we should not be
>>>                                 are times when it makes sense to be
>>>                                 flexible with things.
>>>
>>>                                     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.
>>>
>>>                                     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
>>>
>>>                                         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
>>>                                         draft, prevents the kind of
>>>                                         issues John described
>>>                                         earlier in the thread.
>>>
>>>                                         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
>>>                                         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
>>>                                         being requested. A location
>>>                                         can be varying shades of
>>>                                         adjusted so the
>>>                                         parameter value potentially
>>>                                         being more of a logical or
>>>                                         abstract identifier and not
>>>                                         necessarily a network
>>>                                         addressable URL?
>>>
>>>                                             <[email-masked]
>>>                                                 Some implementations
>>>                                                 like Ping and Auth0
>>>                                                 have been adding
>>>                                                 another parameter
>>>                                                 "aud" to identify
>>>                                                 the logical resource
>>>                                                 name so not stepping
>>>                                                 explaining the
>>>                                                 difference, but we
>>>                                                 helpful, but perhaps
>>>                                                 at 4:38 PM Richard
>>>                                                     already provide
>>>                                                     a means of
>>>                                                     logical identifier?
>>>                                                     *Date: *Friday,
>>>                                                     January 18, 2019
>>>                                                     at 5:47 AM
>>>                                                     *Cc: *IETF oauth
>>>                                                     WG
>>>                                                     from the client
>>>                                                     validation PoV,
>>>                                                     having an
>>>                                                     corresponding to
>>>                                                     a location makes
>>>                                                     things more solid.
>>>                                                     assign generated
>>>                                                     deployment time,
>>>                                                     or services that
>>>                                                     the same logical
>>>                                                     (generating new
>>>                                                     audiences on the
>>>                                                     fly at the AS
>>>                                                     every time you
>>>                                                     do a deployment
>>>                                                     and get assigned
>>>                                                     a new URL can be
>>>                                                     Leaving a widely
>>>                                                     used approach as
>>>                                                     exercise to the
>>>                                                     reader seems a
>>>                                                     given that this
>>>                                                     might lead to
>>>                                                     work out of the
>>>                                                     box with
>>>                                                     feasible to add
>>>                                                     such parameter
>>>                                                     directly in this
>>>                                                     spec? That would
>>>                                                     interop issues,
>>>                                                     and also gives
>>>                                                     us a chance to
>>>                                                     people about the
>>>                                                     shortcomings of
>>>                                                     choosing that
>>>                                                     approach.
>>>                                                     On Thu, Jan 17,
>>>                                                     2019 at 4:32 PM
>>>                                                     John Bradley
>>>                                                     <[email-masked]
>>>                                                         discussed this.
>>>                                                         certainly be
>>>                                                         This however
>>>                                                         is a more
>>>                                                         free to map
>>>                                                         the location
>>>                                                         audience in
>>>                                                         the AT.
>>>                                                         resources it
>>>                                                         can be
>>>                                                         tricked into
>>>                                                         one as a bad
>>>                                                         resource can
>>>                                                         always lie
>>>                                                         about what
>>>                                                         resource it is.
>>>                                                         client would
>>>                                                         validate it
>>>                                                         becomes
>>>                                                         locations to
>>>                                                         it needs for
>>>                                                         access tokens.
>>>                                                         may want to
>>>                                                         keep
>>>                                                         like logical
>>>                                                         On 1/17/2019
>>>                                                             The text
>>>                                                             form the
>>>                                                             draft be
>>>                                                             to cover
>>>                                                             On Thu,
>>>                                                             Jan 17,
>>>                                                             2019 at
>>>                                                             8:19 AM
>>>                                                                 be a
>>>                                                                 be a
>>>                                                                 is a
>>>                                         the intended recipient(s).
>>>                                         Any review, use,
>>>                                         in error, please notify the
>>>                                         sender immediately by e-mail
>>>                                         and delete the message and
>>>                                         any file attachments from
>>>                                         your computer. Thank you./*
>>>
>>>
>>>                                 */CONFIDENTIALITY NOTICE: This email
>>>                                 may contain confidential and
>>>                                 review, use, distribution or
>>>                                 this communication in error, please
>>>                                 notify the sender immediately by
>>>                                 e-mail and delete the message and
>>>                                 any file attachments from your
>>>                                 computer. Thank you./*
>>>
>                 /CONFIDENTIALITY NOTICE: This email may contain
>                 prohibited...  If you have received this communication
>                 e-mail and delete the message and any file attachments
>                 from your computer. Thank
>                 you./_______________________________________________
>                 OAuth mailing list

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jan 2019 19:02:55 +0000

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 <[email-masked]> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Thank you guys!

Regards,
 Rifaat

                                                          -- Mike

John B.

Regards,
 Rifaat

Regards,
 Rifaat

John B.

We have discussed this.

John B.

Authors,

Regards,
 Rifaat

access.

Regards,
 Rifaat

OAuth mailing list

OAuth mailing list

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 23 Jan 2019 11:50:52 -0800

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 <Michael.Jones=
[email-masked]> 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
>
>
>
> *Sent:* Wednesday, January 23, 2019 10:56 AM
> *To:* [email-masked]
> I don't think they are necessarily mutually exclusive, that is why I think
> there is value in allowing them to be specified separately.
>
> 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.
>
> 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.
>
> thanks for you patience. Brian and myself iterated on modifying the text
> to cover the logical identifier use case, highlighting the security
> *From:* OAuth <[email-masked]> *On Behalf Of *John Bradley
> review, use, distribution or disclosure by others is strictly
> prohibited...  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any file
> attachments from your computer. Thank you.*

---

From: George Fletcher <[email-masked]>
Date: Wed, 23 Jan 2019 14:55:21 -0500

What about deployments where the logical endpoint 
(https://api.service.example.com/foo) is actually deployed at 
https://2354353-<geo-location>.api.service.example.com/foo? I've worked 
with partners where the endpoint URI is unique to a geo-location and 
that endpoint is returned to the client when providing the token. 
Requiring exact location URLs force a client to make two token requests 
in order to get a token for the exact specified location.

Maybe I'm missing something?

Thanks,
George

On 1/23/19 1:56 PM, John Bradley wrote:
> 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.
>
> I really like keeping the resource simple and unspoofable, it is the 
> URI of the RS where you are presenting the AT.
>
> 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 
>> 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 Monday, January 21, 2019, Vittorio Bertocci
>>             To move this discussion forward, can you guys suggest
>>             some text to make the logical identifier usage clearer?
>>
>>             Regards,
>>              Rifaat
>>
>>
>>                 adjustment and/or augmentation of some text to make
>>                 it more clear.
>>
>>                     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.
>>>                         logical resource in a standard compliant
>>>                         way, hence it doesn't strictly matter
>>>                         whether the definition of the corresponding
>>>                         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
>>>                         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
>>>                         better than ignoring he logical identifier
>>>                         case altogether, however I think that not
>>>                         acknowledging the logical id case
>>>>                             draft-ietf-oauth-resource-indicators,
>>>>                             as the logical audience work is already
>>>>                                     not allow the process to
>>>>                                         or out-of-band or
>>>>                                         absolute URI that indicates
>>>>                                         the location of the target
>>>>                                         service or resource where
>>>>                                         access is being requested.
>>>>                                         A location can be varying
>>>>                                         that's a logical identifier
>>>>                                         that points to some
>>>>                                         resource is well within the
>>>>                                         bounds of the draft.
>>>>
>>>>                                         text should be added and/or
>>>>                                         adjusted so the
>>>>                                                 the logical
>>>>                                                 resource and then
>>>>                                                 using scopes to
>>>>                                                 and try to add text
>>>>                                                     audiences on
>>>>                                                     the fly at the
>>>>                                                     AS every time
>>>>                                                     you do a
>>>>                                                     this spec? That
>>>>                                                     would eliminate
>>>>                                                     the interop
>>>>                                                     also gives us a
>>>>                                                     chance to fully
>>>>                                                     warn people
>>>>                                                     about the
>>>>                                                         into asking
>>>>                                                         wrong one
>>>>                                                         as a bad
>>>>                                         of the intended
>>>>                                         recipient(s). Any review,
>>>>                                         use, distribution or
>>>>                                         disclosure by others is
>>>>                                         strictly prohibited. If you
>>>>                                         have received this
>>>>                                         communication in error,
>>>>                                         please notify the sender
>>                 prohibited...  If you have received this
>>                 communication in error, please notify the sender
>>                 immediately by e-mail and delete the message and any
>>                 file attachments from your computer. Thank

---

From: George Fletcher <[email-masked]>
Date: Wed, 23 Jan 2019 14:59:42 -0500

+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.
> complexity of the specs, which is already unusably high for mere 
> mortals in the OAuth2/OIDC family of specs.
>
> 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:[email-masked]>> 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
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     I don't think they are necessarily mutually exclusive, that is why
>     I think there is value in allowing them to be specified separately.
>
>     interacting with RS https://fire.hhs.com as the resource wants a
>     OAuth token with an audience of HHS and a scope of read.
>
>     I really like keeping the resource simple and unspoofable, it is
>     the URI of the RS where you are presenting the AT.
>
>     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
>         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
>         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
>                 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.
>
>                     To move this discussion forward, can you guys
>                     suggest some text to make the logical identifier
>                     usage clearer?
>
>                     Regards,
>
>                      Rifaat
>
>                         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
>                         On Sun, Jan 20, 2019 at 7:39 PM Vittorio
>                         Bertocci <[email-masked]
>                             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.
>
>                             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.
>
>                                     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
>                                     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
>                                     parameters are expected to result
>                                     in audience restricted tokens. It
>                                     seems the only difference comes at
>                                     addressable case giving more
>                                     guarantees that the token will go
>                                     to its intended recipient, but the
>                                     request and audience restriction
>                                     developer discovered it out of
>                                     band and placed it in the app
>                                     config at deployment time. Those
>                                     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
>                                     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.
>
>                                     altogether, however I think that
>                                     not acknowledging the logical id
>                                     case in oauth-resource-indicators
>                                     is going to create confusion and
>                                             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
>                                             - 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
>                                             as the logical audience
>                                             *On Behalf Of *John Bradley
>                                             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
>                                             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
>                                                 at 6:22 PM Rifaat
>                                                     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.
>                                                     things happen and
>                                                     sometimes the WG
>                                                     misses something.
>                                                     I hear you and
>                                                     agree that this
>                                                     make things
>                                                     difficult for
>                                                     2019 at 5:35 PM
>                                                     Brian Campbell
>                                                         process does,
>                                                         right? I do
>                                                         but that's
>                                                         mostly because
>                                                         threads is
>                                                         hard for me
>                                                         and I'll just
>                                                         get over it...
>                                                         As far as I
>                                                         understand
>                                                         things, the
>                                                         by the
>                                                         resource how
>                                                         to identity
>                                                         the resource
>                                                         like is
>                                                         and using the
>                                                         location in
>                                                         that context
>                                                         ,along with
>                                                         some other
>                                                         checks
>                                                         prescribed in
>                                                         that draft,
>                                                         prevents the
>                                                         kind of issues
>                                                         John described
>                                                         earlier in the
>                                                         In cases where
>                                                         knows the
>                                                         resource a
>                                                         priori or
>                                                         out-of-band or
>                                                         configured or
>                                                         whatever, I
>                                                         don't think
>                                                         concerns
>                                                         arise. And
>                                                         using such a
>                                                         known value,
>                                                         be it an
>                                                         location or
>                                                         resource-indicators
>                                                         draft is
>                                                         admittedly
>                                                         somewhat
>                                                         talks about
>                                                         the value of
>                                                         the 'resource'
>                                                         parameter. But
>                                                         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'
>                                                         value that's a
>                                                         that points to
>                                                         some resource
>                                                         is well within
>                                                         the bounds of
>                                                         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
>                                                         added and/or
>                                                         adjusted so
>                                                         resource-indicators
>                                                         draft would be
>                                                         a little more
>                                                         open/clear
>                                                         value
>                                                         potentially
>                                                         identifier and
>                                                         not
>                                                         necessarily a
>                                                         addressable URL?
>                                                         On Fri, Jan
>                                                         18, 2019 at
>                                                         1:18 PM Rifaat
>                                                             I wouldn't
>                                                             worry too
>                                                             much about
>                                                             the process.
>                                                             If it
>                                                             makes
>                                                             sense to
>                                                             update the
>                                                             document,
>                                                             then feel
>                                                             that.
>                                                             On Fri,
>                                                             Jan 18,
>                                                             3:08 PM
>                                                             John
>                                                                 Yes
>                                                                 provided
>                                                                 by "scope"
>                                                                 Ping
>                                                                 Auth0
>                                                                 have
>                                                                 been
>                                                                 adding
>                                                                 another
>                                                                 "aud"
>                                                                 identify
>                                                                 then
>                                                                 scopes
>                                                                 define
>                                                                 permissions
>                                                                 to the
>                                                                 resource.
>                                                                 Fortunately,
>                                                                 we are
>                                                                 name
>                                                                 so not
>                                                                 stepping
>                                                                 We
>                                                                 could
>                                                                 go
>                                                                 back
>                                                                 try to
>                                                                 add
>                                                                 explaining
>                                                                 difference,
>                                                                 but we
>                                                                 are
>                                                                 quite
>                                                                 late
>                                                                 in the
>                                                                 process.
>                                                                 agree
>                                                                 that a
>                                                                 parameter may
>                                                                 helpful,
>                                                                 but
>                                                                 perhaps
>                                                                 should
>                                                                 Fri,
>                                                                 18,
>                                                                 4:38
>                                                                 Richard
>                                                                 Backman,
>                                                                     Doesn’t
>                                                                     means
>                                                                     specifying
>                                                                     Richard
>                                                                     Backman
>                                                                     AWS
>                                                                     Identity
>                                                                     *From:
>                                                                     *OAuth
>                                                                     <[email-masked]
>                                                                     on
>                                                                     behalf
>                                                                     January
>                                                                     18,
>                                                                     5:47
>                                                                     *To:
>                                                                     *John
>                                                                     *Cc:
>                                                                     *IETF
>                                                                     oauth
>                                                                     *Subject:
>                                                                     *Re:
>                                                                     Thanks
>                                                                     John
>                                                                     agree
>                                                                     from
>                                                                     PoV,
>                                                                     having
>                                                                     makes
>                                                                     things
>                                                                     more
>                                                                     solid.
>                                                                     That
>                                                                     said:
>                                                                     use
>                                                                     widespread,
>                                                                     as
>                                                                     (think
>                                                                     services
>                                                                     hosting
>                                                                     URLs
>                                                                     only
>                                                                     time,
>                                                                     or
>                                                                     services
>                                                                     are
>                                                                     somehow
>                                                                     grouped
>                                                                     under
>                                                                     same
>                                                                     People
>                                                                     won't
>                                                                     stop
>                                                                     because
>                                                                     they
>                                                                     often
>                                                                     have
>                                                                     no
>                                                                     new
>                                                                     audiences
>                                                                     on
>                                                                     fly
>                                                                     AS
>                                                                     every
>                                                                     time
>                                                                     do
>                                                                     get
>                                                                     assigned
>                                                                     new
>                                                                     Leaving
>                                                                     widely
>                                                                     used
>                                                                     approach
>                                                                     as
>                                                                     exercise
>                                                                     reader
>                                                                     seems
>                                                                     disservice
>                                                                     community,
>                                                                     given
>                                                                     this
>                                                                     might
>                                                                     lead
>                                                                     vendors
>                                                                     (for
>                                                                     Auth0)
>                                                                     keeping
>                                                                     their
>                                                                     own
>                                                                     parameters,
>                                                                     or
>                                                                     misusing
>                                                                     ones
>                                                                     place;
>                                                                     make
>                                                                     hard
>                                                                     SDK
>                                                                     libraries
>                                                                     work
>                                                                     out
>                                                                     box
>                                                                     with
>                                                                     different
>                                                                     ASes;
>                                                                     so on.
>                                                                     Would
>                                                                     feasible
>                                                                     add
>                                                                     such
>                                                                     directly
>                                                                     this
>                                                                     spec?
>                                                                     That
>                                                                     eliminate
>                                                                     issues,
>                                                                     also
>                                                                     gives
>                                                                     us
>                                                                     chance
>                                                                     fully
>                                                                     warn
>                                                                     people
>                                                                     choosing
>                                                                     4:32
>                                                                     John
>                                                                         We
>                                                                         have
>                                                                         however
>                                                                         more
>                                                                         AS
>                                                                         free
>                                                                         map
>                                                                         some
>                                                                         AT.
>                                                                         From
>                                                                         point
>                                                                         view
>                                                                         once
>                                                                         asking
>                                                                         asking
>                                                                         wrong
>                                                                         as
>                                                                         always
>                                                                         lie
>                                                                         is.
>                                                                         If
>                                                                         we
>                                                                         were
>                                                                         change
>                                                                         it,
>                                                                         how
>                                                                         AS
>                                                                         free
>                                                                         do
>                                                                         mapping
>                                                                         needs
>                                                                         access
>                                                                         may
>                                                                         want
>                                                                         but
>                                                                         should
>                                                                         from
>                                                                         resource.
>                                                                         John
>                                                                         B.
>                                                                         9:56
>                                                                         AM,
>                                                         email may
>                                                         contain
>                                                         confidential
>                                                         and privileged
>                                                         material for
>                                                         the sole use
>                                                         intended
>                                                         recipient(s).
>                                                         Any review,
>                                                         use,
>                                                         distribution
>                                                         prohibited. If
>                                                         you have
>                                                         received this
>                                                         communication
>                                                         in error,
>                                                         please notify
>                                                         the sender
>                                                         immediately by
>                                                         e-mail and
>                                                         delete the
>                                                         message and
>                                                         any file
>                                                         attachments
>                                                         from your
>                                                         computer.
>                                                         Thank you./*
>                                                 */CONFIDENTIALITY
>                                                 NOTICE: This email may
>                                                 contain confidential
>                                                 and privileged
>                                                 material for the sole
>                                                 use of the intended
>                                                 recipient(s). Any
>                                                 prohibited.. If you
>                                                 communication in
>                                                 error, please notify
>                                                 the sender immediately
>                                                 by e-mail and delete
>                                                 the message and any
>                                                 you./*
>                         /CONFIDENTIALITY NOTICE: This email may
>                         contain confidential and privileged material
>                         for the sole use of the intended recipient(s).
>                         Any review, use, distribution or disclosure by
>                         others is strictly prohibited... If you have
>                         received this communication in error, please
>                         notify the sender immediately by e-mail and
>                         delete the message and any file attachments

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 24 Jan 2019 15:45:44 -0500

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 <gffletch=
[email-masked]> wrote:

> 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
>
>> 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.
>>
>> In Azure AD v1 & ADFS, that's resource.. It could be used for both

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Jan 2019 23:19:57 +0000

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 <[email-masked]>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <[email-masked]>
Cc: Vittorio Bertocci <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]
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 <gffletch=[email-masked]<mailto:[email-masked]>> 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 <Michael.Jones=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

John B.

Regards,
 Rifaat

On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell <bcampbell=[email-masked]..org<mailto:[email-masked]>> 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.

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

                                                          -- Mike

John B.

Regards,
 Rifaat

Regards,
 Rifaat

John B.

We have discussed this.

John B.

Authors,

Regards,
 Rifaat

access.

Regards,
 Rifaat

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 24 Jan 2019 19:13:00 -0500

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 <[email-masked]>
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 <[email-masked]>
> *Sent:* Thursday, January 24, 2019 12:46 PM
> *To:* George Fletcher <[email-masked]>
> *Cc:* Vittorio Bertocci <[email-masked]>; Mike Jones <
> [email-masked]>; [email-masked]
> [email-masked]..org <[email-masked]>>
> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 28 Jan 2019 07:07:39 -0700

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.

---

From: George Fletcher <[email-masked]>
Date: Mon, 28 Jan 2019 11:04:43 -0500

+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 "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 
> On Thu, Jan 24, 2019 at 5:13 PM Rifaat Shekh-Yusef 
> <[email-masked] <mailto:rifaat.ietf@gmail..com>> wrote:
>
>     On Thu, Jan 24, 2019 at 6:20 PM Mike Jones
>     <[email-masked] <mailto:[email-masked]>>
>     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 <[email-masked]
>         *To:* George Fletcher <[email-masked] <mailto:[email-masked]>>
>         *Cc:* Vittorio Bertocci <[email-masked]
>         <mailto:[email-masked]>>; Mike Jones
>         <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a
>         scheduled OAuth WG Virtual Office meeting.
>
>         On Wed, Jan 23, 2019 at 3:00 PM George Fletcher
>         <gffletch=[email-masked]
>         <mailto:[email-masked]>> 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
>
>                 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
>                 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.
>
>                     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
>
>                     <mailto:[email-masked]>> *On Behalf Of
>                     *John Bradley
>                     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
>                     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
>                         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
>                         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 <[email-masked]
>                             On Monday, January 21, 2019, Vittorio
>                                 On Mon, Jan 21, 2019 at 9:35 AM Rifaat
>                                 Shekh-Yusef <[email-masked]
>                                     To move this discussion forward,
>                                     can you guys suggest some text to
>                                     make the logical identifier usage
>                                     clearer?
>
>                                     Regards,
>
>                                      Rifaat
>
>                                     <bcampbell=[email-masked]..org
>                                             In Azure AD v1 & ADFS,
>                                             that's resource.. It could
>                                             be used for both network
>                                             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
>                                                     wasn't monitoring
>                                                     those discussions
>                                                     hence I didn't
>                                                     have a chance to
>                                                     offer feedback.
>                                                     When I saw
>                                                     something that
>                                                     gave me the
>                                                     deployments and
>                                                     developers using a
>                                                     similar parameter
>                                                     for a long time, I
>                                                     thought prudent to
>                                                     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
>                                                     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
>                                                     <[email-masked]
>                                                         On Jan 19,
>                                                         2019, at 12:34
>                                                         PM, Mike Jones
>                                                             I also
>                                                             agree that
>                                                             “resource”
>                                                             a specific
>                                                             network-addressable
>                                                             whereas a
>                                                             (like
>                                                             “aud” in
>                                                             JWTs) can
>                                                             refer to
>                                                             one or
>                                                             resources.
>                                                             They are
>                                                             different,
>                                                             related,
>                                                             things.
>                                                             Note that
>                                                             the ACE WG
>                                                             proposing
>                                                             register a
>                                                             “req_aud”
>                                                             - partly
>                                                             based on
>                                                             feedback
>                                                             from OAuth
>                                                             members. 
>                                                             This is a
>                                                             general
>                                                             parameter,
>                                                             which any
>                                                             will be
>                                                             able to use.
>                                                             therefore
>                                                             believe
>                                                             that no
>                                                             changes
>                                                             are needed
>                                                             as the
>                                                             work is
>                                                             happening
>                                                             in another
>                                                             *From:*
>                                                             *On Behalf
>                                                             Of *John
>                                                             Bradley
>                                                             *Sent:*
>                                                             Saturday,
>                                                             19, 2019
>                                                             9:01 AM
>                                                             *To:*
>                                                             Brian
>                                                             Campbell
>                                                             *Cc:*
>                                                             IETF oauth
>                                                             *Subject:*
>                                                             Re:
>                                                             We need to
>                                                             decide if
>                                                             we want to
>                                                             make a
>                                                             change.
>                                                             For
>                                                             centric.
>                                                             I prefer
>                                                             that can
>                                                             be a scope
>                                                             or other
>                                                             parameter.
>                                                             If becomes
>                                                             harder for
>                                                             people to
>                                                             use the
>                                                             correctly
>                                                             if we are
>                                                             too flexible.
>                                                             I would
>                                                             have a
>                                                             if we
>                                                             think we
>                                                             On Sat,
>                                                             Jan 19,
>                                                             2019,
>                                                             11:41 AM
>                                                             Brian
>                                                             Campbell
>                                                                 No
>                                                                 apology
>                                                                 needed,
>                                                                 Rifaat.
>                                                                 And I
>                                                                 apologize
>                                                                 what I
>                                                                 said
>                                                                 came
>                                                                 off
>                                                                 way. I
>                                                                 was
>                                                                 just
>                                                                 trying
>                                                                 light
>                                                                 situation..
>                                                                 And I
>                                                                 not be
>                                                                 hamstrung
>                                                                 process
>                                                                 times
>                                                                 when
>                                                                 sense
>                                                                 to be
>                                                                 flexible
>                                                                 things.
>                                                                 6:22
>                                                                     Sorry
>                                                                     Brian,
>                                                                     was
>                                                                     clear
>                                                                     my
>                                                                     meant
>                                                                     say
>                                                                     allow
>                                                                     process
>                                                                     prevent
>                                                                     producing
>                                                                     quality
>                                                                     document
>                                                                     without
>                                                                     assuming
>                                                                     issue
>                                                                     place.
>                                                                     Ideally
>                                                                     these
>                                                                     identified
>                                                                     during
>                                                                     WGLC,
>                                                                     happen
>                                                                     sometimes
>                                                                     misses
>                                                                     hear
>                                                                     difficult
>                                                                     authors.
>                                                                     will
>                                                                     sure
>                                                                     does
>                                                                     become
>                                                                     norm,
>                                                                     will
>                                                                     try
>                                                                     stick
>                                                                     process
>                                                                     much
>                                                                     5:35
>                                                                     Brian
>                                                                     Campbell
>                                                                         Rifaat.
>                                                                         Process
>                                                                         process
>                                                                         does,
>                                                                         right?
>                                                                         kinda
>                                                                         grumble
>                                                                         WGCL
>                                                                         passed
>                                                                         that's
>                                                                         mostly
>                                                                         replying
>                                                                         these
>                                                                         kinds
>                                                                         threads
>                                                                         me
>                                                                         I'll
>                                                                         just
>                                                                         over
>                                                                         it...
>                                                                         As
>                                                                         far
>                                                                         things,
>                                                                         come
>                                                                         play
>                                                                         when
>                                                                         told
>                                                                         by
>                                                                         identity
>                                                                         described
>                                                                         context
>                                                                         ,along
>                                                                         other
>                                                                         prescribed
>                                                                         draft,
>                                                                         prevents
>                                                                         kind
>                                                                         issues
>                                                                         described
>                                                                         earlier
>                                                                         In
>                                                                         cases
>                                                                         where
>                                                                         knows
>                                                                         priori
>                                                                         out-of-band
>                                                                         configured
>                                                                         whatever,
>                                                                         don't
>                                                                         think
>                                                                         arise.
>                                                                         And
>                                                                         known
>                                                                         value,
>                                                                         representation,
>                                                                         okay.
>                                                                         location-centric
>                                                                         talks
>                                                                         parameter.
>                                                                         ultimately
>                                                                         defines
>                                                                         absolute
>                                                                         URI
>                                                                         indicates
>                                                                         target
>                                                                         service
>                                                                         where
>                                                                         requested.
>                                                                         A
>                                                                         varying
>                                                                         shades
>                                                                         I'd
>                                                                         say
>                                                                         URI
>                                                                         that's
>                                                                         points
>                                                                         well
>                                                                         within
>                                                                         bounds
>                                                                         maybe
>                                                                         okay
>                                                                         is?
>                                                                         Or
>                                                                         that's
>                                                                         too
>                                                                         much
>                                                                         left
>                                                                         exerciser
>                                                                         reader?
>                                                                         And
>                                                                         added
>                                                                         and/or
>                                                                         adjusted
>                                                                         so
>                                                                         little
>                                                                         necessarily
>                                                                         URL?
>                                                                         1:18
>                                                                             wouldn't
>                                                                             worry
>                                                                             too
>                                                                             much
>                                                                             sense
>                                                                             update
>                                                                             feel
>                                                                             3:08
>                                                                                 by
>                                                                                 "scope"
>                                                                                 so
>                                                                                 try
>                                                                                     so
>                                                                                     on.
>                                                                         NOTICE:
>                                                                         email
>                                                                         privileged
>                                                                         material
>                                                                         sole
>                                                                         Any
>                                                                         review,
>                                                                         disclosure
>                                                                         by
>                                                                         others
>                                                                         prohibited.
>                                                                         received
>                                                                         error,
>                                                                         please
>                                                                         notify
>                                                                         sender
>                                                                         immediately
>                                                                         by
>                                                                         e-mail
>                                                                         delete
>                                                                         message
>                                                                         any
>                                                                         file
>                                                                         your
>                                                                         Thank
>                                                                 NOTICE:
>                                                                 email
>                                                                 privileged
>                                                                 material
>                                                                 sole
>                                                                 use of
>                                                                 Any
>                                                                 review,
>                                                                 disclosure
>                                                                 by
>                                                                 others
>                                                                 prohibited..
>                                                                 If you
>                                                                 received
>                                                                 error,
>                                                                 please
>                                                                 notify
>                                                                 sender
>                                                                 immediately
>                                                                 by
>                                                                 e-mail
>                                                                 delete
>                                                                 message
>                                                                 any
>                                                                 file
>                                                                 your
>                                                                 Thank
>                                         /CONFIDENTIALITY NOTICE: This
>                                         email may contain confidential
>                                         received this communication in
>                                         error, please notify the
>                                         and delete the message and any
>                                         computer. Thank
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> prohibited..  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 28 Jan 2019 18:28:12 +0000

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 <[email-masked]> On Behalf Of George Fletcher
Sent: Monday, January 28, 2019 10:05 AM
To: Brian Campbell <bcampbell=[email-masked]>
Cc: [email-masked]; Vittorio Bertocci <[email-masked]>
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 <[email-masked]<mailto:rifaat.ietf@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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

All,

Regards,
 Rifaat

Thanks,
George

                                                       -- Mike

John B.

Regards,
 Rifaat

                                                          -- Mike

John B.

Regards,
 Rifaat

Regards,
 Rifaat

John B.

We have discussed this.

John B.

Authors,

Regards,
 Rifaat

access.

Regards,
 Rifaat

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Mon, 28 Jan 2019 13:54:16 -0700

[added [email-masked] 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 <[email-masked]>
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 <[email-masked]> *On Behalf Of *George Fletcher
> *Sent:* Monday, January 28, 2019 10:05 AM
> *To:* Brian Campbell <bcampbell=[email-masked]>
> *Cc:* [email-masked]; Vittorio Bertocci <[email-masked]>
> 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"
> identified is really a risk decision and based on the deployment model can
> be managed at either the RS or the AS.
>
> Thanks,
> George
>
> 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 <[email-masked]
> <rifaat.ietf@gmail..com>> wrote:
>

---

From: George Fletcher <[email-masked]>
Date: Mon, 28 Jan 2019 17:12:02 -0500

I also don't know that this raises to the level of "concern" but I find 
the parameter name of "req_aud" odd. Given that the parameter in the 
resource-indicators spec is 'resource' why not use a parameter name of 
'audience'. That said, I have not read the thread on the ACE working 
group list so there could be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases) between 
'resource' and 'audience' and having two parameters that cover a lot of 
the same semantics is going to be confusing for developers. When calling 
an API at a resource server, the 'audience' and the 'resource' are 
pretty equivalent. Maybe in other use cases they are distinctly separate?

Thanks,
George

On 1/28/19 3:54 PM, Brian Campbell wrote:
> [added [email-masked] <mailto:[email-masked]> 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.
>
> On Mon, Jan 28, 2019 at 11:28 AM Mike Jones 
> <[email-masked] <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *George Fletcher
>     *To:* Brian Campbell <bcampbell=[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Vittorio Bertocci
>     <[email-masked] <mailto:[email-masked]>>
>     https://api.example.com/mail <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 is really a load balancer that fronts the
>     "
>     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
>
>         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.
>
>             <mailto:[email-masked]>> 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
>
>                 This coming Monday, Jan 28 @ 12:00pm Eastern Time, we
>                 have a scheduled OAuth WG Virtual Office meeting.
>
>                     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
>
>                         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
>                         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
>                         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.
>
>                             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
>
>                             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.
>
>                                 to split the resource parameter in two
>                                 distinct parameters to better signal
>                                 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.
>
>                                         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.
>
>                                                 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
>                                                     [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.
>                                                     On Sun, Jan 20,
>                                                     2019 at 17:58 John
>                                                         What is the
>                                                         parameter that
>                                                         Microsoft is
>                                                         using?
>                                                         On 1/20/2019
>                                                         3:59 PM,
>                                                         Bertocci wrote:
>                                                             First of
>                                                             all, it
>                                                             wasn't my
>                                                             intent to
>                                                             disrupt
>                                                             established
>                                                             In my
>                                                             former
>                                                             position I
>                                                             wasn't
>                                                             monitoring
>                                                             those
>                                                             discussions
>                                                             hence I
>                                                             didn't
>                                                             chance to
>                                                             offer
>                                                             feedback.
>                                                             something
>                                                             that gave
>                                                             me the
>                                                             impression
>                                                             might lead
>                                                             to issues,
>                                                             and given
>                                                             that I
>                                                             worked
>                                                             deployments
>                                                             using a
>                                                             similar
>                                                             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
>                                                             to have
>                                                             guidance
>                                                             on how to
>                                                             work with
>                                                             concept of
>                                                             in a
>                                                             standard
>                                                             compliant
>                                                             way, hence
>                                                             it doesn't
>                                                             matter
>                                                             whether
>                                                             definition
>                                                             lives
>                                                             That said.
>                                                             Reading
>                                                             through
>                                                             the draft,
>                                                             it would
>                                                             appear
>                                                             that most
>                                                             reasons
>                                                             for which
>                                                             the spec
>                                                             created
>                                                             apply to
>                                                             both the
>                                                             and the
>                                                             types:
>                                                             knowing
>                                                             what keys
>                                                             to use to
>                                                             encrypt
>                                                             constrain
>                                                             tokens to
>                                                             overloading
>                                                             indicating
>                                                             parts...
>                                                             those all
>                                                             apply to
>                                                             and logic
>                                                             alike. And
>                                                             both
>                                                             expected
>                                                             to result
>                                                             restricted
>                                                             tokens. It
>                                                             seems the
>                                                             difference
>                                                             comes at
>                                                             usage
>                                                             time, with
>                                                             case
>                                                             giving
>                                                             guarantees
>                                                             that the
>                                                             token will
>                                                             go to its
>                                                             recipient,
>                                                             but the
>                                                             restriction
>                                                             syntax
>                                                             seems to
>                                                             be exactly
>                                                             the same.
>                                                             On top of
>                                                             this: in
>                                                             99.999% of
>                                                             scenarios
>                                                             encountered
>                                                             wild in
>                                                             the last 5
>                                                             years of
>                                                             using the
>                                                             ecosystem,
>                                                             was known
>                                                             at design
>                                                             discovered
>                                                             it out of
>                                                             band and
>                                                             placed it
>                                                             in the app
>                                                             time.
>                                                             Those
>                                                             aren't
>                                                             fringe
>                                                             cases I
>                                                             encountered:
>                                                             in Azure
>                                                             AD v1 and
>                                                             mandatory,
>                                                             hence
>                                                             literally
>                                                             solution i
>                                                             saw or
>                                                             touched
>                                                             used it.
>                                                             suggested,
>                                                             this is a
>                                                             scenario
>                                                             where the
>                                                             case
>                                                             aren't as
>                                                             pronounced
>                                                             as in the
>                                                             case in
>                                                             which the
>                                                             discovers
>                                                             runtime.
>                                                             This isn't
>                                                             there is
>                                                             indicated,
>                                                             it's
>                                                             there are
>                                                             many
>                                                             development
>                                                             time to be
>                                                             able to
>                                                             identifiers-
>                                                             and if the
>                                                             /concrete
>                                                             apply to
>                                                             the their
>                                                             case,
>                                                             simply not
>                                                             comply.
>                                                             summary:
>                                                             creating
>                                                             two
>                                                             in two
>                                                             documents
>                                                             is better
>                                                             ignoring
>                                                             he logical
>                                                             case
>                                                             altogether,
>                                                             however I
>                                                             think that
>                                                             acknowledging
>                                                             logical id
>                                                             is going
>                                                             to create
>                                                             confusion
>                                                             not be as
>                                                             useful to
>                                                             community
>                                                             as it
>                                                             12:38 Phil
>                                                                 +1 to
>                                                                 Mike
>                                                                 John’s
>                                                                 comments.
>                                                                 On Jan
>                                                                 19,
>                                                                 12:34
>                                                                 PM,
>                                                                 Mike
>                                                                 Jones
>                                                                     whereas
>                                                                     “aud”
>                                                                     JWTs)
>                                                                     refer
>                                                                     They
>                                                                     Note
>                                                                     ACE
>                                                                     register
>                                                                     -
>                                                                     partly
>                                                                     based
>                                                                     able
>                                                                     needed
>                                                                     Mike
>                                                                     *On
>                                                                     Behalf
>                                                                     Of
>                                                                     19,
>                                                                     9:01
>                                                                     IETF
>                                                                     decide
>                                                                     prefer
>                                                                     scope
>                                                                     harder
>                                                                     Sat,
>                                                                     19,
>                                                                     11:41
>                                                                         way.
>         /CONFIDENTIALITY NOTICE: This email may contain confidential
>         by e-mail and delete the message and any file attachments from
>         your computer. Thank you./
>
> prohibited.  If you have received this communication in error, please

---

From: Brian Campbell <[email-masked]>
Date: Mon, 28 Jan 2019 16:25:50 -0700

Following up on the thread here and the discussion earlier during the
"OAuth WG Virtual Office Hours" call,
draft-ietf-oauth-resource-indicators-02
<https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02> has
been published with some minor updates to clarify that the value of the
"resource" parameter is a URI which can be an abstract identifier for the
target resource and doesn't necessarily have to correspond to a network
addressable location.

On Mon, Jan 28, 2019 at 3:12 PM George Fletcher <[email-masked]> wrote:

> 'audience'. That said, I have not read the thread on the ACE working group
> list so there could be very good reasons for the chosen name:)
>
> 'resource' and 'audience' and having two parameters that cover a lot of the
> same semantics is going to be confusing for developers. When calling an API
> at a resource server, the 'audience' and the 'resource' are pretty
> equivalent. Maybe in other use cases they are distinctly separate?
>
> Thanks,
> George
>
> 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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 29 Jan 2019 08:56:16 +0100

> pretty equivalent. Maybe in other use cases they are distinctly separate?

To give you all the background of "req_aud" from ACE (sorry for the long 
text):

Originally in ACE we had defined the "aud" parameter for requests to the 
token endpoint with the semantics that the client was requesting a token 
for a certain audience (i.e. requesting that the AS copy the "aud" 
parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that 
specifies the intended audience of Authorization Servers (if I remember 
correctly), so we decided to rename our parameter to "req_aud" for 
"requested audience".
Mike Jones then made us aware of the work on resource indicators, but 
upon closer examination I found the "resource" parameter to be more 
limited than the "req_aud", since resource specifically states:

"Its value MUST be an absolute URI ... the "resource" parameter URI 
value is an identifier representing the identity of the resource"

My interpretation of this is that "resource" refers to a single 
resource, which is more constrained than the definition of the "aud" 
claim from 7519, which uses a StringOrURI value.  For example my intent 
was to use "aud" and "req_aud" for group identifiers 
("temperatureSensorGroup4711") and other non-uri strings 
(hash-of-public-key), which I cannot do with "resource".  We therefore 
decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, 
even though is clearly overlaps with "resource".

Any comments and suggestions about that line of reasoning (especially 
from the OAuth point of view) are very welcome.

/Ludwig

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

---

From: George Fletcher <[email-masked]>
Date: Tue, 29 Jan 2019 08:15:01 -0500

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec 
[1] allows for abstract identifiers, and since a URN is also a URI, you 
could easily use a URN syntax to accomplish the use case outlined in 
your email.

resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" is 
not a "single resource" in the context of a fully qualified API endpoint.

    Another example, for an API like SCIM [RFC7644  <https://tools.ietf.org/html/rfc7644>] that has
        multiple endpoints such as "https://apps.example.com/scim/Users",
        "https://apps.example.com/scim/Groups", and
        "https://apps.example.com/scim/Schemas" The client would use
        "https://apps.example.com/scim/" as the resource so that the issued
        access token is valid for all the endpoints of the SCIM API.

Using "https://apps.example.com/scim" is semantically equivalent to 
using "temperatureSensorGroup4711", at least to me:)

Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:
>> I also don't know that this raises to the level of "concern" but I 
>> find the parameter name of "req_aud" odd. Given that the parameter in 
>> the resource-indicators spec is 'resource' why not use a parameter 
>> name of 'audience'. That said, I have not read the thread on the ACE 
>> working group list so there could be very good reasons for the chosen 
>> name:)
>>
>> 'resource' and 'audience' and having two parameters that cover a lot 
>> of the same semantics is going to be confusing for developers. When 
>> calling an API at a resource server, the 'audience' and the 
>> 'resource' are pretty equivalent. Maybe in other use cases they are 
>> distinctly separate?
>>
>
> To give you all the background of "req_aud" from ACE (sorry for the 
> long text):
>
> Originally in ACE we had defined the "aud" parameter for requests to 
> the token endpoint with the semantics that the client was requesting a 
> token for a certain audience (i.e. requesting that the AS copy the 
> "aud" parameter value into the "aud" claim value of the token).
> We were then told that this collided with a use of "aud" in OAuth, 
> that specifies the intended audience of Authorization Servers (if I 
> remember correctly), so we decided to rename our parameter to 
> "req_aud" for "requested audience".
> claim from 7519, which uses a StringOrURI value.  For example my 
> intent was to use "aud" and "req_aud" for group identifiers 
> decided to keep the "req_aud" parameter in 
> draft-ietf-ace-oauth-params, even though is clearly overlaps with 
> "resource".
>

-- 
Identity Standards Architect
Verizon Media                     Work: [email-masked]
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography