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

Vladimir Dzhuvinov <vladimir@connect2id.com> Sat, 07 March 2020 13:39 UTC

Return-Path: <vladimir@connect2id.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 4630F3A1362 for <oauth@ietfa.amsl.com>; Sat, 7 Mar 2020 05:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.006
X-Spam-Level:
X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 sFA3XRVwuREC for <oauth@ietfa.amsl.com>; Sat, 7 Mar 2020 05:39:19 -0800 (PST)
Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 2A6663A1360 for <oauth@ietf.org>; Sat, 7 Mar 2020 05:39:19 -0800 (PST)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id AZfgjmJWrsAUUAZfgjTHca; Sat, 07 Mar 2020 06:39:18 -0700
x-spam-cmae: v=2.3 cv=H5GlPNQi c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=I0CVDw5ZAAAA:8 a=pGLkceISAAAA:8 a=398g4vTdAAAA:8 a=ddEIn7SpAAAA:8 a=48vgC7mUAAAA:8 a=PQ40HBN0VJFOrcyirakA:9 a=QKznYiEb3Zlnc8fA:21 a=eUujN8Vc8WLQNcLX:21 a=QEXdDO2ut3YA:10 a=TAuBDUiYFBnBY41GAJUA:9 a=m8h4ox5-hdn0ZhPE:21 a=mi4M5f7z0FTFb9_p:21 a=zz7Q1gUknc60TUhj:21 a=_W_S_7VecoQA:10 a=baMBZpDhkP33AwImeJwA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=YdXdGVBxRxTCRzIkH2Jn:22 a=IdGyktwZ2tr74praB_5u:22 a=oxJcF3atIAxlNsKubCHO:22 a=0LcYgHMQs7_kImmFrmno:22 a=w1C3t2QeGrPiZgrLijVG:22
x-spam-account: vladimir@connect2id.com
x-spam-domain: connect2id.com
X-CMAE-Analysis: v=2.3 cv=H5GlPNQi c=1 sm=1 tr=0 p=_Y5QVBCcAAAA:8 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=I0CVDw5ZAAAA:8 a=pGLkceISAAAA:8 a=398g4vTdAAAA:8 a=ddEIn7SpAAAA:8 a=48vgC7mUAAAA:8 a=PQ40HBN0VJFOrcyirakA:9 a=QKznYiEb3Zlnc8fA:21 a=eUujN8Vc8WLQNcLX:21 a=QEXdDO2ut3YA:10 a=TAuBDUiYFBnBY41GAJUA:9 a=m8h4ox5-hdn0ZhPE:21 a=mi4M5f7z0FTFb9_p:21 a=zz7Q1gUknc60TUhj:21 a=_W_S_7VecoQA:10 a=baMBZpDhkP33AwImeJwA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=YdXdGVBxRxTCRzIkH2Jn:22 a=IdGyktwZ2tr74praB_5u:22 a=oxJcF3atIAxlNsKubCHO:22 a=0LcYgHMQs7_kImmFrmno:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Takahiko Kawasaki <taka@authlete.com>, 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>
References: <CALAqi__3RXxMyKp7dPjQK-eD+E4duY1y2SVWqC-Xnr3twh8HeA@mail.gmail.com> <741BA825-7143-4886-AE46-B66A9E686A8C@lodderstedt.net> <CAHdPCmNqkt48O+2gcJKu5UhYYyCmiBX6nEmBCxvvzP5+ey4SFA@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <32e56dd3-8015-9566-713f-b411648974cc@connect2id.com>
Date: Sat, 07 Mar 2020 15:39:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAHdPCmNqkt48O+2gcJKu5UhYYyCmiBX6nEmBCxvvzP5+ey4SFA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090907090303040106080703"
X-CMAE-Envelope: MS4wfOSNcHaZVjIwyl5hN9BeURHTaU4VK0Zfds8NMSLgi13INmYEO+fGddTSwrXg8mKoskheT875+veNsY+bwd0HIkAFOeysneYsq0M9itrW88/EmQqa19rh 4nj7Z7qmUuBY1JPNXHrDODOQBJiVRPXIt6x6Lq04NseJL7D+z+esGGuresRJFD/FEJpz95xp/ECYh3Q/UnHGkmANgFicxLJ4ZwOe9Q5/igecEeOci6wDutC2 miBUA6rQ/kKwct1L11NGSX14xCZ7brga+RABXWTfKCl5u8Vr7XqPx1AIklSgILUJ1EPevOlNDtqvE2XaUIsplQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qHvbao_VjwSk8wMo-E7OAVXV42s>
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 13:39:21 -0000
X-List-Received-Date: Sat, 07 Mar 2020 13:39:21 -0000

Hi Taka,

I like the idea. I suppose there are tonnes of use cases where some data
needs to be embedded into a JWT claims set, which could benefit from
having its own container and content type, instead of doing what tried
at first. I suppose this could merit a spec of its own (?). For the JWT
introspection response I find this outside the spec scope. In a
conversion with Torsten we settled on the "token_introspection" name for
the container, to make it consistent with the content type
(application/token-introspection+jwt) and the JWT "typ" header
(token-introspection+jwt).

The JWT claim will also need to be registered with
https://www.iana.org/assignments/jwt/jwt.xhtml , so the name also better
be self-evident and avoid potential conflicts with future specs.

Vladimir

On 07/03/2020 03:33, Takahiko Kawasaki wrote:
> 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 <mailto:torsten@lodderstedt.net>> wrote:
>
>
>
>>     Am 04.03.2020 um 19:18 schrieb Filip Skokan <panva.ip@gmail.com
>>     <mailto: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
>>     <mailto: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 <mailto: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 <mailto:jricher@mit.edu>> wrote:
>>             >
>>             > +1, this encapsulation is much cleaner.
>>             >
>>             >> On Mar 2, 2020, at 2:25 AM, Filip Skokan
>>             <panva.ip@gmail.com <mailto: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 <mailto: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 <mailto:OAuth@ietf.org>
>>             >> https://www.ietf.org/mailman/listinfo/oauth
>>             >> _______________________________________________
>>             >> OAuth mailing list
>>             >> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             >> https://www.ietf.org/mailman/listinfo/oauth
>>             >
>>             > _______________________________________________
>>             > OAuth mailing list
>>             > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             > https://www.ietf.org/mailman/listinfo/oauth
>>
-- 
Vladimir Dzhuvinov