Re: [jose] Next steps after the JWP BoF @ IETF 114

Brian Campbell <bcampbell@pingidentity.com> Wed, 10 August 2022 22:15 UTC

Return-Path: <bcampbell@pingidentity.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 A34C2C157B44 for <jose@ietfa.amsl.com>; Wed, 10 Aug 2022 15:15:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=pingidentity.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 C2LhHbmyRQAT for <jose@ietfa.amsl.com>; Wed, 10 Aug 2022 15:15:54 -0700 (PDT)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 22E0DC157B42 for <jose@ietf.org>; Wed, 10 Aug 2022 15:15:54 -0700 (PDT)
Received: by mail-yb1-xb32.google.com with SMTP id 204so25565352yba.1 for <jose@ietf.org>; Wed, 10 Aug 2022 15:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=GmEnWwcZUsJ45GlZwkNWkfH00Y5MERyyN4Ok2bF7efI=; b=WDfsAfpl0mafiLN94BEPnsyi2ygT466dYVCeTGnnRTewkZwRi+MBJpRO9v92lDs8hx ceSgH6ABRRUX4TAvREzV2UH7MaKOJTEdxJ3sGUWeGoKc4y/vX7NAId8XUVVNbPpo9Nsn x8Bn+RBVt7OcUrjHzWlbYeu8QeW2DuS/XBleIwPtTf6byOU2vfOia+04pQ/tBsVYl9a2 DZPGhLmUUOX3EfZPyHbljDUHJV4x38xNtcVPwu8Cdgdsr82ElnimRhP1mzpH770gD/WU lHiwjOWcKUXHzaNuU/dkrmyFWvvJ/rZOnvt0/Yo+gGQPL62f6ZonY2Utl117+lOmXTmf 5qNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=GmEnWwcZUsJ45GlZwkNWkfH00Y5MERyyN4Ok2bF7efI=; b=IrIvOWgF/I2maA2ORLvlP4AuYPbXJfIs6qQmchCb57dGbZOiAEjebmNHmAmcwDj/H6 3jr1JBmlF0PlZf2uG8Xg2wyQPJ1Qqya8l0yJEFBtIsAGgasUQm7U7Z7rQr3cS40qXfnh fA8pXUcE1yiE7ScyL3/JlWwe+ChNi5iWZH5OFyCdo01E00b+t2FYYmQ/7mdta8o+J6I9 1ypH+bGbNbT2Ey7cu+H4AmdVfy6oiFnyJlhOITymDDnhwUm+/7qHCg/65lglquUo7Cdk uXDIUsD8+KyyfatGEqqmCqRewrM/amKao3/L8bB+camf56fuRf2XfsIW/5Xo1YahYII6 cQSA==
X-Gm-Message-State: ACgBeo3XzpW1MfxQnkH86bLeonU3EJuch4T9VfWbH7FlrnKlYE2S2Q0w KBzynEOXXlQN+uiIv6d/QegwxhJlx2AZuIOK3k2T+2KWiLLCdOUEBwPESwHssYKiERHtSqsOHdz RRisLKm0v0b7h
X-Google-Smtp-Source: AA6agR7/Z0G4PAa239PpqXwAHAv4yJvoTa8QyseSVbbe035i+iZLpfuCW0LFfm01ofP/V6dRigEoMd5Ae8ErJMu/2UA=
X-Received: by 2002:a25:c709:0:b0:676:bf77:c838 with SMTP id w9-20020a25c709000000b00676bf77c838mr27626194ybe.430.1660169753158; Wed, 10 Aug 2022 15:15:53 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR06MB706116362B6F56B45F7D5067C2979@PH0PR06MB7061.namprd06.prod.outlook.com> <CA+k3eCReiagB5Z0RoXaQK5xJzm1m5Z+Qh7E-uaBy4rLrOjt6ag@mail.gmail.com> <CAAFNpxvT-8H6Z-PWTFKt=W3em9uoBLzfX5PYRqDSULmUCRf-zQ@mail.gmail.com>
In-Reply-To: <CAAFNpxvT-8H6Z-PWTFKt=W3em9uoBLzfX5PYRqDSULmUCRf-zQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 10 Aug 2022 16:15:18 -0600
Message-ID: <CA+k3eCSb4Lo_uQa5mtOJZ_YnUweyihhsckxTJzmgL7zvhzgb4Q@mail.gmail.com>
To: Jeremie Miller <jeremie.miller@gmail.com>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006788ac05e5ea6423"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/ramFRlZIxRK-z_SNBdWJOUMprK4>
Subject: Re: [jose] Next steps after the JWP BoF @ IETF 114
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: Wed, 10 Aug 2022 22:15:57 -0000

[apologies for the delayed response, I went on part of family summer
vacation right after Philly]

I can't meaningfully speculate on those specific questions, to be honest.
My point is more meta, I guess, in saying that mismatched expectations are
much less likely when the container/abstraction itself provides a
relatively consistent set of security/privacy properties. Because
unlinkability seems to be the one thing that something like JWP can provide
that plain old JWT cannot, that seems to me like it should be a focus.
While including selective disclosure only mechanisms (that can be done via
SD-JWT) feels to me like it distracts and detracts from the overall effort
and would increase the potential for mismatched expectations down the road.


On Sat, Jul 30, 2022 at 11:02 AM Jeremie Miller <jeremie.miller@gmail.com>
wrote:

> Thanks for clarifying Brian, I still think this is one of the best
> discussion points:
>
>  For that reason and others, I'd suggest that JWP focus only on newer
>> cypto and the things JWS really cannot currently achieve and have JWP in
>> general provide a consistent set of security/privacy properties.
>>
>
> Since this unlinkability property primarily concerns the holder entity, I
> could phrase the question as: does the holder developer expect that when
> generating a JWP presentation it will always have the unlinkable privacy
> guarantee?
>

> Consequently, when they're unable to choose JWP due to the inherent
> underlying algorithm requirements and still require unlinkability, is
> SD-JWT with a batch/refresh single-use mode an adequate fallback?
>
> Jer
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._