> 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
