Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Jul 2018 17:59:52 +0200

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 <[email-masked]>:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Jul 2018 12:16:47 -0400

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

On Tue, Jul 17, 2018 at 11:59 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> 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

---

From: David Waite <[email-masked]>
Date: Thu, 19 Jul 2018 01:54:54 -0600

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 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, and the authorization servers would isolate tokens to only being consumed within an origin. This would actually make redundant/supplemental the AS additions defined within this spec (resource/origin request parameter, ‘aud’ introspection response member)

-DW

> On Jun 12, 2018, at 1:28 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hey OAuth WG
> 
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ <https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Jul 2018 14:51:41 +0200

Hi Dick,

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

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2018 09:42:13 -0400

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

On Thu, Jul 19, 2018 at 3:54 AM, David Waite <[email-masked]>
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.:
>
>     oauth_server_metadata_uris="https://as.example.com/.well-
> known/oauth-authorization-server https://different-as.example.
> com/.well-known/oauth-authorization-server"
>
>
> 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.

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

I'm not understanding why you think this. Would you elaborate?

>
> Fourth and finally: Is the intention to eventually recommend token binding
> here? Token binding as a requirement across clients, resources, and the
> authorization servers would isolate tokens to only being consumed within an
> origin. This would actually make redundant/supplemental the AS additions
> defined within this spec (resource/origin request parameter, ‘aud’
> introspection response member)
>

Token binding solves part of the resource constrained access token
requirement, but does not solve how the client authenticates to the AS.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2018 09:46:57 -0400

On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> 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

---

From: n-sakimura <[email-masked]>
Date: Fri, 20 Jul 2018 08:33:19 +0000

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:[email-masked]] On Behalf Of David Waite
Sent: Thursday, July 19, 2018 4:55 PM
To: Dick Hardt <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

Four comments.

should be

It seems that:

-DW

On Jun 12, 2018, at 1:28 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hey OAuth WG

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

---

From: David Waite <[email-masked]>
Date: Fri, 20 Jul 2018 12:29:09 -0600

> On Jul 20, 2018, at 2:33 AM, n-sakimura <[email-masked]> wrote:
> 

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

>     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>"
>  
> 
> <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"
>  
> On Jun 12, 2018, at 1:28 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hey OAuth WG
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: David Waite <[email-masked]>
Date: Fri, 20 Jul 2018 12:39:44 -0600

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

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Jul 2018 18:49:05 +0200

Hi Dick,

Am 19.07.2018 um 15:46 schrieb Dick Hardt <[email-masked]>:

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 22 Jul 2018 18:52:50 -0400

On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <
[email-masked]> wrote:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 23 Jul 2018 09:42:20 +0200

Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <[email-masked]>:
> 
> 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.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Jul 2018 07:58:09 -0400

In your examples, are these the same AS?

On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <[email-masked]>
wrote:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 23 Jul 2018 18:50:23 +0200

> Am 23.07.2018 um 13:58 schrieb Dick Hardt <[email-masked]>:
> 

yes

> 
> 
> 
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi Dick,
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Jul 2018 19:25:09 -0400

And who is the AS?

On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <
[email-masked]> wrote:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 24 Jul 2018 17:59:29 +0200

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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 24 Jul 2018 13:21:17 -0700

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 24 Jul 2018 22:47:07 +0200

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 <[email-masked]>:
> 
> 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? 
> 
>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <[email-masked]> wrote:
>> 
>>> And who is the AS?
>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 24 Jul 2018 13:51:46 -0700

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 25 Jul 2018 07:20:55 +0200

> Am 24.07.2018 um 22:51 schrieb Dick Hardt <[email-masked]>:
> 

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 25 Jul 2018 09:22:16 +0200

> 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 on…

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.