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
