Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09

Torsten Lodderstedt <> Wed, 26 August 2020 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E41E83A124E for <>; Wed, 26 Aug 2020 05:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YcW6hWLF9a6h for <>; Wed, 26 Aug 2020 05:26:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E7E73A124B for <>; Wed, 26 Aug 2020 05:26:29 -0700 (PDT)
Received: by with SMTP id c8so1547562edn.8 for <>; Wed, 26 Aug 2020 05:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tlZrXmf2yyXsRglOEC9N0qFCH7Q6XKUV9KdQNFyFgU=; b=dp3mO9fU6N1fl0WvEklpbamsBu90TxBKABjy9HefRLJWB1Mxtuv7iSO1+DfaqZtKQw J81m5wddOeDbthuc46De9nTveV+0heCTnc0eEees2GbBZqDeMhSEqWPZSxpCopG7Bo3R FfvmBAXlKGtKacuDnAbKolZ823B3SzZJzM74GNqF/R6iAcnLMZnZb0FSxIHaCj0j5NoJ 9ZHXPkiZYJlPWkHRpq6JjQru7RwIPXIJ6AI96913JXryZ64oZtat2c4lKfbq/dLJQhnD h+lV+tAIwrQwAkpUTisFrcYcHFaoVWHH4QzFX70yCx39w4P+bB2ezkcZUPuz1Y7ytmnQ AZ0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tlZrXmf2yyXsRglOEC9N0qFCH7Q6XKUV9KdQNFyFgU=; b=TB3J8wLYBUFL3MLmMDZqZDrRO/aGO1bxykI/vJ6jrJ+KmvLWOCqjR4tCKCoM5q7FxM WDda2ks+0GN9SsQBWA+4U63kH7oZrejeZGvBy8rF93GNXwD85Vo4FJWLw+KMPTb4AUQq lGK6FWVlpSMOGcs8es7puToXJ3juflM1tezr24qBuAG+bxwCwp9DFa1SJpDiRwWVNP16 GYu8gdp5YT7J4jrSG1J0VslwkTq1VxeP80+7SEap8FXL4eRkzFahyS+dUe7gYW9mQ8ju kId/4FlHN9dU9QsojRqqJlBTItxW9hM1xKvrKdMSSniIItEHV5DiGWbf5FPGBSmGrrpc QH2w==
X-Gm-Message-State: AOAM530Y/uZw6khECZF9ZqOSkgGcs2FvyI54r3XX0eHzRt3rlGgs5/rO y9u2j74i4zMzZd4W7MgfYf9oBA==
X-Google-Smtp-Source: ABdhPJwVb11BqO28qb4v89aDo2vaFqZpJ4C3OaVwwL3SYNlBrB07+y3KPFCv0DyzQZ55m7V9OvvEOw==
X-Received: by 2002:aa7:cc14:: with SMTP id q20mr1505809edt.309.1598444787463; Wed, 26 Aug 2020 05:26:27 -0700 (PDT)
Received: from ( [2003:eb:8f1e:2a05:c33:4d31:fc06:9d53]) by with ESMTPSA id p9sm1778230ejg.120.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 05:26:26 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Torsten Lodderstedt <>
In-Reply-To: <>
Date: Wed, 26 Aug 2020 14:26:25 +0200
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Roman Danyliw <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-introspection-response-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2020 12:26:31 -0000

Hi Roman, 

thanks for your review feedback. 

> On 21. Aug 2020, at 16:43, Roman Danyliw <> wrote:
> Hi!
> I conducted an another AD review of draft-ietf-oauth-jwt-introspection-response-09.  As background, -07 of this document went to IESG Review and the document was brought back to the WG to address the DISCUSS points.  
> Below is my feedback which can be addressed concurrently with IETF LC.
> ** Section 5.  I want to clarify what are the permissible members of token_introspection.  The two relevant text snippets seem to be:
> (a) "token_introspection  A JSON object containing the members of the
>           token introspection response, as specified in the "OAuth
>           Token Introspection Response" registry established by
>           [RFC7662] as well as other members."
> (b) "Claims from the "JSON Web Token Claims" registry that are
>           commonly used in [OpenID.Core] and can be applied to the
>           resource owner MAY be included as members in the
>           "token_introspection" claim."
> -- Per (a), Recommend citing the IANA sub-registry directly -- (and not the "as specified in the "OAuth Token Introspection Response" registry established by [RFC7662]")


> -- Per (a), "... as well as other members", what members is this referencing?  Is that (b)?  Recommend being clear upfront on which exact registries are the sources of valid members.

I reworked the whole paragraph (hrefs for registries not shown). 

As specified in section 2.2. of [RFC7662], specific implementations MAY extend the token introspection response with service-specific claims. In the context of this specification, such claims will be added as top-level members of the token_introspection claim. Response names intended to be used across domains MUST be registered in the OAuth Token Introspection Response registry defined by [RFC7662]. In addition, claims from the JSON Web Token Claims registry established by [RFC7519] MAY be included as members in the token_introspection claim. They can serve to convey the privileges delegated to the client, to identify the resource owner or to provide a required contact detail, such as an e-Mail address or phone number. When transmitting such claims the AS acts as an identity provider in regard to the RS. The AS determines based on its RS-specific policy what claims about the resource owner to return in the token introspection response.

Does this work for you?

> -- Per (b), "... commonly used in [OpenId.Core]", what are those specifically?  Is that claims registered in whose reference is [OpenID Connect Core 1.0]?  Recommend being unambiguous in which claims are permitted by pointing the IANA registry.
> -- If I'm understanding right that the source comes either from oauth-parameters.xhtml#token-introspection-response or jwt.xhtml#claims, what happens if it isn't one of those?

Every implementation is also free to use their own specific claims. This is defined in section 2.2. of RFC 

> ** Section 5.  Per " The AS MUST ensure the release of any privacy-sensitive data is legally based", recommend also including a forward reference to Section 9


best regards,

> Regards,
> Roman
> _______________________________________________
> OAuth mailing list