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

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 <torsten@lodderstedt.net<mailto:torsten@lodderstedt.net>> wrote:

Hi Justin, hi all,

On 4. Sep 2019, at 19:28, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:

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.

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<http://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 <drafts-expert-review@iana.org<mailto:drafts-expert-review@iana.org>> wrote:

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

_______________________________________________
oauth-ext-review mailing list
oauth-ext-review@ietf.org
https://www.ietf.org/mailman/listinfo/oauth-ext-review