Re: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797

Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 08 February 2021 16:03 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 97EC23A10BA for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 08:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3nwHGebFTZor for <oauth@ietfa.amsl.com>; Mon, 8 Feb 2021 08:03:11 -0800 (PST)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 D12DC3A10E8 for <oauth@ietf.org>; Mon, 8 Feb 2021 08:03:11 -0800 (PST)
Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 990HlxIGCw5Jf990HlRyik; Mon, 08 Feb 2021 09:03:10 -0700
X-CMAE-Analysis: v=2.4 cv=X62XlEfe c=1 sm=1 tr=0 ts=602160be a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=O7ycHR8boHRv27uBlEwA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=nak9Ox0lsa0-jk66YjIA:9 a=216G3L1HtJXoGbrs:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <CALkShcs5iY9WRYzC2Zub7LZQ5=YMHPuovYZkWOhXOiJUaTgN0g@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <40a89ab4-04ca-e494-638c-db149e046afd@connect2id.com>
Date: Mon, 08 Feb 2021 18:03:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CALkShcs5iY9WRYzC2Zub7LZQ5=YMHPuovYZkWOhXOiJUaTgN0g@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050304000102030505030502"
X-CMAE-Envelope: MS4xfERgXj7uEwKyHNT/spE+n/A3TkqamwaPblbuUhfOiAiFgSXPsmdUcMFhLTw9ZeMYE2ITLWJkUosgXYQ1JWHHsEXOdNEpwxhWY7o8M0hw8G+yyfU1VYZd 8fCAZC2LFEPguiTHDfvaXhZI54bjkXbHaEgvJxrA+lk2rFwI2MHUDjmZKOaNaWsSiKeGhX3wZ+ugtw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3Cu81pjLEWLLl076d471iUzgpq8>
Subject: Re: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797
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: Mon, 08 Feb 2021 16:03:14 -0000

Hi Andrii,

The unencoded payload JWS from RFC 7797 appears to be harder to get
right. Web frameworks can for instance make serialization and parsing of
JSON and text in general in HTTP unpredictable or difficult to control.
A single \n introduced at the end of the body can for instance break the
signature (been in one such situation). Incorrectly set charsets can
also cause issues. To mitigate this there has been an effort to
canonicalize JSON.

Also note that the JSON payload of the signed introspection response is
not a 1:1 copy of the RFC 7662 token introspection response. It includes
claims outside the token_introspection container - iss, aud and iat. So
where will they go and how is the signature going to include them as well?

There's also the issue with encryption - we don't have a standard way of
doing JWE over an RFC 7797 style signed text yet.

Vladimir

On 07/02/2021 11:56, Andrii Deinega wrote:
> Hi WG.
>
> draft-ietf-oauth-jwt-introspection-response-10 proposes to return
> signed JWTs as a response from the introspection endpoint... which is
> making me wonder if there are any particular reasons to not avail JSON
> Web Signature (JWS) Unencoded Payload Option (RFC 7797) and the
> X-JWS-SIGNATURE HTTP header in order to achieve the same goals?
>
> Pros would be
>
>  1. a token introspection response remains to be exactly the same as
>     it was before with an exception for a JWT in the X-JWS-SIGNATURE
>     HTTP header (where a detached payload is the actual token
>     introspection response)
>  2. the AS can safely enable it for all responses from the
>     introspection endpoint so clients who don't require or just aren't
>     aware of this header will continue to work as before and
>     accordingly, the clients who require some stronger assurance will
>     require and check a JWT in X-JWS-SIGNATURE HTTP header
>  3. the same approach could also work for other endpoints such as the
>     revocation and OIDC UserInfo endpoints
>
> What do you think?
>
> Regards,
> Andrii
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov