> 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 protected]> wrote: >> >>> Am 23.07.2018 um 13:58 schrieb Dick Hardt <[email protected]>: >>> >>> In your examples, are these the same AS? >> >> yes >> >>> >>> >>> >>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt >>>> <[email protected]> wrote: >>>> Hi Dick, >>>> >>>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt <[email protected]>: >>>> > >>>> > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
