Subject: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 5 Nov 2018 13:32:38 +0700

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.

---

From: Mike Jones <[email-masked]>
Date: Mon, 5 Nov 2018 06:39:41 +0000

As discussed during the working group meeting, I agree with the people who spoke up saying that they believe that trying to over-generalize the JWT introspection response mechanism to cover all OAuth interactions would be reaching too far.  There are differences in the characteristics of the different OAuth endpoints (authorization, token, introspection, AS metadata, dynamic registration, etc.) that would have to be accounted for, including the likelihood that different keys and algorithms would be appropriate in the different contexts, different client authentication methods would be needed, etc.

Let's do one thing well.  Not create something that's extra-complicated without any clear use cases for doing so.

				-- Mike

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: Monday, November 5, 2018 1:33 PM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] Generalizing draft-ietf-oauth-jwt-introspection-response-01

Hi all, 

Thanks in advance,
Torsten.

---

From: Justin P Richer <[email-masked]>
Date: Wed, 7 Nov 2018 01:16:03 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Thanks in advance,
Torsten. _______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth