Subject: [oauth-ext-review] [IANA #1151219] expert reviews for draft-ietf-oauth-jwt-introspection-response (oauth-parameters)

From: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 04 Sep 2019 01:00:22 +0000

Attn: Justin Richer, Mike Jones, Nat Sakimura, John Bradley

Have you been able to review the registration requests Torsten Lodderstedt submitted to the mailing list for draft-ietf-oauth-jwt-introspection-response on 2019-08-14? This document is on Thursday's IESG telechat agenda.

We need Justin to approve the registrations in Sections 8.1 and 8.3, and we need Mike Jones, Nat Sakimura, and/or John Bradley to approve the registrations in Section 8.2. The first person to respond from that group should also let us know whether one approval is enough, or whether we should also wait for a second and/or third reviewer to approve.

https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response

https://www.iana.org/assignments/oauth-parameters

Best regards,

Amanda Baber
Lead IANA Services Specialist

---

From: Mike Jones <[email-masked]>
Date: Wed, 4 Sep 2019 09:01:54 +0000

I approve of the registrations in 8.2.  These are straightforward enough that I don't believe that approvals from Nat or John are also needed.

Thanks,

-- Mike

________________________________
From: Amanda Baber via RT <[email-masked]>
Sent: Tuesday, September 3, 2019 6:00:22 PM
Cc: [email-masked] <[email-masked]>
Subject: [IANA #1151219] expert reviews for draft-ietf-oauth-jwt-introspection-response (oauth-parameters)

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwt-introspection-response&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ca6f289f511fb427632fc08d730d343ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637031556254269993&amp;sdata=NaYLhsSkl5Trv7Ow6XAhWGtIaEec9jMY%2BJLFnYdoE94%3D&amp;reserved=0

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Foauth-parameters&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ca6f289f511fb427632fc08d730d343ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637031556254269993&amp;sdata=U0%2F62ADYVfgursWOt%2Fne1xvoLGNQ6m6HWrsgXzXHI2k%3D&amp;reserved=0

Best regards,

Amanda Baber

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Sep 2019 17:28:16 +0000

I approve the registrations in section 8.1, they make sense in the context of the document.

However, I am inclined to reject the registrations in 8.3, so I hope someone can help me understand what’s going on here. I am not seeing in the document where the requests for the registrations in section 8.3 are used or required. I realize that they are all registered JWT claims — but this is because they are used within OpenID Connect for the ID Token. Since introspection is intended to be used for Access Tokens primarily, I don’t see the purpose of putting these here. This is especially true because this document does not define introspection response values themselves, but instead provides a packaging mechanism for them. Therefore it’s my belief that the document could drop section 8.3 entirely with no changes to functionality. I’ve copied Torsten to clear up if I’m missing anything.

— Justin

On Sep 3, 2019, at 9:00 PM, Amanda Baber via RT <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,

Amanda Baber

_______________________________________________
oauth-ext-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth-ext-review

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Sep 2019 20:30:02 +0200

Hi Justin, hi all,

> On 4. Sep 2019, at 19:28, Justin Richer <[email-masked]> wrote:
> 

access tokens can be used (and are used in practice) to convey claims about the resource owner to resource servers. See https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-02#section-2.2.1 for a reference. 

In the same way, token introspection responses may provide this kind of data to resource servers. Especially in the use cases driving this draft, resource servers need claims about the end user to, for example, create qualified electronic certificates. I admit the text of the draft is not very specific about this since I considered this common practice. I could add such text to the next revision.

I think it is reasonable to register the OpenID Connect User Claims as Token Introspection Response values.

I don’t know why it did not happen in previous drafts, but I came across this topic in the course of my work at yes.com, which led to this draft and therefore added the missing registrations to it. 

I hope that clarifies the rationale. 

best regards,
Torsten. 

> 
> — Justin
> 
>> On Sep 3, 2019, at 9:00 PM, Amanda Baber via RT <[email-masked]> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 5 Sep 2019 18:53:18 +0000

Torsten, thanks for the clarification of where this came from. However, this draft as it stands does not define the use or meaning of any of these fields in a plain introspection response, which is what that registry is for. I don’t think it’s appropriate for this draft to extend the plain introspection response without significant discussion of why it would do so.

It might make more sense for this registry request to be moved to the access-token-jwt draft instead, which can discuss the use of these fields and tie them to introspection responses. This draft would then inherit all of those fields without issue. What do you think of that direction?

— Justin

On Sep 5, 2019, at 2:30 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin, hi all,

On 4. Sep 2019, at 19:28, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

I don’t know why it did not happen in previous drafts, but I came across this topic in the course of my work at yes.com<http://yes.com>, which led to this draft and therefore added the missing registrations to it.

best regards,
Torsten.

— Justin

Best regards,

Amanda Baber

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 5 Sep 2019 22:38:07 +0200

Hi Justin,

the meaning of these fields in the context of an Introspection response is the same as in ID tokens. I suggest to add an explanation along those lines to the draft.

I don’t understand how moving the registration to access-token-jwt works better as this draft is not related to token introspection. Moreover, there is no relationship between access-token-jwt and this draft.

best regards,
Torsten.

> Am 05.09.2019 um 20:53 schrieb Justin Richer <[email-masked]>:
> 
>> On Sep 5, 2019, at 2:30 PM, Torsten Lodderstedt <[email-masked]> wrote:
>> 
>> Hi Justin, hi all,
>>