I’m definitely in favor of separating the “person using the client software” from the “person making the authorization decision” and allowing them to be the same person without changing the protocol. UMA has that separation, but doesn’t handle the collapsed case very well in my opinion (in spite of best efforts to allow it). OAuth assumes they’re always the same but can be tweaked to make them different sometimes (like CIBA’s call center use case), but it’s not really set up for that.
I think we have an opportunity to get this right in XYZ because we have a more flexible way of defining “how I can interact with a user” as part of the protocol, as well as “anything I know about the user already” for the client to push in. This could be used as a signal to the AS that the end user and resource owner are different parties and it should go bug someone through an asynchronous channel for approval. As for the rest of Nat’s list below, that’s a hefty feature set. If we pick up this work, I think a few of these might fit better into a companion spec, but they are all definitely worth discussing. I would personally rather bring all the pieces together and figure out how to slice them apart than have something incomplete that needs to be bolted on to for anyone to use it. — Justin On Jul 22, 2019, at 12:21 PM, Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>> wrote: +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<mailto: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<mailto: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<mailto: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
