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