Re: [jose] Profileability of JWP and JWA

Orie Steele <orie@transmute.industries> Mon, 04 March 2024 16:34 UTC

Return-Path: <orie@transmute.industries>
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 96377C151986 for <jose@ietfa.amsl.com>; Mon, 4 Mar 2024 08:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level:
X-Spam-Status: No, score=-7.085 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, 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=transmute.industries
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 exofOKnfsAnn for <jose@ietfa.amsl.com>; Mon, 4 Mar 2024 08:34:40 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 00632C14CE2E for <jose@ietf.org>; Mon, 4 Mar 2024 08:34:39 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1dcd0431f00so29100735ad.3 for <jose@ietf.org>; Mon, 04 Mar 2024 08:34:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1709570079; x=1710174879; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1MmLWSaUto9WULj36wJ4b97Fd63/Kp9+W+9jQfcXvuM=; b=cZpHroVRTamZzGoCKbeLGO2oi0xHTqf53upIDBxyj6RnzJdAcShw7SYf/UDLQuiGA4 PVrA/7hghw9iThNeSSOdXN63ZsrjkGj3iNbWdx/785PqsJQkKes4+sUqwgOsKQv5+1zT NO8CX8KxPzuMvmBOYzuJRRotEsE933y4v5CIfrBdWgcz58JZ6S3tY2XqR4FxqmGGpAjc wKjxNPJ1L1VDM0ezk85esyjT+0VnQ1+7mvDC4iJDf8mcF3twbYNcdx32KV61MFb/ZreT /mPXlqh2IigkmB45rlY/rFbJgvikI+lnsN3PAf5ue0woYg3yuPqcDQlnWPmBjxTlvDpC skqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709570079; x=1710174879; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1MmLWSaUto9WULj36wJ4b97Fd63/Kp9+W+9jQfcXvuM=; b=uKAaXRo3IQ780QTXOl87tpQWJNHbNy2NAJ9yvs+KNc5kwPSdsyIqVf+oRxYlUPzbvV cXTUP1xfMwt+8jcjwUoNN631/fbqJxg2EG084PfEmaM6i5DSjPfdZEQJBx+rleGSJDck 6dDe99jRZiSUpvubVUXXKWusEQdjUtiYgadd3VnhIuuH1ho47laMdnoXX38JW17Vk8DM 6isnuBRh7rE2iLbC/qbRpzG+ucRKibNi0T3lFJJc2f7rMHMQuhGdpVzn0xYD2N6ZmIDY 09Z61/kE5iaMTge0xdLGk/debe5Sjx8F7c3vMQRDdlSYf+HbCKzaDHiJB7EpEmgnCPOa nmpw==
X-Gm-Message-State: AOJu0YynoDVv8A7kUYcHuUPPudyVRC8K2NUZ3DYquQSZ7dvZda06ruSw 304L8cvSUN+abTLj7zHIDwlYQBthkW8dh472Qxc4/NVx88t/evycAHB1W3OMKGk8bwjNuuBI8Uq 7VHOgsBsFEKoXJxbibrrUx4BAor2rKBxr2QFLSqyalOOB2KBb7CmWZA==
X-Google-Smtp-Source: AGHT+IFL3qMdz4pl7frQPoPk4pkVNb3aAxTIW1HfWDDX4gy+fbJHGUIxjrK7/iMiHM81fRtqENWBcavE571IepEdtI4=
X-Received: by 2002:a17:90b:17c7:b0:29b:309b:a131 with SMTP id me7-20020a17090b17c700b0029b309ba131mr4660407pjb.10.1709570079252; Mon, 04 Mar 2024 08:34:39 -0800 (PST)
MIME-Version: 1.0
References: <CACsn0cn=1d0LbKyR2Kf1dXBx86hJ_CMuRNoBpraKSRrXtBUU+Q@mail.gmail.com>
In-Reply-To: <CACsn0cn=1d0LbKyR2Kf1dXBx86hJ_CMuRNoBpraKSRrXtBUU+Q@mail.gmail.com>
From: Orie Steele <orie@transmute.industries>
Date: Mon, 04 Mar 2024 10:34:28 -0600
Message-ID: <CAN8C-_+_svJOooFTfPJRTr3N+odWp-W47S=qoGDA=heLMGCSZA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: jose@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b026b0612d84df7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/YkC5N2GBRjZ14cIyqWsAsnNeU9w>
Subject: Re: [jose] Profileability of JWP and JWA
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: Mon, 04 Mar 2024 16:34:43 -0000

Thanks for giving the document a review.

For some background on applications of BBS.

There are other work items that I am aware of that bind the "claims
structure" very tightly to a specific serialization.

Namely: https://www.w3.org/TR/vc-di-bbs/

I worked on early versions of this approach, and the application
preprocessing that is required to safely convert application/ld+json to
application/n-quads, and then to binary messages that can be used with BBS
interfaces is substantial.

The early designs for BBS in JOSE and COSE tried to address this directly,
by separating algorithms that take binary inputs... claims in a
serialization that can be expressed in binary.

The goal was to reduce, as much as possible the "application processing
overhead".

Of course for JSON, CBOR, we have to consider unicode, and CWT and JWT
claims in registries, etc...

It is therefore nice to have at least 1 place, where the algorithm and
interfaces are defined without assuming serialization preferences.

OS




On Sun, Mar 3, 2024 at 2:06 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> Dear Joseans,
>
> I've read the recently revised complex of drafts, and have some
> questions about how we envision profiling working. It seems like the
> documents defer a lot of the capabilities to the algorithms document,
> while imposing some convention on what the claims representation along
> the lines of "the names of the claims are strings suitable for JSON
> object keys and have an order, and the claim values can only be
> selectively revealed". This matters for both developing more
> algorithms and for profilng: it may be that we end up with a profile
> having to pick an algorithm, and that new algorithms with new
> capabilities end up needing special treatment at the level of say
> SPICE.
>
> Secondly I'm curious where things like binding to upper level
> protocols or enclaves are supposed to fit in here.
>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>