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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 05 September 2019 20:38 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth-ext-review@ietfa.amsl.com
Delivered-To: oauth-ext-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D4120868 for <oauth-ext-review@ietfa.amsl.com>; Thu, 5 Sep 2019 13:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7faRbIHZwF6o for <oauth-ext-review@ietfa.amsl.com>; Thu, 5 Sep 2019 13:38:13 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DEF120271 for <oauth-ext-review@ietf.org>; Thu, 5 Sep 2019 13:38:13 -0700 (PDT)
Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <torsten@lodderstedt.net>) id 1i5yW8-0003al-Gf; Thu, 05 Sep 2019 22:38:08 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-7AE5A436-86AD-419A-95AE-A10298FC98B9; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <17F6DDC4-2A4D-40C7-A24D-D396446D23B6@mit.edu>
Date: Thu, 5 Sep 2019 22:38:07 +0200
Cc: "drafts-expert-review@iana.org" <drafts-expert-review@iana.org>, "oauth-ext-review@ietf.org" <oauth-ext-review@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <BA3ABFCF-2111-4819-95D5-812E31A404C0@lodderstedt.net>
References: <RT-Ticket-1151219@icann.org> <rt-4.4.3-9075-1567558308-1288.1151219-37-0@icann.org> <rt-4.4.3-9076-1567558822-1862.1151219-37-0@icann.org> <1F7E6313-32D1-40A3-9C46-6F505E91D3B8@mit.edu> <3648DD09-4AB1-491C-9C77-6EE48C97D5BC@lodderstedt.net> <17F6DDC4-2A4D-40C7-A24D-D396446D23B6@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth-ext-review/9cSNf39fJV7XXXuFKYgPvLOw_j8>
Subject: Re: [oauth-ext-review] [IANA #1151219] expert reviews for draft-ietf-oauth-jwt-introspection-response (oauth-parameters)
X-BeenThere: oauth-ext-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Review of proposed IANA registrations for OAuth." <oauth-ext-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth-ext-review>, <mailto:oauth-ext-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth-ext-review/>
List-Post: <mailto:oauth-ext-review@ietf.org>
List-Help: <mailto:oauth-ext-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth-ext-review>, <mailto:oauth-ext-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 20:38:16 -0000

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 <jricher@mit.edu>du>:
> 
> 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> wrote:
>> 
>> Hi Justin, hi all,
>> 
>>> On 4. Sep 2019, at 19:28, Justin Richer <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, 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> 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
>>> 
>> 
>