Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> 
> We are building up the scheme. One banking group is deployed.
> 
>> 
>> Today, a separate flow us required for each RS, correct?
> 
> We support combined flows because this is a key requirement for us. But this 
> comes at a price: we cannot tightly audience restrict our tokens. We use 
> handles and Introspection to ensure every RS only gets to know the data it 
> needs to know. And we must use sender constraint tokens in order to prevent 
> token leakage. Having an interoperable way to obtain structured and audience 
> restricted access tokens would simply development, reduce coupling between AS 
> & RS and improve performance.

I forgot to mention, a deployment supporting strict resource server specific 
audience restriction with structured access tokens is in place at Deutsche 
Telekom for years now ( even predating OAuth 2.0). As the only drawback, 
encoding of resource servers in scopes and refresh token handling to obtain 
RS-specific access tokens is proprietary.

> 
>> 
>> In the future, you would like the client to ask for multiple resources that 
>> are managed by the same AS, correct?
>> 
>> 
>>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt 
>>>  wrote:
>>> For every bank (and their customers) there is a set of services run by the 
>>> bank or other entities, which rely on the AS of the particular bank for 
>>> authorization. In some cases, a service may bring its own AS to the party 
>>> (due to technical restrictionions). So an RP binding to a certain 
>>> bank-specific service ecosystem needs to determine which AS every RS relies 
>>> on. Authorization requests for RS relying on the same AS (the bank) can be 
>>> combined into s single request/flow resulting in an optimized UX.
>>> 
 Am 24.07.2018 um 22:21 schrieb Dick Hardt :
 
 I'm trying to understand the use case. 
 
 It still is vague. Are you saying that each of these is run by a different 
 entity, but all trust the bank as the authorization server to manage if 
 the user has granted permission to use the resource rather than managing 
 it themselves? 
 
 account information, payment initiation, identity, and electronic 
 signature 
 
>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
>>  wrote:
>> 
>> And who is the AS?
> 
> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
> central AS/IDP. 
> 
> Why are you asking?
> 
>> 
 On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
  wrote:
 
>>> 
 Am 23.07.2018 um 13:58 schrieb Dick Hardt :
 
 In your examples, are these the same AS?
>>> 
>>> yes
>>> 
 
 
 
> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>  wrote:
> Hi Dick,
> 
> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
> > 
> > Entering in an email address that resolves to a resource makes 
> > sense. It would seem that even if this was email, calendar etc. -- 
> > that those would be different scopes for the same AS, not even 
> > different resources. That is how all of Google, Microsoft work 
> > today.
> 
> I don’t know how those services work re OAuth resources. To me it’s 
> not obvious why one should make all those services a single OAuth 
> resource. I assume the fact OAuth as it is specified today has no 
> concept of identifying a resource and audience restrict an access 
> token led to designs not utilizing audience restriction. 
> 
> Can any of the Google or Microsoft on this list representatives 
> please comment?
> 
> In deployments I‘m familiar with email, calendar, contacts, cloud and 
> further services were treated as different resources and clients 
> needed different (audience restricted) access tokens to use it.
> 
> In case of YES, the locations of a user’s services for account 
> information, payment initiation, identity, and electronic signature 
> are determined based on her bank affiliation (bank identification 
> code). In general, each of these services may be provided/operated by 
> a different entity and exposed at completely different endpoints 
> (even different DNS domains).
> 
> kind regards,
> Torsten.
>> 
 
>> 


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> Am 24.07.2018 um 22:51 schrieb Dick Hardt :
> 
> Ok. I think I understand the use case now. Would you confirm?
> 
> These are deployed today, correct?

We are building up the scheme. One banking group is deployed.

> 
> Today, a separate flow us required for each RS, correct?

We support combined flows because this is a key requirement for us. But this 
comes at a price: we cannot tightly audience restrict our tokens. We use 
handles and Introspection to ensure every RS only gets to know the data it 
needs to know. And we must use sender constraint tokens in order to prevent 
token leakage. Having an interoperable way to obtain structured and audience 
restricted access tokens would simply development, reduce coupling between AS & 
RS and improve performance.

> 
> In the future, you would like the client to ask for multiple resources that 
> are managed by the same AS, correct?
> 
> 
>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt 
>>  wrote:
>> For every bank (and their customers) there is a set of services run by the 
>> bank or other entities, which rely on the AS of the particular bank for 
>> authorization. In some cases, a service may bring its own AS to the party 
>> (due to technical restrictionions). So an RP binding to a certain 
>> bank-specific service ecosystem needs to determine which AS every RS relies 
>> on. Authorization requests for RS relying on the same AS (the bank) can be 
>> combined into s single request/flow resulting in an optimized UX.
>> 
>>> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
>>> 
>>> I'm trying to understand the use case. 
>>> 
>>> It still is vague. Are you saying that each of these is run by a different 
>>> entity, but all trust the bank as the authorization server to manage if the 
>>> user has granted permission to use the resource rather than managing it 
>>> themselves? 
>>> 
>>> account information, payment initiation, identity, and electronic signature 
>>> 
 On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
  wrote:
 
> And who is the AS?
 
 In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
 central AS/IDP. 
 
 Why are you asking?
 
> 
>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>  wrote:
>> 
>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>> 
>>> In your examples, are these the same AS?
>> 
>> yes
>> 
>>> 
>>> 
>>> 
 On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
  wrote:
 Hi Dick,
 
 > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
 > 
 > Entering in an email address that resolves to a resource makes 
 > sense. It would seem that even if this was email, calendar etc. -- 
 > that those would be different scopes for the same AS, not even 
 > different resources. That is how all of Google, Microsoft work today.
 
 I don’t know how those services work re OAuth resources. To me it’s 
 not obvious why one should make all those services a single OAuth 
 resource. I assume the fact OAuth as it is specified today has no 
 concept of identifying a resource and audience restrict an access 
 token led to designs not utilizing audience restriction. 
 
 Can any of the Google or Microsoft on this list representatives please 
 comment?
 
 In deployments I‘m familiar with email, calendar, contacts, cloud and 
 further services were treated as different resources and clients 
 needed different (audience restricted) access tokens to use it.
 
 In case of YES, the locations of a user’s services for account 
 information, payment initiation, identity, and electronic signature 
 are determined based on her bank affiliation (bank identification 
 code). In general, each of these services may be provided/operated by 
 a different entity and exposed at completely different endpoints (even 
 different DNS domains).
 
 kind regards,
 Torsten.
> 
>>> 
> 


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

Ok. I think I understand the use case now. Would you confirm?

These are deployed today, correct?

Today, a separate flow us required for each RS, correct?

In the future, you would like the client to ask for multiple resources that
are managed by the same AS, correct?


On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> For every bank (and their customers) there is a set of services run by the
> bank or other entities, which rely on the AS of the particular bank for
> authorization. In some cases, a service may bring its own AS to the party
> (due to technical restrictionions). So an RP binding to a certain
> bank-specific service ecosystem needs to determine which AS every RS relies
> on. Authorization requests for RS relying on the same AS (the bank) can be
> combined into s single request/flow resulting in an optimized UX.
>
> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
>
> I'm trying to understand the use case.
>
> It still is vague. Are you saying that each of these is run by a
> different entity, but all trust the bank as the authorization server to
> manage if the user has granted permission to use the resource rather than
> managing it themselves?
>
> account information, payment initiation, identity, and electronic signature
>
>
> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>>
>> And who is the AS?
>>
>>
>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the
>> central AS/IDP.
>>
>> Why are you asking?
>>
>>
>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>>>
>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>>
>>> In your examples, are these the same AS?
>>>
>>>
>>> yes
>>>
>>>
>>>
>>>
>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <
>>> tors...@lodderstedt.net> wrote:
>>>
 Hi Dick,

 > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
 >
 > Entering in an email address that resolves to a resource makes sense..
 It would seem that even if this was email, calendar etc. -- that those
 would be different scopes for the same AS, not even different resources.
 That is how all of Google, Microsoft work today.

 I don’t know how those services work re OAuth resources. To me it’s not
 obvious why one should make all those services a single OAuth resource.. I
 assume the fact OAuth as it is specified today has no concept of
 identifying a resource and audience restrict an access token led to designs
 not utilizing audience restriction.

 Can any of the Google or Microsoft on this list representatives please
 comment?

 In deployments I‘m familiar with email, calendar, contacts, cloud and
 further services were treated as different resources and clients needed
 different (audience restricted) access tokens to use it.

 In case of YES, the locations of a user’s services for account
 information, payment initiation, identity, and electronic signature are
 determined based on her bank affiliation (bank identification code). In
 general, each of these services may be provided/operated by a different
 entity and exposed at completely different endpoints (even different DNS
 domains).

 kind regards,
 Torsten.
>>>
>>>
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

For every bank (and their customers) there is a set of services run by the bank 
or other entities, which rely on the AS of the particular bank for 
authorization. In some cases, a service may bring its own AS to the party (due 
to technical restrictionions). So an RP binding to a certain bank-specific 
service ecosystem needs to determine which AS every RS relies on. Authorization 
requests for RS relying on the same AS (the bank) can be combined into s single 
request/flow resulting in an optimized UX.

> Am 24.07.2018 um 22:21 schrieb Dick Hardt :
> 
> I'm trying to understand the use case. 
> 
> It still is vague. Are you saying that each of these is run by a different 
> entity, but all trust the bank as the authorization server to manage if the 
> user has granted permission to use the resource rather than managing it 
> themselves? 
> 
> account information, payment initiation, identity, and electronic signature 
> 
>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt 
>>  wrote:
>> 
>>> And who is the AS?
>> 
>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the 
>> central AS/IDP. 
>> 
>> Why are you asking?
>> 
>>> 
 On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
  wrote:
 
> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
> 
> In your examples, are these the same AS?
 
 yes
 
> 
> 
> 
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>  wrote:
>> Hi Dick,
>> 
>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>> > 
>> > Entering in an email address that resolves to a resource makes sense. 
>> > It would seem that even if this was email, calendar etc. -- that those 
>> > would be different scopes for the same AS, not even different 
>> > resources. That is how all of Google, Microsoft work today.
>> 
>> I don’t know how those services work re OAuth resources. To me it’s not 
>> obvious why one should make all those services a single OAuth resource. 
>> I assume the fact OAuth as it is specified today has no concept of 
>> identifying a resource and audience restrict an access token led to 
>> designs not utilizing audience restriction. 
>> 
>> Can any of the Google or Microsoft on this list representatives please 
>> comment?
>> 
>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>> further services were treated as different resources and clients needed 
>> different (audience restricted) access tokens to use it.
>> 
>> In case of YES, the locations of a user’s services for account 
>> information, payment initiation, identity, and electronic signature are 
>> determined based on her bank affiliation (bank identification code). In 
>> general, each of these services may be provided/operated by a different 
>> entity and exposed at completely different endpoints (even different DNS 
>> domains).
>> 
>> kind regards,
>> Torsten.
>>> 
> 


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

I'm trying to understand the use case.

It still is vague. Are you saying that each of these is run by a different
entity, but all trust the bank as the authorization server to manage if the
user has granted permission to use the resource rather than managing it
themselves?

account information, payment initiation, identity, and electronic signature

On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>
> And who is the AS?
>
>
> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the
> central AS/IDP.
>
> Why are you asking?
>
>
> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>>
>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>
>> In your examples, are these the same AS?
>>
>>
>> yes
>>
>>
>>
>>
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>>> Hi Dick,
>>>
>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>>> >
>>> > Entering in an email address that resolves to a resource makes sense.
>>> It would seem that even if this was email, calendar etc. -- that those
>>> would be different scopes for the same AS, not even different resources..
>>> That is how all of Google, Microsoft work today.
>>>
>>> I don’t know how those services work re OAuth resources. To me it’s not
>>> obvious why one should make all those services a single OAuth resource. I
>>> assume the fact OAuth as it is specified today has no concept of
>>> identifying a resource and audience restrict an access token led to designs
>>> not utilizing audience restriction.
>>>
>>> Can any of the Google or Microsoft on this list representatives please
>>> comment?
>>>
>>> In deployments I‘m familiar with email, calendar, contacts, cloud and
>>> further services were treated as different resources and clients needed
>>> different (audience restricted) access tokens to use it.
>>>
>>> In case of YES, the locations of a user’s services for account
>>> information, payment initiation, identity, and electronic signature are
>>> determined based on her bank affiliation (bank identification code). In
>>> general, each of these services may be provided/operated by a different
>>> entity and exposed at completely different endpoints (even different DNS
>>> domains).
>>>
>>> kind regards,
>>> Torsten.
>>
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> And who is the AS?

In case of yes, it’s typically the bank. At Deutsche Telekom, it is the central 
AS/IDP. 

Why are you asking?

> 
>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt 
>>  wrote:
>> 
>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>> 
>>> In your examples, are these the same AS?
>> 
>> yes
>> 
>>> 
>>> 
>>> 
 On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
  wrote:
 Hi Dick,
 
 > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
 > 
 > Entering in an email address that resolves to a resource makes sense. It 
 > would seem that even if this was email, calendar etc. -- that those 
 > would be different scopes for the same AS, not even different resources. 
 > That is how all of Google, Microsoft work today.
 
 I don’t know how those services work re OAuth resources. To me it’s not 
 obvious why one should make all those services a single OAuth resource. I 
 assume the fact OAuth as it is specified today has no concept of 
 identifying a resource and audience restrict an access token led to 
 designs not utilizing audience restriction. 
 
 Can any of the Google or Microsoft on this list representatives please 
 comment?
 
 In deployments I‘m familiar with email, calendar, contacts, cloud and 
 further services were treated as different resources and clients needed 
 different (audience restricted) access tokens to use it.
 
 In case of YES, the locations of a user’s services for account 
 information, payment initiation, identity, and electronic signature are 
 determined based on her bank affiliation (bank identification code). In 
 general, each of these services may be provided/operated by a different 
 entity and exposed at completely different endpoints (even different DNS 
 domains).
 
 kind regards,
 Torsten.
> 


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

And who is the AS?

On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

>
> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>
> In your examples, are these the same AS?
>
>
> yes
>
>
>
>
> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi Dick,
>>
>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>> >
>> > Entering in an email address that resolves to a resource makes sense.
>> It would seem that even if this was email, calendar etc. -- that those
>> would be different scopes for the same AS, not even different resources.
>> That is how all of Google, Microsoft work today.
>>
>> I don’t know how those services work re OAuth resources. To me it’s not
>> obvious why one should make all those services a single OAuth resource. I
>> assume the fact OAuth as it is specified today has no concept of
>> identifying a resource and audience restrict an access token led to designs
>> not utilizing audience restriction.
>>
>> Can any of the Google or Microsoft on this list representatives please
>> comment?
>>
>> In deployments I‘m familiar with email, calendar, contacts, cloud and
>> further services were treated as different resources and clients needed
>> different (audience restricted) access tokens to use it.
>>
>> In case of YES, the locations of a user’s services for account
>> information, payment initiation, identity, and electronic signature are
>> determined based on her bank affiliation (bank identification code). In
>> general, each of these services may be provided/operated by a different
>> entity and exposed at completely different endpoints (even different DNS
>> domains).
>>
>> kind regards,
>> Torsten.
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
> 
> In your examples, are these the same AS?

yes

> 
> 
> 
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
>>  wrote:
>> Hi Dick,
>> 
>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>> > 
>> > Entering in an email address that resolves to a resource makes sense. It 
>> > would seem that even if this was email, calendar etc. -- that those would 
>> > be different scopes for the same AS, not even different resources. That is 
>> > how all of Google, Microsoft work today.
>> 
>> I don’t know how those services work re OAuth resources. To me it’s not 
>> obvious why one should make all those services a single OAuth resource. I 
>> assume the fact OAuth as it is specified today has no concept of identifying 
>> a resource and audience restrict an access token led to designs not 
>> utilizing audience restriction. 
>> 
>> Can any of the Google or Microsoft on this list representatives please 
>> comment?
>> 
>> In deployments I‘m familiar with email, calendar, contacts, cloud and 
>> further services were treated as different resources and clients needed 
>> different (audience restricted) access tokens to use it.
>> 
>> In case of YES, the locations of a user’s services for account information, 
>> payment initiation, identity, and electronic signature are determined based 
>> on her bank affiliation (bank identification code). In general, each of 
>> these services may be provided/operated by a different entity and exposed at 
>> completely different endpoints (even different DNS domains).
>> 
>> kind regards,
>> Torsten.


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

In your examples, are these the same AS?



On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt 
wrote:

> Hi Dick,
>
> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
> >
> > Entering in an email address that resolves to a resource makes sense. It
> would seem that even if this was email, calendar etc. -- that those would
> be different scopes for the same AS, not even different resources. That is
> how all of Google, Microsoft work today.
>
> I don’t know how those services work re OAuth resources. To me it’s not
> obvious why one should make all those services a single OAuth resource. I
> assume the fact OAuth as it is specified today has no concept of
> identifying a resource and audience restrict an access token led to designs
> not utilizing audience restriction.
>
> Can any of the Google or Microsoft on this list representatives please
> comment?
>
> In deployments I‘m familiar with email, calendar, contacts, cloud and
> further services were treated as different resources and clients needed
> different (audience restricted) access tokens to use it.
>
> In case of YES, the locations of a user’s services for account
> information, payment initiation, identity, and electronic signature are
> determined based on her bank affiliation (bank identification code). In
> general, each of these services may be provided/operated by a different
> entity and exposed at completely different endpoints (even different DNS
> domains).
>
> kind regards,
> Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt :
> 
> Entering in an email address that resolves to a resource makes sense. It 
> would seem that even if this was email, calendar etc. -- that those would be 
> different scopes for the same AS, not even different resources. That is how 
> all of Google, Microsoft work today.

I don’t know how those services work re OAuth resources. To me it’s not obvious 
why one should make all those services a single OAuth resource. I assume the 
fact OAuth as it is specified today has no concept of identifying a resource 
and audience restrict an access token led to designs not utilizing audience 
restriction. 

Can any of the Google or Microsoft on this list representatives please comment?

In deployments I‘m familiar with email, calendar, contacts, cloud and further 
services were treated as different resources and clients needed different 
(audience restricted) access tokens to use it.

In case of YES, the locations of a user’s services for account information, 
payment initiation, identity, and electronic signature are determined based on 
her bank affiliation (bank identification code). In general, each of these 
services may be provided/operated by a different entity and exposed at 
completely different endpoints (even different DNS domains).

kind regards,
Torsten.

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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Dick,
>
> Am 19.07.2018 um 15:46 schrieb Dick Hardt :
>
> I think any scenario with multiple resource servers relying on the same AS
>> for authorization where the client acts on behalf of the resource owner
>> qualifies for grant type code and distributed OAuth.
>>
>> Let’s assume a user wants to authorize a client for access to her cloud
>> storage, email account and contacts when setting app the respective app.
>>
>
> Would you walk me through the user experience that happened for the client
> to do discovery on these three resources? In other words, what did the user
> do to get the client to call the resource and get back the 401 response?
>
>
> I would assume the user enters the URLs or identifies the respective
> service providers in the app (e.g. by entering her email address). The
> client then sends an initial request as described in your draft and gets
> back the 401.
>

Entering in an email address that resolves to a resource makes sense. It
would seem that even if this was email, calendar etc. -- that those would
be different scopes for the same AS, not even different resources. That is
how all of Google, Microsoft work today.

It seems improbable that an end user is going to post multiple resource end
points. But I'm interested if you can present such a use case.



>
> Doing so for several resources will give the client the AS URL for all
> involved resources. If the client compares the iss claims it will figure
> our all resources are protected by the same AS and can authorize access via
> a single authz code grant flow.
>

Today, if you had a Google hosted email and a Microsoft hosted email, you
would have different AS.

Do you have another example?



>
> kind regards,
> Torsten.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

Am 19.07.2018 um 15:46 schrieb Dick Hardt :

>> I think any scenario with multiple resource servers relying on the same AS 
>> for authorization where the client acts on behalf of the resource owner 
>> qualifies for grant type code and distributed OAuth. 
>> 
>> Let’s assume a user wants to authorize a client for access to her cloud 
>> storage, email account and contacts when setting app the respective app.
> 
> Would you walk me through the user experience that happened for the client to 
> do discovery on these three resources? In other words, what did the user do 
> to get the client to call the resource and get back the 401 response?

I would assume the user enters the URLs or identifies the respective service 
providers in the app (e.g. by entering her email address). The client then 
sends an initial request as described in your draft and gets back the 401.

Doing so for several resources will give the client the AS URL for all involved 
resources. If the client compares the iss claims it will figure our all 
resources are protected by the same AS and can authorize access via a single 
authz code grant flow.

kind regards,
Torsten.

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

Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite]

There is also existing software that expects to be able to act/respond based 
only on the WWW-Authenticate header. See

https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header)
 
<https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header)>

-DW

> On Jul 20, 2018, at 2:33 AM, n-sakimura  wrote:
> 
> Hi David, 
>  
> Thanks for the comment, and sorry for the delay in my reply.
>  
> Doing it with Web Linking [RFC8288]  has several advantages.
>  
> It is standard based J It is just a matter of registering link relations to 
> the IANA Link Relation Type Registry, and it is quite widely used.
> No or very little coding needed: Other than adding some HTTP server 
> configuration, the rest stays the same as RFC6750.
> Standard interface: this kind of metadata is applicable not only for letting 
> the client find the appropriate authorization server but for other metadata 
> as well. Also, other endpoints as long as it is supporting the direct 
> communication with the client, can provide relevant metadata with it without 
> going through the client authorization.
>  
> I did not quite follow why CORS is relevant here. We are just talking about 
> the client to server communication, and there are no embedded resources in 
> the response. Could you kindly elaborate a little, please? 
>  
> For the second point, since it was discussed in the WG meeting yesterday, I 
> will defer to that discussion.
>  
> Best, 
>  
> Nat Sakimura
>  
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>  
> Four comments.
>  
> First: What is the rationale for including the parameters as Link headers 
> rather than part of the WWW-Authenticate challenge, e.g.:
>  
> WWW-Authenticate: Bearer realm="example_realm",
>  scope="example_scope",
>  error=“invalid_token",
> resource_uri="https://api.example.com/resource 
> <https://api.example.com/resource>",
> 
> oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
>  <https://as.example.com/.well-known/oauth-authorization-server> 
> https://different-as.example.com/.well-known/oauth-authorization-server 
> <https://different-as.example.com/.well-known/oauth-authorization-server>"
>  
> 
> My understanding is that the RFC6750 auth-params are extensible (but not 
> currently part of any managed registry.)
>  
> One reason to go with this vs Link headers is CORS policy - exposing Link 
> headers to a remote client must be done all or nothing as part of the CORS 
> policy, and can’t be limited by the kind of link.
>  
> Second: (retaining link format) Is there a reason the metadata location is 
> specified the way it is? It seems like
>  
> <https://as.example.com/.well-known/oauth-authorization-server 
> <https://as.example.com/.well-known/oauth-authorization-server>>; 
> rel=“oauth_server_metadata_uri"
>  
> should be
>  
> <https://as.example.com <https://as.example.com/>>; rel=“oauth_issuer"
>  
> OAuth defines the location of metadata under the .well-known endpoint as a 
> MUST. An extension of OAuth may choose from at least three different methods 
> for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their 
> extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
> using a different mechanism for specifying metadata
>  
> Given all this, it seems appropriate to only support specifying of 
> metadata-supplying issuers, not metadata uris.
>  
> Third: I have doubts of the usefulness of resource_uri in parallel to both 
> the client requested URI and the Authorization “realm” parameter.
>  
> As currently defined, the client would be the one enforcing (or possibly 
> ignoring) static policy around resource URIs - that a resource URI is 
> arbitrary except in that it must match the host (and scheme/port?) of the 
> requested URI. The information on the requested URI by the client is not 
> shared between the client and AS for it to do its own policy verification. It 
> would seem better to send the client origin to the AS for it to do 
> (potential) policy verif

Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite]

> On Jul 20, 2018, at 2:33 AM, n-sakimura  wrote:
> 
> I did not quite follow why CORS is relevant here. We are just talking about 
> the client to server communication, and there are no embedded resources in 
> the response. Could you kindly elaborate a little, please? 

Sure!  It is effectively an additional (complex) restriction on 
implementation/capabilities of CORS and the design of the resources.

There are five possible access results for a resource that come to mind:
1. Client does not have authorization but gets a (possibly limited) entity 
response
2. Client does not have authorization and is challenged
3. Client has authorization and gets a (possibly customized) entity response
4. Client has insufficient authorization and is challenged (e.g. for a new 
access token, possibly with more scopes)
5. Client has insufficient authorization and is refused access

The CORS policies returned for 1 and 3 may be different than 2 and 4, may be 
different for 5, and may come from different infrastructure (such as an 
authenticating reverse proxy “gateway”). Note also that cases 1 and 3 may have 
a WWW-Authenticate header on the response, indicating that providing 
authorization may return a different entity response.

One way to handle remote access for all of these cases with commonality would 
be to expose the WWW-Authenticate header via the CORS policy.

With the Link header used as well, you would need to also expose the Link 
header in all of these cases (or at least 1-4). However, the Link header can 
return many relations beyond this one authorization use case, and you would be 
exposing those all-or-nothing. 

You effectively lose the ability to regulate visibility of the Link header via 
CORS, and must resort to selective disclosure of headers as your mechanism of 
control (or serialize those links in another way such as within the content 
body, when an available option)

-DW

>  
> For the second point, since it was discussed in the WG meeting yesterday, I 
> will defer to that discussion.
>  
> Best, 
>  
> Nat Sakimura
>  
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>  
> Four comments.
>  
> First: What is the rationale for including the parameters as Link headers 
> rather than part of the WWW-Authenticate challenge, e.g.:
>  
> WWW-Authenticate: Bearer realm="example_realm",
>  scope="example_scope",
>  error=“invalid_token",
> resource_uri="https://api.example.com/resource 
> <https://api.example.com/resource>",
> 
> oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
>  <https://as.example.com/.well-known/oauth-authorization-server> 
> https://different-as.example.com/.well-known/oauth-authorization-server 
> <https://different-as.example.com/.well-known/oauth-authorization-server>"
>  
> 
> My understanding is that the RFC6750 auth-params are extensible (but not 
> currently part of any managed registry.)
>  
> One reason to go with this vs Link headers is CORS policy - exposing Link 
> headers to a remote client must be done all or nothing as part of the CORS 
> policy, and can’t be limited by the kind of link.
>  
> Second: (retaining link format) Is there a reason the metadata location is 
> specified the way it is? It seems like
>  
> <https://as.example.com/.well-known/oauth-authorization-server 
> <https://as.example.com/.well-known/oauth-authorization-server>>; 
> rel=“oauth_server_metadata_uri"
>  
> should be
>  
> <https://as.example.com <https://as.example.com/>>; rel=“oauth_issuer"
>  
> OAuth defines the location of metadata under the .well-known endpoint as a 
> MUST. An extension of OAuth may choose from at least three different methods 
> for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their 
> extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
> using a different mechanism for specifying metadata
>  
> Given all this, it seems appropriate to only support specifying of 
> metadata-supplying issuers, not metadata uris.
>  
> Third: I have doubts of the usefulness of resource_uri in parallel to both 
> the client requested URI and the Authorization “realm” parameter.
>  
> As currently defined, the client would be the one enforcing (or possibly 
> ignoring) static policy around

Re: [OAUTH-WG] updated Distributed OAuth ID

[n-sakimura]

Hi David,

Thanks for the comment, and sorry for the delay in my reply.

Doing it with Web Linking [RFC8288]  has several advantages.


  1.  It is standard based ☺ It is just a matter of registering link relations 
to the IANA Link Relation Type Registry, and it is quite widely used.
  2.  No or very little coding needed: Other than adding some HTTP server 
configuration, the rest stays the same as RFC6750.
  3.  Standard interface: this kind of metadata is applicable not only for 
letting the client find the appropriate authorization server but for other 
metadata as well. Also, other endpoints as long as it is supporting the direct 
communication with the client, can provide relevant metadata with it without 
going through the client authorization.

I did not quite follow why CORS is relevant here. We are just talking about the 
client to server communication, and there are no embedded resources in the 
response. Could you kindly elaborate a little, please?

For the second point, since it was discussed in the WG meeting yesterday, I 
will defer to that discussion.

Best,

Nat Sakimura


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
Sent: Thursday, July 19, 2018 4:55 PM
To: Dick Hardt 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

Four comments.

First: What is the rationale for including the parameters as Link headers 
rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm="example_realm",
 scope="example_scope",
 error=“invalid_token",
resource_uri="https://api.example.com/resource;,

oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
 https://different-as.example.com/.well-known/oauth-authorization-server;

My understanding is that the RFC6750 auth-params are extensible (but not 
currently part of any managed registry.)

One reason to go with this vs Link headers is CORS policy - exposing Link 
headers to a remote client must be done all or nothing as part of the CORS 
policy, and can’t be limited by the kind of link.

Second: (retaining link format) Is there a reason the metadata location is 
specified the way it is? It seems like

<https://as.example.com/.well-known/oauth-authorization-server>; 
rel=“oauth_server_metadata_uri"

should be

<https://as.example.com>; rel=“oauth_issuer"

OAuth defines the location of metadata under the .well-known endpoint as a 
MUST. An extension of OAuth may choose from at least three different methods 
for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting their 
extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
using a different mechanism for specifying metadata

Given all this, it seems appropriate to only support specifying of 
metadata-supplying issuers, not metadata uris.

Third: I have doubts of the usefulness of resource_uri in parallel to both the 
client requested URI and the Authorization “realm” parameter.

As currently defined, the client would be the one enforcing (or possibly 
ignoring) static policy around resource URIs - that a resource URI is arbitrary 
except in that it must match the host (and scheme/port?) of the requested URI. 
The information on the requested URI by the client is not shared between the 
client and AS for it to do its own policy verification. It would seem better to 
send the client origin to the AS for it to do (potential) policy verification, 
rather than relying on clients to implement it for them based on static spec 
policy.

The name “resource URI” is also confusing, as I would expect it to be the URI 
that was requested by the client. The purpose of this parameter is a bit 
confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified 
in [RFC6750] section 3.2 - where the term doesn’t appear in 6750 and there does 
not appear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the client, 
it is redundant and should be dropped
(If the resource URI is *not* a direct match with the URI of the resource 
requested by the client, it might need a better name).
b. If the resource URI is meant to provide a certain arbitrary grouping for 
applying tokens within the origin of the resource server, what is its value 
over the preexisting “ realm” parameter?
c. If the resource URI is meant to provide a way for an AS to allow resources 
to be independent, identified entities on a single origin - I’m unsure how a 
client would understand it is meant to treat these resource URIs as independent 
entities (e.g. be sure not to send bearer tokens minted for resource /entity1 
to /entity2, or for that mat

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Dick,
>
>
>
>>
>> Section 3:
>> Don’t you think it could be a useful information to have the resource URI
>> available in the authorization flow?I would assume it could have some
>> additional meaning to the AS and could also be the context of the scope.
>>
>
> I'm assuming you are referring to the Authorization Code Grant. Good call
> out that the resource URI would be useful in the redirect.
>
> The use cases that I have been working with have all been Client
> Credential Grants
>
> I currently don't know of a real world use case for the Authorization Code
> Grant for Distributed OAuth.
>
>
> I think any scenario with multiple resource servers relying on the same AS
> for authorization where the client acts on behalf of the resource owner
> qualifies for grant type code and distributed OAuth.
>
> Let’s assume a user wants to authorize a client for access to her cloud
> storage, email account and contacts when setting app the respective app.
>

Would you walk me through the user experience that happened for the client
to do discovery on these three resources? In other words, what did the user
do to get the client to call the resource and get back the 401 response?

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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

David, thanks for the detailed feedback ... responses inline ...

On Thu, Jul 19, 2018 at 3:54 AM, David Waite 
wrote:

> Four comments.
>
> First: What is the rationale for including the parameters as Link headers
> rather than part of the WWW-Authenticate challenge, e.g.:
>
> WWW-Authenticate: Bearer realm="example_realm",
>  scope="example_scope",
>  error=“invalid_token",
> resource_uri="https://api.example.com/resource;,
> oauth_server_metadata_uris="https://as.example.com/.well-
> known/oauth-authorization-server https://different-as.example.
> com/.well-known/oauth-authorization-server"
>
>
> My understanding is that the RFC6750 auth-params are extensible (but not
> currently part of any managed registry.)
>
> One reason to go with this vs Link headers is CORS policy - exposing Link
> headers to a remote client must be done all or nothing as part of the CORS
> policy, and can’t be limited by the kind of link.
>
>
Nat had a good argument for using Link headers, I'll let him respond.


> Second: (retaining link format) Is there a reason the metadata location is
> specified the way it is? It seems like
>
> ;
> rel=“oauth_server_metadata_uri"
>
> should be
>
> ; rel=“oauth_issuer"
>
> OAuth defines the location of metadata under the .well-known endpoint as a
> MUST. An extension of OAuth may choose from at least three different
> methods for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their
> extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”,
> potentially using a different mechanism for specifying metadata
>
> Given all this, it seems appropriate to only support specifying of
> metadata-supplying issuers, not metadata uris.
>

Interesting, what do others think of this?

There is a security advantage of using a predefined path as a malicious RS
can not have the client fetch a different meta data document than the one
that is at the well known location.


>
> Third: I have doubts of the usefulness of resource_uri in parallel to both
> the client requested URI and the Authorization “realm” parameter.
>
> As currently defined, the client would be the one enforcing (or possibly
> ignoring) static policy around resource URIs - that a resource URI is
> arbitrary except in that it must match the host (and scheme/port?) of the
> requested URI. The information on the requested URI by the client is not
> shared between the client and AS for it to do its own policy verification..
> It would seem better to send the client origin to the AS for it to do
> (potential) policy verification, rather than relying on clients to
> implement it for them based on static spec policy.
>
> The name “resource URI” is also confusing, as I would expect it to be the
> URI that was requested by the client. The purpose of this parameter is a
> bit confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint
> specified in [RFC6750] section 3.2 - where the term doesn’t appear in 6750
> and there does not appear to be a section 3.2 ;-)
>
> It seems that:
> a. If the resource_uri is a direct match for the URI requested for the
> client, it is redundant and should be dropped
> (If the resource URI is *not* a direct match with the URI of the
> resource requested by the client, it might need a better name).
>

It is not a direct match. Open to new name suggestions!


> b. If the resource URI is meant to provide a certain arbitrary grouping
> for applying tokens within the origin of the resource server, what is its
> value over the preexisting “ realm” parameter?
>

It is not arbitrary. The resource URI MUST be contained in the URI the
client is requesting access to. The hostname in the resource URI must be in
the hostname in the TLS certificate. This lets the client ensure it is
requesting an access token that is intended for the resource it is
accessing.

The realm parameter does not have these characteristics specified, and may
already be used for other purposes.


> c. If the resource URI is meant to provide a way for an AS to allow
> resources to be independent, identified entities on a single origin - I’m
> unsure how a client would understand it is meant to treat these resource
> URIs as independent entities (e.g. be sure not to send bearer tokens minted
> for resource /entity1 to /entity2, or for that matter prevent /entity1 from
> requesting tokens for /entity2).
>

It is intended for the client to enforce.


>
> Admittedly based on not fully understanding the purpose of this parameter,
> it seems to me there exists a simpler flow which better leverages the
> existing Authentication mechanism of HTTP.
>
> A request would fail due to an invalid or missing token 

Re: [OAUTH-WG] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

>  
>> 
>> Section 3: 
>> Don’t you think it could be a useful information to have the resource URI 
>> available in the authorization flow?I would assume it could have some 
>> additional meaning to the AS and could also be the context of the scope.
> 
> I'm assuming you are referring to the Authorization Code Grant. Good call out 
> that the resource URI would be useful in the redirect. 
> 
> The use cases that I have been working with have all been Client Credential 
> Grants
> 
> I currently don't know of a real world use case for the Authorization Code 
> Grant for Distributed OAuth.

I think any scenario with multiple resource servers relying on the same AS for 
authorization where the client acts on behalf of the resource owner qualifies 
for grant type code and distributed OAuth. 

Let’s assume a user wants to authorize a client for access to her cloud 
storage, email account and contacts when setting app the respective app.

One would use the code grant type for that use case. And having the resource 
URLs in the authorization flow would allow the AS to further determine the 
context of the requested authorization.

Even more important, the AS could restrict the access tokens for use at this 
URIs only. At best, the AS would allow the client to obtain different access 
tokens for any of the involved resource servers, each of them tailored to the 
needs of the particular RS (content) and bound to it (aud, token binding, ...).

In the YES context, we have several different services/resources, which can be 
combined in a single authorization transaction, e.g. initiation of a payment 
and creating an electronic signature.

In all solutions I have seen or designed in the past, the resource server was 
either carried in the scope parameter or implicitly determined from the scope 
values (see OIDC). Making it explicit would result in an interoperable approach 
to represent this information and use it to tighten up OAuth security and 
privacy (token binding, audience restriction).

kind regards,
Torsten.

>  
>> 
>> Section 4: 
>> I think the client MUST authenticate using a PoP (asymmetric crypto based) 
>> mechanisms due to the attack angle given in 6.3
>> Did you intentionally restricted the draft to single resources?
> 
> yes
>  
>> I would desire support for an integrated UI flow for authorizing access to 
>> multiple resources at once. This makes sense in multi-service deployments.
> 
> It could be. Would be great to get some real use cases for that in an 
> Authorization Code Grant.
>  
>> 
>> Section 6.1. 
>> I suggest you also refer to 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.7 
>> for a comprehensive discussion of this threat..
> 
> Thanks
>  
>> 
>> kind regards,
>> Torsten.   
>> 
>> 
>> > Am 12.06.2018 um 21:28 schrieb Dick Hardt :
>> > 
>> > Hey OAuth WG
>> > 
>> > I have worked with Nat and Brian to merge our concepts and those are 
>> > captured in the updated draft.
>> > 
>> > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>> > 
>> > We are hopeful the WG will adopt this draft as a WG document.
>> > 
>> > Any comments and feedback are welcome!
>> > 
>> > /Dick
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> 
> 


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

Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite]

Four comments.

First: What is the rationale for including the parameters as Link headers 
rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm="example_realm",
 scope="example_scope",
 error=“invalid_token",
resource_uri="https://api.example.com/resource;,

oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
 https://different-as.example.com/.well-known/oauth-authorization-server;


My understanding is that the RFC6750 auth-params are extensible (but not 
currently part of any managed registry.)

One reason to go with this vs Link headers is CORS policy - exposing Link 
headers to a remote client must be done all or nothing as part of the CORS 
policy, and can’t be limited by the kind of link.

Second: (retaining link format) Is there a reason the metadata location is 
specified the way it is? It seems like

; 
rel=“oauth_server_metadata_uri"

should be

; rel=“oauth_issuer"

OAuth defines the location of metadata under the .well-known endpoint as a 
MUST. An extension of OAuth may choose from at least three different methods 
for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting their 
extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
using a different mechanism for specifying metadata

Given all this, it seems appropriate to only support specifying of 
metadata-supplying issuers, not metadata uris.

Third: I have doubts of the usefulness of resource_uri in parallel to both the 
client requested URI and the Authorization “realm” parameter.

As currently defined, the client would be the one enforcing (or possibly 
ignoring) static policy around resource URIs - that a resource URI is arbitrary 
except in that it must match the host (and scheme/port?) of the requested URI. 
The information on the requested URI by the client is not shared between the 
client and AS for it to do its own policy verification. It would seem better to 
send the client origin to the AS for it to do (potential) policy verification, 
rather than relying on clients to implement it for them based on static spec 
policy.

The name “resource URI” is also confusing, as I would expect it to be the URI 
that was requested by the client. The purpose of this parameter is a bit 
confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified 
in [RFC6750] section 3.2 - where the term doesn’t appear in 6750 and there does 
not appear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the client, 
it is redundant and should be dropped
(If the resource URI is *not* a direct match with the URI of the resource 
requested by the client, it might need a better name).
b. If the resource URI is meant to provide a certain arbitrary grouping for 
applying tokens within the origin of the resource server, what is its value 
over the preexisting “ realm” parameter?
c. If the resource URI is meant to provide a way for an AS to allow resources 
to be independent, identified entities on a single origin - I’m unsure how a 
client would understand it is meant to treat these resource URIs as independent 
entities (e.g. be sure not to send bearer tokens minted for resource /entity1 
to /entity2, or for that matter prevent /entity1 from requesting tokens for 
/entity2).

Admittedly based on not fully understanding the purpose of this parameter, it 
seems to me there exists a simpler flow which better leverages the existing 
Authentication mechanism of HTTP. 

A request would fail due to an invalid or missing token for the realm at the 
origin, and and the client would make a request to the issuer including the 
origin of the requested resource as a parameter. Any other included parameters 
specified by the WWW-Authenticate challenge understood by the client (such as 
“scope”) would also be applied to this request.

Normal authorization grant flow would then happen (as this is the only grant 
type supported by RFC6750). Once the access token is acquired by the client, 
the client associates that token with the “realm” parameter given in the 
initial challenge by the resource server origin. Likewise, the ‘aud’ of the 
token as returned by a token introspection process would be the origin of the 
resource server.

It seems any more complicated protected resource groupings on a resource server 
would need a client to understand the structure of the resource server, and 
thus fetch some sort of resource server metadata.

Fourth and finally: Is the intention to eventually recommend token binding 
here? Token binding as a requirement across clients, resources, 

Re: [OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

Thanks for the review Torsten! ... comments inserted ...

On Tue, Jul 17, 2018 at 11:59 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Dick,
>
> I like the draft! It puts together some best practices relevant for
> dynamic OAuth in a reasonable way.
>
> Some comments:
>
> Section 2:
> I appreciate the idea to let the resource determine its resource URI
> (later used as aud of the access token). This will allow the RS to segment
> and group its resources as needed.
>

:)


>
> Section 3:
> Don’t you think it could be a useful information to have the resource URI
> available in the authorization flow?I would assume it could have some
> additional meaning to the AS and could also be the context of the scope.
>

I'm assuming you are referring to the Authorization Code Grant. Good call
out that the resource URI would be useful in the redirect.

The use cases that I have been working with have all been Client Credential
Grants

I currently don't know of a real world use case for the Authorization Code
Grant for Distributed OAuth.


>
> Section 4:
> I think the client MUST authenticate using a PoP (asymmetric crypto based)
> mechanisms due to the attack angle given in 6.3
> Did you intentionally restricted the draft to single resources?


yes


> I would desire support for an integrated UI flow for authorizing access to
> multiple resources at once. This makes sense in multi-service deployments..
>

It could be. Would be great to get some real use cases for that in an
Authorization Code Grant.


>
> Section 6.1.
> I suggest you also refer to https://tools.ietf.org/html/
> draft-ietf-oauth-security-topics-06#section-3.7 for a comprehensive
> discussion of this threat.
>

Thanks


>
> kind regards,
> Torsten.
>
>
> > Am 12.06.2018 um 21:28 schrieb Dick Hardt :
> >
> > Hey OAuth WG
> >
> > I have worked with Nat and Brian to merge our concepts and those are
> captured in the updated draft.
> >
> > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
> >
> > We are hopeful the WG will adopt this draft as a WG document.
> >
> > Any comments and feedback are welcome!
> >
> > /Dick
> > ___
> > 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] updated Distributed OAuth ID

[Torsten Lodderstedt]

Hi Dick,

I like the draft! It puts together some best practices relevant for dynamic 
OAuth in a reasonable way.

Some comments: 

Section 2: 
I appreciate the idea to let the resource determine its resource URI (later 
used as aud of the access token). This will allow the RS to segment and group 
its resources as needed.

Section 3: 
Don’t you think it could be a useful information to have the resource URI 
available in the authorization flow?I would assume it could have some 
additional meaning to the AS and could also be the context of the scope.

Section 4: 
I think the client MUST authenticate using a PoP (asymmetric crypto based) 
mechanisms due to the attack angle given in 6.3
Did you intentionally restricted the draft to single resources? I would desire 
support for an integrated UI flow for authorizing access to multiple resources 
at once. This makes sense in multi-service deployments.

Section 6.1. 
I suggest you also refer to 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.7 for 
a comprehensive discussion of this threat.

kind regards,
Torsten.   


> Am 12.06.2018 um 21:28 schrieb Dick Hardt :
> 
> Hey OAuth WG
> 
> I have worked with Nat and Brian to merge our concepts and those are captured 
> in the updated draft.
> 
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
> 
> We are hopeful the WG will adopt this draft as a WG document.
> 
> Any comments and feedback are welcome!
> 
> /Dick
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

Re: [OAUTH-WG] updated Distributed OAuth ID

[Brian Campbell]

Thanks for the review and suggestions, Jared. A token (pun intended!)
attempt at addressing your comments follows.

Though I don't think I actually discussed it with my co-authors, I did
think about the link relation for the AS being the issuer rather than
pointing to the metadata document under ".well-known".  I must admit that I
kinda liked using the full URL to the metadata because it relieved the
client from having to figure it out from the issuer. Which could be
cumbersome for clients given that there's both
".well-known/openid-configuration"
and the soon to be ".well-known/oauth-authorization-server" as well as
different procedures for forming the full metadata URL from the issuer
value when the issuer contains a path component. Having said that though,
I'm inclined to agree with you that the *right* thing to do here is have
the link relation to the AS be just the issuer value. Or at lest invite
more discussion about it. "oauth2-isser" seems a perfectly reasonable
relation name, should we take that route.

The idea behind the "resource_uri" link relation (and this likely needs to
be expanded on better in the document) is that it is like the base URL of
the application or set of protected resources. So, for example, both a
request to https://api.example.com/someapp/stuff/abc123 and
https://api.example.com/someapp/stuff/xyz789 might get a 401 with
resource_uri link relation value of . Or
a requests to https://resources.example.com/some/deeper/path/here and
https://resources.example.com/things might both get a 401 with resource_uri
link relation value of . RFC6596 says in
the abstract that the "canonical" Link Relation is used to "designate an
Internationalized Resource Identifier (IRI) as preferred over resources
with duplicative content".  "canonical" doesn't seem to fit the purpose
from that text and reading RFC6596 didn't help me see it fit either. I
looked through the registry for Link Relation Types and nothing jumped out
at me as being applicable for this.

The client check of the host in the link relation to the host where the
request was made is intended to protect against what the draft calls
Resource Server Impersonation in 6.2 where a bad RS would return a 401 with
a link relation for a different sever which would result in the client
asking for a token for that different server but using it with the bad
server, who in turn could replay it at the different server. PoP tokens
could also prevent such replay in a different way but for bearer tokens I
think the check is needed to ensure the right audience gets into the token.




On Tue, Jun 12, 2018 at 4:57 PM, Jared Hanson  wrote:

> Thanks Dick, Nat and Brian for your work on this ID.  I have a couple
> improvements I would like to discuss:
>
> I would suggest replacing the "oauth_server_metadata_uri" link relation
> with "oauth2-isser", and dropping the ".well-known" suffix from the value..
> For example:
>
> Link: ; rel="oauth2-issuer"
>
> The rationale for this are two-fold:
>
> 1. It allows the discovery mechanism to be more flexible, or application
> specific.  For instance, OpenID Connect discovery could be used and take
> advantage of already deployed ".well-known/openid-configuration"
> documents.  Applications could also take advantage of other discovery
> mechanisms, either now (such as LRDD and WebFinger) or in the future.
>
> 2.. It aligns the syntax (underscores vs dash) with
> https://tools.ietf.org/html/draft-wmills-oauth-lrdd-07
> (which I also think should be revived as link relations).  Also, existing
> conventions with registered link relations seem to prefer dashes rather
> than underscores.
>
> I would suggest replacing the "resource_uri" link relation with
> "canonical" (RFC6596), which seems to fit the purpose and avoids
> registering a potentially duplicative link relation value.
>
> There is language in the draft requiring the client to check "host" values
> between TLS certificates and link relation values.  This seems unnecessary
> to me, for a couple reasons.
>
> 1. It unnecessarily constrains the logical organization of resources,
> which may be hosted on multiple domains and yet have a canonical URL by
> which other systems, including the authorization server, identify them.
> Allowing the canonical URL to differ from the host of the initial request
> will avoid these limitations.
>
> 2. The resource server must ultimately do audience checking in order to
> validate the access token.  I believe this accounts for all the security
> considerations, and alleviates the burden from the client to do any
> checking itself..
>
> Jared Hanson
> Auth0 Inc.
>
> --
> Jared Hanson 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for 

[OAUTH-WG] updated Distributed OAuth ID

[Dick Hardt]

Hey OAuth WG

I have worked with Nat and Brian to merge our concepts and those are
captured in the updated draft.

https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/

We are hopeful the WG will adopt this draft as a WG document.

Any comments and feedback are welcome!

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