Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection
Takahiko Kawasaki <taka@authlete.com> Sat, 07 March 2020 01:33 UTC
Return-Path: <taka@authlete.com>
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 DCC353A0F80 for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2020 17:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.com
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 FXajjCj-ve3r for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2020 17:33:16 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 EDA573A0F7E for <oauth@ietf.org>; Fri, 6 Mar 2020 17:33:15 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id 6so4441598wre.4 for <oauth@ietf.org>; Fri, 06 Mar 2020 17:33:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YZst0zMVbiLOpFyTKP4NSb7HzTK7LmO2MybjhuEta28=; b=keXYTte144VRGwzvINkXzlCUZ/U+u/AHBx82LGbWMqXysJy8KUhv70D2xgIX26yQGk wNrd6Z2vaH7Cwy8wcGDcC5YsPI2wfyOe7FcLTKPCoWMF++jJuHxIFralOFDkjO82vIsz tqoms97TYYeHFLNVSvqPsjrR4CLrFPP+TYuVcSsdFwltHgsX1lEKHY7TF+ZpVUNTPJ7u q2iWM2kok2vNfprkv+guguZ32vWak+dSsG4IV6SBKCuI6t073BVsvNV5nIVzPEvSQoLI KDzrfuxZO3ZWNfT46D1Sxex/n6PllE9qYt3cQZYHDdvJgVCHgiC1oNuqJoRlWaXvKJh9 VISg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YZst0zMVbiLOpFyTKP4NSb7HzTK7LmO2MybjhuEta28=; b=XWlImPlM1W28FclM/3beu4nK+mCXO7u7VckWjf+cGVeJ1PA3cYPEMeCDVFV1H3ziy9 tRnEc2MA4rrQ3KzbDrxrLCFWbkNdB4M05P8wweeoyqKwWudCfG6pJonaW9T3i89ayC41 OCUJgOM7g9f39iK+w9I10vOYZBZNX0l7Q8ovszbXTEAhrBtQjhpd9efG3s/95gZSN+kp 1xcsmE24EUJmwiC79CVTBiLHQXWwMo23NUdRHPeaLZuuphb/VoSJr53s+4S8xdm+uX9c tD/CzD2mvgrLmksmb1lwid/XN3sHmWEMO9gKZgc0+Mikuj1G0RL9meRkkvHOeMy7Wfo6 K/Mg==
X-Gm-Message-State: ANhLgQ0Lm39rDGf8DDsbG2HhYeIDZuYjeNQ8FRcYDb5L8Ie8cLE+0zVo AdFdKBMtPPEkUQ5fHZWMR23gNLmTO/3qNr58MvxotJfETtI=
X-Google-Smtp-Source: ADFU+vu364TEJj5IaO01PSg/bkkTnVxQ5626j/2Rdn54hOX8wwur5xy0F8dT9ZqA/l+ILd8w/k2rOOKSZWnKmLbnrhs=
X-Received: by 2002:a5d:67c7:: with SMTP id n7mr6533101wrw.319.1583544794039; Fri, 06 Mar 2020 17:33:14 -0800 (PST)
MIME-Version: 1.0
References: <CALAqi__3RXxMyKp7dPjQK-eD+E4duY1y2SVWqC-Xnr3twh8HeA@mail.gmail.com> <741BA825-7143-4886-AE46-B66A9E686A8C@lodderstedt.net>
In-Reply-To: <741BA825-7143-4886-AE46-B66A9E686A8C@lodderstedt.net>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Sat, 07 Mar 2020 10:33:02 +0900
Message-ID: <CAHdPCmNqkt48O+2gcJKu5UhYYyCmiBX6nEmBCxvvzP5+ey4SFA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Filip Skokan <panva.ip@gmail.com>, oauth <oauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, Vladimir Dzhuvinov <vladimir@connect2id.com>
Content-Type: multipart/alternative; boundary="000000000000ef6c1e05a039c07b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mUaHJXN38vCUmeNy-irutP8MkWg>
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: Sat, 07 Mar 2020 01:33:19 -0000
Regarding the name of the JSON property in the payload of the introspection response JWT. If we choose a more generic name (e.g. "content") than "token_data", the approach discussed here can be used as a generic way to wrap a JSON response in JWT. If we are ambitious, we can even add "content_type". Example 1: { "iss": "...", "content_type": "application/json", "content": { "key0": "value0", "key1": "value1" } } Example 2: { "iss": "...", "content_type": "application/x-www-form-urlencoded", "content": "key0=value0&key1=value1" } Taka On Thu, Mar 5, 2020 at 3:28 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > > > Am 04.03.2020 um 19:18 schrieb Filip Skokan <panva.ip@gmail.com>: > > > Sorry, i meant - is top level jti required as well? > > > I don’t see any use case for it, but that might be due to lack of > creativity :-) > > > S pozdravem, > *Filip Skokan* > > > On Wed, 4 Mar 2020 at 19:15, Filip Skokan <panva.ip@gmail.com> wrote: > >> Torsten, let's make sure we call out the required top level JWT claims - >> iss, iat, aud, what else? is top level iat required as well? >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Wed, 4 Mar 2020 at 17:19, 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 >>> >>>
- [OAUTH-WG] Conflicting definitions in JWT Respons… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Justin Richer
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Filip Skokan
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Torsten Lodderstedt
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Takahiko Kawasaki
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Conflicting definitions in JWT Res… Benjamin Kaduk