Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 04 March 2020 16:49 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F273A1277 for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 08:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 dQ4DR8jplBCD for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 08:49:53 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6DCC3A1280 for <oauth@ietf.org>; Wed, 4 Mar 2020 08:49:52 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id g134so2887542wme.3 for <oauth@ietf.org>; Wed, 04 Mar 2020 08:49:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1znzZqii9DOZZroNiZmnLNoVtKu74+VIfJlFM3odbZk=; b=bHnDf+FLG0J1CRLxkvgpP/R9X0xOP4WTbixoesT8VdBoXJvShjUakmVNErZQ4Pl1nc xMuXGQPlm4XLd05hutuXa5pjpGoUVw/xBGZ4yJ4jDGdY7KLyqSrMC4K6wREaWf0ujTDe Rd7B8OupwUJr0zkEVktGttc4otmzknPImVbeRorfq+pnuae/k9VeXNrI8a+1fM/rlQun IiNKzNN/3EjNqG8KVyrwaLiLAt3pUc0V6PfXPBxgExLRoN8G8YrmdJFR6cB3X5wJtPRP 1bFqusysXut1lgbgvIZl7y+BJDlMMAFhZV8Kmsji1r5CSel5143NuKaPI71OUSo/LIk+ +PHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1znzZqii9DOZZroNiZmnLNoVtKu74+VIfJlFM3odbZk=; b=CRaAaZsrpk2kc0b/s6a6Kk4b0OQFQjG6Ni7QygTWLqmbbQTs1NDEF750RCVnDkiL3F rFENtqd24GD8i3y+JbrRRGECxVgvBXSf9Z0bkoyPOiGJ6fmQqgZhEdNnLFgXBztwrREK m6pTefd1vKzFSOgiOEM1l3sO/CKBtFJj2pGToFdnR3g68gENjD0Z+UUmCPl3lqVzIRxq XWXTQPjEWSWlMOx9zpn0wNyoh1gahx1d/MWf7jqFVqzYtc1HY3wIeC8WHPx1g4+qlEjf 42i9oRbJRsKaKYP/5UNg6ppSNRF30cy4+W5u67+TcQ/PBauPr6OXBN8DINFS8YjQfMeJ ZXdA==
X-Gm-Message-State: ANhLgQ1jY81juFHFvyATCc29M3yolxUGvcL0ctTdO3EJbSMvmltjkVZq ONvekUf1Kj2dACTisfn3/zu55Q==
X-Google-Smtp-Source: ADFU+vubsLxhdscn2ADq/7SKXWzDOhh3gW5YNzmxgivTsK2ZxlPCEXkfqMZ6UdTUhfKyZ8hfLAuoyg==
X-Received: by 2002:a1c:417:: with SMTP id 23mr4576306wme.92.1583340588757; Wed, 04 Mar 2020 08:49:48 -0800 (PST)
Received: from ?IPv6:2a01:598:8883:9b10:81c6:3548:b9ae:86bb? ([2a01:598:8883:9b10:81c6:3548:b9ae:86bb]) by smtp.gmail.com with ESMTPSA id p1sm6532569wrf.82.2020.03.04.08.49.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2020 08:49:48 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-994FE243-5406-4708-862B-680930962526"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 04 Mar 2020 17:49:46 +0100
Message-Id: <F3C2DFA0-778B-400E-ADB6-20E8FDC05EC1@lodderstedt.net>
References: <5EF38619-815D-4370-A1CE-1992588FBDD8@mit.edu>
Cc: oauth <oauth@ietf.org>, Filip Skokan <panva.ip@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, Takahiko Kawasaki <taka@authlete.com>, Vladimir Dzhuvinov <vladimir@connect2id.com>
In-Reply-To: <5EF38619-815D-4370-A1CE-1992588FBDD8@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lWIb9ELk4mq9vDarlW2N9d8qz88>
Subject: Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
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: Wed, 04 Mar 2020 16:50:00 -0000

no particular reason, just indicating special meaning. I can live without it.

> Am 04.03.2020 um 17:29 schrieb Justin Richer <jricher@mit.edu>:
> 
> Why the leading underscore in the name? Why not just “token_data”?
> 
> — Justin
> 
>> On Mar 4, 2020, at 11:19 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> Hi all, 
>> 
>> based on the recent feedback, Vladimir and I propose the following changes to draft-ietf-oauth-jwt-introspection-response: 
>> 
>> - the token data are encapsulated in a container element “_token_data”
>> - beyond this, the top-level container only contains meta data pertinent to the JWT representing the signed (encrypted) introspection response
>> - we need to add text to the spec to point out that replay detection must be based on the jti in the “_token_data” container not the top level claim
>> 
>> That’s example of how it would look like:
>> 
>> {
>>  "iss":"https://as.example-bank.com",
>>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>  "iat":1532452100,
>>  "_token_data":{
>>     "active":true,
>>     "iss":"https://as.example-bank.com",
>>     "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>     "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>     "iat":1532452084,
>>     "exp":1532453100,
>>     "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>     "cnf":{
>>        "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>     },
>>     "sub":"123456789087632345678"
>>  }
>> }
>> 
>> The response for inactive tokens would look like this:
>> 
>> {
>>  "iss":"https://as.example-bank.com",
>>  "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>  "iat":1532452100,
>>  "_token_data":{
>>     "active":false
>>  }
>> }
>> 
>> What do you think?
>> 
>> best regards,
>> Torsten. 
>> 
>>>> On 4. Mar 2020, at 16:37, Justin Richer <jricher@mit.edu> wrote:
>>> 
>>> +1, this encapsulation is much cleaner.
>>> 
>>>> On Mar 2, 2020, at 2:25 AM, Filip Skokan <panva.ip@gmail.com> wrote:
>>>> 
>>>> Perhaps we should consider leaving the root level JWT claims as-is per JWT and push the introspection response unmodified as if it was regular json response to a JWT claim called "introspection". Since regular introspection uses the same claim names as JWT this would get around all the conflicts.
>>>> 
>>>> Last time i brought it up the authors didn't want to consider it because of existing implementations.
>>>> 
>>>> S pozdravem,
>>>> Filip Skokan
>>>> 
>>>> 
>>>> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki <taka@authlete.com> wrote:
>>>> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the same concerns in this mailing list about 6 months ago (on Sep. 4, 2019). RFC 8707 didn't exist then, though.
>>>> 
>>>> Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05
>>>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>>>> 
>>>> A JWT puts both (a) information about itself and (b) other data in its payload part. When the "other data" have the same claim names as are used to express information about the JWT itself, conflicts happen.
>>>> 
>>>> Also, it should be noted that Ben pointed out in other thread that the requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which says "jti" is a unique identifier for the access token that MUST be stable for all introspection calls, contradicts the definition of "jti", which should be unique for each JWT.
>>>> 
>>>> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)
>>>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>>>> 
>>>> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve the conflicts.
>>>> 
>>>> Taka
>>>> 
>>>> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki <taka@authlete..com> wrote:
>>>> Hello,
>>>> 
>>>> I'm wondering if the following conflicts in "JWT Response for OAuth Token Introspection" (draft 8) have already been pointed out.
>>>> 
>>>> RFC 8707 (Resource Indicators for OAuth 2.0) requires that 'aud' in an introspection response hold the values of the 'resource' request parameters, whereas "JWT Response for OAuth Token Introspection" says that 'aud' MUST identify the resource server receiving the token introspection response. The definitions conflict.
>>>> 
>>>> RFC 7662 (OAuth 2.0 Token Introspection) requires that 'iat' in an introspection response indicate when the access/refresh token was issued, whereas "JWT Response for OAuth Token Introspection" says that 'iat' indicates when the introspection response in JWT format was issued. The definitions conflict.
>>>> 
>>>> Best Regards,
>>>> Takahiko Kawasaki
>>>> Authlete, Inc.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>