[OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

"Schaar, R.M. (Remco) - Logius" <remco.schaar@logius.nl> Tue, 06 August 2019 14:02 UTC

Return-Path: <prvs=114f83850=remco.schaar@logius.nl>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B45B1120172 for <oauth@ietfa.amsl.com>; Tue, 6 Aug 2019 07:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=logius.nl
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bLM5zLizQyfh for <oauth@ietfa.amsl.com>; Tue, 6 Aug 2019 07:02:03 -0700 (PDT)
Received: from mail2.ssonet.nl (mail2.ssonet.nl []) (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 ECA80120072 for <oauth@ietf.org>; Tue, 6 Aug 2019 07:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=logius.nl; i=@logius.nl; q=dns/txt; s=Selector2; t=1565100123; x=1596636123; h=from:to:subject:date:message-id:mime-version; bh=ZbmNhmK0t0jZBdZrs++oIf1dunmKQoz5nKrL5/K3jNc=; b=qY2i96P9o+0UskAuJzBwCBcfbf3mhSlcca47yLcZqvP5ps53N0xIeFy7 PRlkpVUc+rMDRVBgpkG7Q2RoOYVFT6VWJbjFhn928GIcXiufLhgB9NY0v Qp48ltCiR7eZCs3hIFXymxWlCmc0mDw/ROkBFVKsIkOrHiMLSxqRCFEqr 9mD1lHc4HoumjVWDbZ4mfje6Yzr8WOn/+lWj5n52FzvkHkhN8tfjdBweI VfhaaSI+2Xp/e4Ouj/nzJSJBtj8unCY2KrJ9XJQgJLAXsivcKLtL2og15 mSYJv8TE740IwC77bI6wOzqmh0gYz7cTWTmX37GQ1MQEgAJAXdPkxYoJw Q==;
IronPort-SDR: cOOCL/pQosT/ime++c8Bf/2s17lM6JLvvu5a+5w1RQEkSgyZwjR1EjZw7UJZ/SjyR7xSNDTo45 qXhWKx7FKFWA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="6000,8403,9340"; a="12024036"
X-IronPort-AV: E=Sophos; i="5.64,353,1559512800"; d="scan'208,217"; a="12024036"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
From: "Schaar, R.M. (Remco) - Logius" <remco.schaar@logius.nl>
To: "'oauth@ietf.org'" <oauth@ietf.org>
Thread-Topic: Question regarding draft-ietf-oauth-jwt-introspection-response-05
Thread-Index: AdVMX0zd8VJvxu//SVaPc8ibBp8OiQ==
Date: Tue, 06 Aug 2019 14:01:59 +0000
Message-ID: <38503cd44d9e455bad4432d9ba5e82e8@SV1601507.frd.shsdir.nl>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_38503cd44d9e455bad4432d9ba5e82e8SV1601507frdshsdirnl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ORy0z9pMWs53uctGLodsUTlSW08>
X-Mailman-Approved-At: Wed, 07 Aug 2019 13:09:48 -0700
Subject: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 14:03:22 -0000


I would like to request the OAuth2 working group on a clarification for introspection, in particular regarding the semantics of the 'jti' and 'aud' claims. The draft 'JWT Response for OAuth Token Introspection' seems ambiguous in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 cause this ambiguity.

RFC7662 specifies the 'aud' and 'jti' parameters in relation to "for the token". Note that the wording in RFC7662 is somewhat implicit, we assume "the token" is the (access) token being introspected.
RFC7519 specifies the 'aud' and 'jti' parameters in relation to the JWT itself. The token in the context of RFC7519 is the JWT containing the parameters.

The draft (draft-ietf-oauth-jwt-introspection-response-05) now formulates the response to an introspection as a JWT. The content of the JWT "MAY furthermore contain all claims defined in RFC7662". Now this raises the question to the meaning of the 'aud' and 'jti' parameters.

In line with RFC7519 the parameters would define a value for the introspection response. On the other hand following RFC7662 for the definition would define the value of the parameters as those of the introspected token.

Now for the 'aud' parameter this will typically only be an issue with multiple values for the audience. In the case of a single intended audience the audience of the introspected (access) token will normally be the same principal as the audience of the introspection response JWT. Only for some use cases the value of 'aud' may end up ambiguous.
The 'jti' parameter however will always be ambiguous. As it is an identifier, it should differ for the introspected token and the introspection response by definition. Hence the semantics of 'jti' in a JWT introspection response is unclear. The same can apply to the 'iat', 'nbf' and 'exp' claims in a JWT introspection response.

Can someone clarify the semantics of claims in an introspection response JWT that are defined in both RFC7662 and RFC7519?

Furthermore, the introspection response should use the 'iss' and 'aud' claims to avoid cross-JWT confusion (section 6.1). The 'iss' and 'aud' of an introspected token will typically be the same as those of the introspection response. Hence a JWT access token cannot be distinguished from an introspection response using 'iss' and 'aud' as suggested in the draft.

Introspection refers to JWT best-current-practice. The draft BCP recommends using explicit typing of JWTs, however the draft JWT response for introspection does not apply this recommendation and uses the generic 'application/jwt' instead... The BCP has other recommendations in section 3.12, but these may be insufficient to distinguish a JWT access token from a JWT introspection response.

How would people suggest to best distinguish a JWT (access) token from a JWT introspection response?

Thank you in advance for your response.

Kind regards,
Remco Schaar
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.