Since I brought this up initially, I want to re-voice my support for a general mechanism. I think it makes sense to have something that all of the OAuth JSON-spouting endpoints (introspection, token, revocation, registration, discovery) can use to universally put out signed and/or encrypted JWTs instead using the same mechanism.
Keying for each of these should be fairly clear and based on the nature of the requester. Discovery would be signed by the server key, token could be encrpyted to the client’s key or secret, introspection tied to the resource’s key, etc. I don’t see a lot of possibility for confusion but instead see a chance to make good re-use of a general mechanism all over the place. The authorization endpoint doesn’t come into play at all because it doesn’t return JSON, and instead is a front-channel redirect endpoint. As such it’s a drastically different space and therefore this spec wouldn’t apply. In fact, that’s where JARM would come into play. — Justin On Nov 5, 2018, at 1:32 AM, Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote: Hi all, as mentioned during the presentation this morning, I would like to get a feeling what the working groups thinks about generalizing draft-ietf-oauth-jwt-introspection-response-01 to a mechanism supporting requesting and providing JWT responses from the different OAuth endpoints, such as token, revocation, client registration, and introspection. Please share your thoughts on the list. Thanks in advance, Torsten. _______________________________________________ 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
