> 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 <dick.ha...@gmail.com>:
>>> 
>>> 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 <dick.ha...@gmail.com>:
>>>> > 
>>>> > 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.
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to