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 <dick.ha...@gmail.com>: > > 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 <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. >>> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
