Re: [jose] JWP analogy

Richard Barnes <rlb@ipv.sx> Thu, 28 July 2022 19:51 UTC

Return-Path: <rlb@ipv.sx>
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 C69F3C15A72B for <jose@ietfa.amsl.com>; Thu, 28 Jul 2022 12:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20210112.gappssmtp.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 hM7EjffXkqFy for <jose@ietfa.amsl.com>; Thu, 28 Jul 2022 12:51:02 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 47C88C157B37 for <jose@ietf.org>; Thu, 28 Jul 2022 12:51:02 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id e5so1922040qts.1 for <jose@ietf.org>; Thu, 28 Jul 2022 12:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yBUYFTNQUF3QG/fz3MO51U9el4bb3e1Mx3Ooqv8yXNs=; b=NmMH6kZ0F9hELFqWy+5w6RLWkKcmYvW/nMtgt1lhnFQgXk8fmpUAeUh55EsqRvj1Yc VSaD+JsbfEPxiOppuHTVtbjJK71HnjkYZQAnP8V1Lyd4N/zjqIq3kAg9RYFwyQyQ/vVX R+lRRiZDnx5AZsKX2cfqcPJ7GCIpeaX/MgVhSsrGjIP1sIZMmIy7M6t20Zkx19owYy9r +ZzvceBgWlSLECC4odApj+NvjCYp+sXqaMZk2emIyvFL1TVnDnRmiYJSRiiLaeSiAaZc IE3Q5G2HCT8NO9KD916o6VE8QxAgmw2t4fg/2wosZAI+bm8IyDh947PPQRJshd0ILA4C MfuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yBUYFTNQUF3QG/fz3MO51U9el4bb3e1Mx3Ooqv8yXNs=; b=W+ToEYllpA/KEKK9ZIQYnQSqa3T0dcF8GeUI6ojqaZe2FLdDxvq+t4JHrV5SPzFkQf mDzAYObNY9qJn0G/tL3p5TYr/ARwi3+pCLyw5pFnwdjvBxM3/oxcug1KLEXPLSkoBtoo TdvSY8R4uM3AFJaokq3iq+XoiuUVN1RBWLDgBJaal5Rh5QDsrex4oPJ75qJVmQxQJR/o KeOxi/ZUILIpR8ATmabk9XfPy2xxPQ0tU2fSNt+WPY09ZAuCO3GYiYe9Vgug716MZYeF aTu/7h9llVtpZpw4CZCaDQnHLNpYIAdhSC2zk5LiT3k5Me3e/nn+JASPb5HHrepiO1In UFhw==
X-Gm-Message-State: AJIora8Vum1WdRUR9YGDxPHhV6/OqjDD/YKVn8u+2xvvTJO02GKMfjoF zYNWUb7k6lMzR59A66K1NLtvSFtfClSCLF0qr4y6ZsUzPK4=
X-Google-Smtp-Source: AGRyM1sW/Qr2+PpbCLNhvs+or9zhAPFByt+/zrWkBm7zJaLt/1+8Aa1xz42dRxrbFVeecBKPCdobK9/fT4t/C03Qas0=
X-Received: by 2002:a05:622a:390:b0:31f:3729:5595 with SMTP id j16-20020a05622a039000b0031f37295595mr497233qtx.291.1659037860836; Thu, 28 Jul 2022 12:51:00 -0700 (PDT)
MIME-Version: 1.0
References: <CO1PR00MB099675CF6652137A9BAA5E31F5969@CO1PR00MB0996.namprd00.prod.outlook.com>
In-Reply-To: <CO1PR00MB099675CF6652137A9BAA5E31F5969@CO1PR00MB0996.namprd00.prod.outlook.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 28 Jul 2022 15:50:50 -0400
Message-ID: <CAL02cgQBEoPbOon6kK1NkVzD6P6oM3CTvRu8u6YmeFuKvYTPjA@mail.gmail.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005d4a9105e4e2da78"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/DxdectmiPicgLXj8DkRIvUgui1A>
Subject: Re: [jose] JWP analogy
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 19:51:06 -0000

Drivers' licenses / passports / etc. are a terrible analogy for JWP.  They
provide neither selective disclosure nor unlinkability.  They are highly
linkable by design, and as far as doing selective disclosure by covering up
certain fields ... well, I wouldn't recommend trying this at Passport
Control.

If you want something holder bound (cf. picture on a DL/passport), all you
need is a subject public key, e.g., via a "cnf" claim in a JWT.  A
DL/passport is a JWT+cnf.

I'm not pushing back on the work here, I'm asking whether we need a whole
new struct for it.  As SD-JWT shows, selective disclosure can be done
within the bounds of JWT.  I haven't caught up on the other thread yet, but
it seems like it remains to be proven whether unlinkability cannot be done
with JWTs.

If we want to make a charter that says "define a structure that provides
(a) holder binding (b) selective disclosure and (c) unlinkability" and then
fight out in the working group whether it's a usage of JWT or something
different, that's OK with me if it's OK with the AD.

--RLB

On Thu, Jul 28, 2022 at 3:20 PM Mike Jones <Michael.Jones=
40microsoft.com@dmarc.ietf.org> wrote:

> *Three parties* are involved when using your physical driver’s license:
>
>    - The Issuer – such as the Washington State Department of Motor
>    Vehicles
>    - The Holder – the person to whom the license was issued (you)
>    - The Verifier – the party you’re showing the license to, such as a
>    grocery store or policeman
>
>
>
> A key point is that you don’t have to (and don’t want to) involve the
> issuer every time you use the license.  The DMV doesn’t need to know where
> and when I’m making age-restricted purchases.  *You don’t “call home”.*
>
>
>
> Finally, *the license is holder-bound*; it is not a bearer token.  Even
> if you’re in possession of my license, you’re unable to use it (unless you
> look just like me!).
>
>
>
>
>
> JWP enables these same properties in the online world.  It uses the three
> roles.  Presentation to a verifier doesn’t involve the issuer.  Issued
> tokens are holder-bound.
>
>
>
> And unlike my physical driver’s license, where everyone I show it to can
> see all the information – including my home address, JWPs enable selective
> disclosure, so that only necessary claims are released.
>
>
>
>
>
> Many parties, both during the BoF
> <https://datatracker.ietf.org/doc/bofreq-miller-json-web-proofs/> and on
> this list, have expressed needs for this functionality backed by real-world
> business use cases.  I urge you to talk to them, understand their needs,
> and understand how JWP will meet them.
>
>
>
> Let’s (re)create the working group and get going on the needed standards
> work!
>
>
>
>                                                        -- Mike
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>