+1 Also, if it were to include user identification in the protocol, I would like to have the spec at least cover the following:
0. User 1. External Identity Provider 2. Resources that covers the functionality of PEP. 3. Authorization Server that act as PDP for Resources. 4. Internal Identity Server within the resource domain. 5. Client APP component 6. Client Server component In addition, it would be good to delineate the resource owner (an entity that has administrative rights over the set of resources) and the end user who is in the protocol flow. That actually asks for the following additional entities: 7. Resource Administrator 8. PAP/PIP It is probably a good idea to state the security target as well. Re: Starting from Resource. Yes. I agree that this is a valid use case. At the same time, there can be cases where the concrete resource endpoint is not known before the user authorization. So, the protocol needs to be able to start both ways, I guess. Cheers, Nat Sakimura On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt <dick.ha...@gmail.com> wrote: > > Hey Justin > > A few use cases that highlight how the world is different now than it was > when OAuth 2.0 was developed would help participants understand why changes > are needed, and also provide a reference for comparing and contrasting > different approaches. > > One of my first comments is why the client is starting off making calls to > the AS. There are times when the AS is not known for a given resource. Why > not allow starting at resource? > > > On Tue, Jul 9, 2019 at 12:48 PM Justin Richer <jric...@mit.edu> wrote: >> >> I have requested time to present Transactional Authorization (the XYZ >> project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve >> uploaded a new version of the spec: >> >> https://tools.ietf.org/html/draft-richer-transactional-authz-02 >> >> Additionally, I’ve updated the writeup and examples on https://oauth.xyz/ >> >> I plan to be in Montreal for the whole week, and I’ve requested from the >> chairs that I present during the Tuesday session due to limited availability >> of some key WG members on Friday. >> >> — Justin >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
