From nobody Wed Mar 17 22:46:34 2021 Return-Path: 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 B01BD3A2024 for ; Wed, 17 Mar 2021 22:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 zk3h-FdWu125 for ; Wed, 17 Mar 2021 22:46:30 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 BC0AA3A2025 for ; Wed, 17 Mar 2021 22:46:29 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id bx7so5073569edb.12 for ; Wed, 17 Mar 2021 22:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rcwyampIQMjjuC55qj+DQJpfbktu5NXR+TilG7oQR7o=; b=Va0AKoyBnI2sNAV/5yOi13KVSIVGy2pEDjjJU4eaw9gOEsMUSaO3q4SZkbJckJPgZ+ gOYnd7OK9yZ2gpzBPK1Dh2N0R3d+F+PyPMgqPd6AZN8UTI5gwglQ56uPrlfZKOzMaBwh FKbf2tELmsFN9LA83gVEVuh9oIBdb3tirm9Bzpzi7JfbdlLa0SZRXeU1OQcobVNsvaHG ZT/Ve6DM7zA9POOL/sqPNefccocHVs5Lg7hv2B5eNLLqOENUHs1o5W1JAgE0f5vjU3Qz zRrthypUlctdpvjKCTZuNxjeehpZ8jbDi7GrxZhLjtyyqTtW3z2hY9Me5ku6kF36V6kB pzWg== 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=rcwyampIQMjjuC55qj+DQJpfbktu5NXR+TilG7oQR7o=; b=gSHCBBj9tmeC/ao55OMHmgsuULhMP8XedYc8ncEAHXuJP0n3t7+RvOTGQnpSUxxYXB VAuMydd64eLTaS6yDDx7fHR5Qct4LtB8GhTsfa+wLtcjCeU6BjEv8zZ6Em5C5arkDW3A 4TJsIN+9TuBsPr8qSVukNT6P77sWJu42Q4JYEj1KOQYN/vrx0Lpni/8lSHxs4eb8Vt2o e7pZC+7r0wW7VHG3C89xsMjYxisoM+OrAEfojo2FAQWWg7iYe/Ol0QqkgFlU13oQBLpP bb1zUsFy1fx9RStvMCoPSeY/mEBt1FhJ6qVrnHdwNSshR568Il9ns8eEwRHEVVcgGQkl ZZqQ== X-Gm-Message-State: AOAM533teo7/+8i/F229VfRoOyBXxbVf1Belp8VHfLb1jEM8xtPN3mfD dFSBaxHDRT4f+aelpnCSkccun/21i4N9DAf9qzRrFcln/aQ= X-Google-Smtp-Source: ABdhPJwJihAZAycwOMRRqjAs0esvOc+EUhKfTzxtUQ77ogP3BVEEGE6NxfMReqnvc85Bc5y6s+T49T8NHRYY0dXcabI= X-Received: by 2002:a05:6402:268c:: with SMTP id w12mr1460827edd.280.1616046384987; Wed, 17 Mar 2021 22:46:24 -0700 (PDT) MIME-Version: 1.0 References: <40a89ab4-04ca-e494-638c-db149e046afd@connect2id.com> In-Reply-To: <40a89ab4-04ca-e494-638c-db149e046afd@connect2id.com> From: Andrii Deinega Date: Wed, 17 Mar 2021 22:46:14 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="000000000000b7c16605bdc91e07" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 05:46:32 -0000 --000000000000b7c16605bdc91e07 Content-Type: text/plain; charset="UTF-8" Hi Vladimir, Thank you for your detailed response. Yes, I completely agree with your point about the issue with encryption. Regards, Andrii On Mon, Feb 8, 2021 at 8:03 AM Vladimir Dzhuvinov wrote: > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b7c16605bdc91e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vladimir,

Thank you for your detaile= d response. Yes, I completely agree with your point about the issue with en= cryption.

Regards,
Andrii

=

On Mon, Feb 8, 2021 at 8:03 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

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 sta= ndard way of doing JWE over an RFC 7797 style signed text yet.

Vladimir

On 07/02/2021 11:56, Andrii Deinega wrote:
=20
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=C2=A0wonder 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=C2=A0and check a JWT in=C2=A0X-JWS-SIGNA= TURE HTTP header
  3. the same approach could also work for other endpoints such as the revocation and OIDC UserInfo endpoints
What=C2=A0do you think?

Regards,
Andrii


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b7c16605bdc91e07--