Re: [jose] JWP

Neil Madden <neil.madden@forgerock.com> Thu, 28 July 2022 06:57 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB594C14CF03 for <jose@ietfa.amsl.com>; Wed, 27 Jul 2022 23:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGtA_gyMlQ0V for <jose@ietfa.amsl.com>; Wed, 27 Jul 2022 23:57:07 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DCDC13CCD2 for <jose@ietf.org>; Wed, 27 Jul 2022 23:57:07 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id d8so961287wrp.6 for <jose@ietf.org>; Wed, 27 Jul 2022 23:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=vJhyVqu1PPIDpWoveQ1jRqlpENfrpU6XbTf6dFRlxn4=; b=kDu65eXbBFdnEh+Q1jMb2Wg4vfa7uMf0AWhiV8JL9WQGT5g8rDD7FF6ZSJekUvVhW5 bYY3YV1fD9ngwwZVkJngV3RwxFtH+aC+7/nad6H6PvYhZ3CXaT+Jxe0DGVncSdfJILTb EYG1zPDwORfr7lCOIIlgcwVUoB6Kemxt3wKX0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vJhyVqu1PPIDpWoveQ1jRqlpENfrpU6XbTf6dFRlxn4=; b=zirjmhXzOa1hJcP0jOjx0ieq8a73x6fasakQURkC7kOzC4khoMuMBaBE0s5vazty7a TDUna3Swr4uUETOjbopY0a52XUAOO8ONDFgfL7HhhTIe6OXg1wgKZB0qNTkAoW+5B+QX lYrK5bfEkYWdcpRNsES96fLArHVqKKMkkoimmm52jXKtbsbPmiWlHLr5sQ9zBObijOm5 AXrrRHLSJsxgkigp/wZ3aS0U8jla9mjj06aj43LgZexNgra6z8KbeppCd2CqFfOycfEo qba9K61I7e5pyvC02GYl+MAiv5f3JMFBqC6g05o3tdCNPqJBs4j4ZYn0X43jHRzU+5Rn lQEQ==
X-Gm-Message-State: AJIora8bgOaHWcqL45rX+Z25j/GU3N98+GXwgeS6efxTd3ld0u12I48P CGWz2OmOLeMhJnncZzCYdGcdozWOJrGGDx7WDTt0K6SpcUkerwPKyXb6kAsrwi4AmurVoPyKPeE asurrC/U8xgw3/Q4DCAYj6kR+yotlq3qtFIOtrjpLbdky11kRDB9scHQY/T870SSknl0=
X-Google-Smtp-Source: AGRyM1to/+TVqCUNWb1/LsNzYAy6j5m2CvsctT9pXn2TYsZi4tfmgwnI307pmidqo/UNwwqDmIy71w==
X-Received: by 2002:a5d:5a9b:0:b0:21e:8d21:8983 with SMTP id bp27-20020a5d5a9b000000b0021e8d218983mr11077627wrb.692.1658991426149; Wed, 27 Jul 2022 23:57:06 -0700 (PDT)
Received: from smtpclient.apple (181.213.93.209.dyn.plus.net. [209.93.213.181]) by smtp.gmail.com with ESMTPSA id g9-20020a05600c4ec900b003a3199c243bsm5696550wmq.0.2022.07.27.23.57.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Jul 2022 23:57:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 28 Jul 2022 07:57:03 +0100
Message-Id: <A6F210BB-1F6F-4235-A213-2E274561D5F6@forgerock.com>
References: <CAGum7cFFUg2qzom1Vu8wsNJapeOkWFoqe_aD4FyGcxr6nwcCgQ@mail.gmail.com>
Cc: jose@ietf.org
In-Reply-To: <CAGum7cFFUg2qzom1Vu8wsNJapeOkWFoqe_aD4FyGcxr6nwcCgQ@mail.gmail.com>
To: Tobias Looker <tplooker@gmail.com>
X-Mailer: iPhone Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/y1v7eoKjcTj1ELsM4tOuD9fy7pg>
Subject: Re: [jose] JWP
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2022 06:57:11 -0000

> On 28 Jul 2022, at 00:08, Tobias Looker <tplooker@gmail.com> wrote:
> 
> 
> > If you’re going to do this, why not just ask the issuer to give you multiple tokens in the first place, each containing some subset of claims you want to disclose? In the limit you could issue a separate JWT for each claim. Is there a fundamental reason this doesn’t work?
> 
> If I understand you correctly, the biggest limitation with that approach is that it requires the holder/prover to be online and able to contact the issuer in realtime to get what it requires for presentation. That might be an acceptable constraint for some use-cases but not all.

No more so than JWP does. To clarify what I’m suggesting here:

In JWP the prover at some point gets a credential from an issuer containing claims {a, …, z}. They later on can selectively disclose some subset of those claims to another party. 

I am suggesting that you can do the same by asking the issuer to instead issue you separate JWTs each with an individual claim (or minimal subset of claims): {a}, …, {z}. At a later time, the holder of these JWTs can send a subset of them to the other party to selectively disclose just those claims. There’s no need to go back to the issuer in either case. 

(As an aside, issuers are often required to be online anyway to check revocation status.)

If the idea of going back to the issuer is to support unlinkability by ensuring that the token is randomized, then I’m not convinced this is needed. For example, to use the commonly cited scenario of proving that you are over 18 (or 21), assume I have a minimal JWT with the claimset:

{
    “iss”: “gov.uk”,
    “over_18”: true
}

If this is signed using a deterministic signature algorithm (eg EdDSA) then the token will be identical for everyone that is over 18 and so naturally unlinkable. 

Such tokens only become linkable if they contain PII (eg email address), which obviously is inherently linkable, or contain a unique combination of other constraints (eg unique expiry time) - which is something that an issuer would need to be mindful of in any case. 

> Issuing each claim as a JWT as an approach to selective disclosure makes the representation of every claim pretty large too (e.g claim name + value + a base64 header + base64 signature).

Sure, but I just want to clarify whether what JWP is proposing is “just” an optimisation of this naive approach, or actually is fundamentally different. 

My suspicion also is that in many use-cases there will only be a few natural subsets of claims that make sense to selectively disclose, so the issuer can probably just issue the 2 or 3 JWTs with those subsets of claims that make sense.

Another question that arises is how to handle constraints like “exp” or “aud” that an issuer might impose on the tokens it issues. In JWP it seems that the holder can also choose to selectively (not) disclose these, which seems like a security flaw to me. Issuing separate JWTs allows the issuer to include these in each one (and even to vary them based on the particular subset of claims). 

> You'd probably want to wrap all of these in another JWT also to establish their relationship to one another which further bloats the overall credentials representation.

I’m not sure why? eg a JWT with my address and a JWT with a claim that I am over 18 both stand up on their own and don’t need to be linked to each other. If some subset of claims only make sense when taken as a group then the issuer can issue them as a single JWT. 

— Neil