I agree that we need to expound on the new use cases that this approach enables, and I’ll send them out here and add them to the site as I get them written down.
To your specific idea: My thinking here was that we can leverage the transaction model to make this work in a consistent fashion. This is noted in the spec and website, but to expand here: 1) Client goes to the RS and tries a request, with no token or with insufficient token. 2) RS goes to the AS and says “hey someone wants a thing but can’t get it, here’s a resource object that describes what would be sufficient access to make that work” .. this request has some signal in it that tells the AS that it’s not a client asking for a token, maybe set the “client” field to “false” or something? I’m not sure how best to signal that yet. 3) AS returns a resource_handle for the requested resource set. This can be random and dynamically generated, doesn’t have to be human readable. 4) RS returns the resource handle and a pointer to the AS’s transaction endpoint to the client in a WWW-Authenticate response header that we’d define, but would look suspiciously like UMA2’s response header with similar information. 5) Client makes its normal XYZ request to the AS but includes the resource_handle it got back from (4). — Justin On Jul 21, 2019, at 5:27 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
