Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

Orie Steele <orie@transmute.industries> Fri, 16 February 2024 18:11 UTC

Return-Path: <orie@transmute.industries>
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 E168DC14F5F7 for <oauth@ietfa.amsl.com>; Fri, 16 Feb 2024 10:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 WKwQSm2vS4GT for <oauth@ietfa.amsl.com>; Fri, 16 Feb 2024 10:11:31 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 CAA47C14F5F5 for <oauth@ietf.org>; Fri, 16 Feb 2024 10:11:31 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1dbae7b8ff2so5363815ad.3 for <oauth@ietf.org>; Fri, 16 Feb 2024 10:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1708107091; x=1708711891; 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=yZlwQHlAWXGHgGTliL9eco75TTGUyfq4Msl/Ui6o22E=; b=UEFVJi71sXubf0zFC1GAA6NpOnYHyaTp1sTM1reWAJQeMTZ1b9hWoITXPSVxxIZHG/ qpjRr7HewRsTyDgYgYl1gmvphopVReTpL2Yuz6izIXlGUgQIPWE2fna56xWrtdKFQMNr ieYqeZYhg/J5o2DoFjCiaTece7wYb+bVzQnupcWG/z5jE+I+BHIVnsDfguEN8TStw9eN M2WYHxYE4t56sNrf/XQ1nRApQR1qFx2sOf9kIxUB3eq5iZzq22JZJ56le2iwx/t+r71L ghn0/ZP4u4y7YHqSF7QjJduJ6fQgSScqR6oiu8wolDu2RgksnK7wqKGehTUjKn3KepVH hkjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708107091; x=1708711891; 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=yZlwQHlAWXGHgGTliL9eco75TTGUyfq4Msl/Ui6o22E=; b=lrl786HWwPrlSRW3TC2PKOWftq7A1Imn5MH7HHRhvpKJxRhi9LZkiVj4u2mZQ5BuW7 BQLW+zcv1+Iy5sAqVeihITrbEyoLn99zzImu+KdIQwulOlLGBkhR4GwPowcQ9ehoIo+c 8q5UDY/ciWIlZvBTTDB3hKtkk95gS2MJY+ASq3IC01sujI1mtgC18dnepcA8e9C7s+Xk ES2oSAXXKM5EEZt4+oS17f8OPRFdwbrNii7z/Uu+tz99sxv2EcAG9AFIvRgzdEsuGETq loe2tjl2VEZN0O1lG+3jLTG4w0neSRCH8TwxKFYjXd8RVDAiaC2JmV/Cfq8XtsOg+8p1 cxbQ==
X-Forwarded-Encrypted: i=1; AJvYcCWB8ianb5epkwbdhoDixkpn3Vht4KD3/mHOYUCFY7OWFIIEeXSX8UoNzDclx0dtelyqn5oO29dRzo9mHXC1Sg==
X-Gm-Message-State: AOJu0YwgsTjmUqOYk3xI10uPCrV7M8gMsd7TmNVe4ZYaVsU4sE8/By4b UAtRXpcXO2vkEdRaIkZ6mF/G69sRx01A/AUNvH8DGHg11L61d6cdLjfoUcxEuyMKVcAbv5KLJwy 6urpMWKogcc++WjPR1ozsEpC4CbLxgYhsYbqFjU0tOsREvild1J4=
X-Google-Smtp-Source: AGHT+IHD0s6gRAP8xzkUFpWMBf4h9Ou4MwZc03fL6zj5n7iEEFLyuKozEjrXGOUblqPsF0AzmFf7KQdJb/3dZTMEZJQ=
X-Received: by 2002:a17:90a:f003:b0:297:196e:df63 with SMTP id bt3-20020a17090af00300b00297196edf63mr6008144pjb.33.1708107091096; Fri, 16 Feb 2024 10:11:31 -0800 (PST)
MIME-Version: 1.0
References: <BN2P110MB110725C85B7253C421DDFE71DC4BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <BN2P110MB1107C4999047DB10B00E71ECDC4BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAK2Cwb4okK1T67-4KyZTKBc846wcP7MVizZ2QYgJJFAcUcPz9w@mail.gmail.com> <07e701da6046$40e704b0$c2b50e10$@prodigy.net>
In-Reply-To: <07e701da6046$40e704b0$c2b50e10$@prodigy.net>
From: Orie Steele <orie@transmute.industries>
Date: Fri, 16 Feb 2024 12:11:19 -0600
Message-ID: <CAN8C-_JjmwhT3+347WybBV4J0f0ki0XH7GzYrMxozDxk25cVzQ@mail.gmail.com>
To: nadalin@prodigy.net
Cc: Roman Danyliw <rdd@cert.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000067498c061183aca5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iT6jSphjHcEm3fssqj_fGRuvBAI>
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2024 18:11:36 -0000

Hey Tony,

On Thu, Feb 15, 2024 at 1:36 PM <nadalin@prodigy.net> wrote:

> 1) Do you support the charter text? Or do you have objections or blocking
> concerns (please describe what they might be and how you would propose
> addressing the concern)?
>
> Not sure I support at this point, I understand the need for an
> architecture document with patterns and definitions, etc.
>
> There is a lot of work going on outside the IETF in this area such as the
> mDL work in ISO that already has patterns and definitions along with
> credential formats (mdoc)  and transports (ble/http/nfc). I don’t believe
> the IETF should ignore these efforts since most of the driving licence and
> passport communities/companies are adopting this as one of the standards
> that issuers and verifiers will use. The same is true for W3C WebAuthn.
>

WebAuthN cannot produce standard digital signatures, and so it cannot be
used to produce standard digital credentials (for example it cannot be used
to produce JWT or SD-JWT).
It could produce authentications for public keys that could be bound to
credentials, but because of the origin binding in WebAuthN, this would not
fit well with the "audience" typically used for digital credentials
(usually there is no audience)

You might find this thread on possible relation between mDoc and CWT
interesting:

https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/


> The architecture, patterns and definitions should be free from technology,
> I don't know why W3C is mentioned in the introduction as the only
> technology, this should not be in the introduction but along with other
> technologies such as mDL/mdoc, webauthn, etc when describing profiles. As
> the goal would be for interested parties to produce profiles of other
> technologies to fit the architecture document with patterns and definitions.
>

W3C is mentioned because some W3C members asked for a term other than
"Verifiable Credentials" to be used... and they asserted the "Verifiable
Credentials" implies the JSON-LD data model developed in W3C.

ISO was not emphasized because formal coordination would require
contribution from ISO experts, and we have had relatively low
engagement from them.


>
> I believe that the WG if formed should also think about holder
> verification and patterns and attestations that can be used.


Interesting. I think this is covered under the metadata discovery
deliverable, but if you feel it could be made more clear, please send text.


> Also there needs to be a notion of a "reader/wallet/etc" that can
> potentially store credentials (not necessarily the user or verifier) and
> release/store credentials upon "user" consent.


This sounds like an application to me.
How do you see this related to "credential formats" or
"issuer/holder/verifier metadata"?


>
>
> There are other models than the 3 party that VCs use, so these also need
> to be considered in the architecture,  patterns and definitions documents
> to enable profiles for other technologies.


Agreed, OAuth JWTs/SD-JWTs, and ISO mDocs are examples we have discussed.
Are there others you would like to see considered?


>
> I believe in the 1st 3 items in Goals but  I don't believe it would be in
> the best interest to define a metatdata protocol, as this sounds like this
> would be a protocol for obtaining DID documents, there are already many
> protocols out there for metadata retrieval, not sure there is a need for
> another one, if one is needed for DIDs then that may be better done in W3C
> as this does not seem to fit well with the charter
>

Discovering attestations for wallets seems to fit here, why should URLs or
URNs (DIDs) be specifically marked as out of scope?

For consideration, JWK / COSE Key Thumbprints are good alternatives to DIDs
which have been standardized / are being standardized in the IETF:

- https://datatracker.ietf.org/doc/draft-ietf-cose-key-thumbprint/


>
> This charter seems to be very scoped to W3C technology, I understand that
> interested parties will have to contribute if they want to have other
> technologies included but the charter in general does not seem to allow
> this, so removing specific technology will allow this to happen.


We chose to use "Digital Credential" and "Digital Presentation"
specifically to keep the door open to CWT and COSE Sign1 structures which
are used in IETF and ISO.


>
>
> I would be happy to give provide specific text changes to the charter.
>

I think it would be great if you could offer text that refines your comment
about format support, and holder/wallet metadata / attestations.


>
>
> 2) If you do support the charter text:
>
>
> 3) Are you willing to author or participate in the developed of the WG
> drafts?
>
> yes
>
> • Are you willing to review the WG drafts?
>
> yes
>
> • Are you interested in implementing the WG drafts?
>
> I'm willing to see how we can use these outputs with the other industry
> technologies.
>
>
Thank you for your comments.


>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>