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

[Rifaat Shekh-Yusef]

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

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

Regards,
 Rifaat


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

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



 --

 Annabelle Richard Backman

 AWS Identity





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



 Thanks John for the background.

 I agree that from the client validation PoV, having an identifier
 corresponding to a location makes things more solid.

 That said: the use of logical identifiers is widespread, as it has
 significant practical advantages (think of services that assign generated
 hosting URLs only at deployment time, or services that are somehow grouped
 under the same logical 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 

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

[Brian Campbell]

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

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

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

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

So maybe the draft is okay as is?

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



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

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

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

[Rifaat Shekh-Yusef]

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

Regards,
 Rifaat


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

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

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

[John Bradley]

Yes the logical resource can be provided by "scope"

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

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

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

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

John B.

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

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

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

[Richard Backman, Annabelle]

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

--
Annabelle Richard Backman
AWS Identity


From: OAuth  on behalf of Vittorio Bertocci 

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

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



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

We have discussed this.

Audiences can certainly be logical identifiers.

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

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

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

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

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

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

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


Authors,

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

Regards,
 Rifaat


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


An extension to the OAuth 2.0 Authorization Framework defining request

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

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

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



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

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

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

Regards,
 Rifaat

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



___

OAuth mailing list

OAuth@ietf.org

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

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

[Vittorio Bertocci]

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



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

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