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

nadalin@prodigy.net Tue, 20 February 2024 01:34 UTC

Return-Path: <nadalin@prodigy.net>
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 72F79C14CEE4 for <oauth@ietfa.amsl.com>; Mon, 19 Feb 2024 17:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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_NONE=0.001, 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=prodigy.net
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 4DVq1CPDJV1V for <oauth@ietfa.amsl.com>; Mon, 19 Feb 2024 17:34:17 -0800 (PST)
Received: from sonic304-28.consmr.mail.gq1.yahoo.com (sonic304-28.consmr.mail.gq1.yahoo.com [98.137.68.209]) (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 B3C26C14F709 for <oauth@ietf.org>; Mon, 19 Feb 2024 17:34:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prodigy.net; s=s2048; t=1708392857; bh=pqvmGNLtj5z6vaSIuqc98+sKKO+LAjffPLHM/g3q4JE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject:Reply-To; b=k/P83lNWPLNHUgM/yC3SXSWvoSs/VOG/0dCLbw6yceLwE1WHlzz71G77msECd625QuEFAkpq5l6woPb9eaFFyrGSIKs6UpIUUXM74OtdW9AenszTad6y47e8n422VEBg/1nfy67GNJXfTx+bkOBtMNozU/U/2Bi6/MH5Cgs8EdJaE23+AW4fFuLZ0u+tLpqexNMlcrqo3bdGep8HXCrrZWwM6nKVuzr6ySMBlIZYayWAxxpMfIuflZ6r1ykNBIw5ZhoAntgLwOj4NiCyweYzneoZkqtpZaeH4a+tqh2jcXb5Iy3Yjy1ZRG++pC43m8yxAp8vGNSG16ZbtkVYuq7PLw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708392857; bh=xyJhysXgRqpnx9Iv+zZJ1GSPQN+iBI5ae0ehbttHabx=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=gyQlTYhFS/Bd4eqxuUb0Ig1JCQPc5gRSnFuiNByNeltBRIYHeZF1fTJxSsWuygHfQzF1woiSDCFcAtv98MVRgxhwGG8LNjzhZCdjTZ3mH53aN8E1ngKiPdM+vyTAAlx3H6oqPc5/pigHsK/o6lv21shfenscmOVR6a2ROxZhHwqAzQCxcYEeGCbwqyPtBhZVnt0axlSGYv3qi1qjsRVT4fTcE8u7JzO4We5Qhlhwkjin6viLbR2bujM5MzUm2kboh07pa6IeE6fK++MerfbccIaqmB0xT56C2odNWdGkdadqEeIL8/L1ZO+Lhqpq8FlzkoO0bxg39J5rDvLCMVCvMQ==
X-YMail-OSG: 9pvEVLcVM1nQoRe78KDu9t.NlByYSXRAl8w2naFrI.9s175sZva6_a3G7Sp8VQ5 l2qbsfpIiVc0fGMADmZ1ns6vCco0wSJErgDO0EGU0b6dWwJ.jlImSDYIMnExAZfx7EwP0zQwIIK7 6q2g2aSiyUtn3zztiKNjDWXrLV.D.w_h1.n0.MMqSNYJhy0e2DjiqqA7gsTEbueMmVqSavKh9xM. ympu.PiITcv0Fjg1GMzZXEkml5fnqcsNjCTVr1O45ETbwY_RUHpYGVPOfy.srouNspDVaCWIcSIK E09W9SuHTWyTrB7fvZ.bkg4xS.uUdwzfzsjWFI4e8WIe34RG7Vok6WZrLO4CHc8T04ubIUQY.o8x 2DfCTeyLJkK59qfBSwTcTjPiXTms3kZ5v9G7T9SL_beLtgfK7cHVBkZvh13gBrNl6ws63SE7Prbp GBpPfmm8.h8_ubayV.3GVAJ1gQv3Bl2J8IJnz0MIHh6tpJntT8o_UDo_nQFZIeQs4IsGg.efeIWN VUniAr2jLVMoR5FxaTj99ddOhv4uMO0XTopaMNHnbqglq2GHj8j7V2nNJYzAuu8WyOHnQ1DeHGOz fjK29vTcNkG8kBe9FJ8sWLsBHvMkVxUwKwuz3RKMwOwueyQBtz24gGK177TCRHklHaUes_wOyDPZ UNvn0PAGXFIt5Xmj2yFTjqDnqbaAn1xguY6iJ3IQjL00Wsvzk8nltTy7xyJbJIcLTRXcZccYB0q8 Pyq3SRcNB3c2c.DODCFTSLuiT5eGrNxC4dn7yDB7mCQszu23oiM7rujdXJ8ECJIol736qIaC.O_A u7XhF9SphzNnuuAHc711fgLJVDRkt7fMIgwmD.wOqyG.yyZ2KEkJKwkPyrE7EmPklOgKFedcUa0V zKuZhU3QlifHABKcfLldPPFuoP4fRGXP73nMHcuOuulFKawchE8xTeosmTsNytN70dTdrM18N5wf ypY2WsITWNsUGxNmksyuOGAX_7PMn9Em5tApIbAzOWMhbgqmbATQi20VqJUcvhynGNUvXsFWo028 dIJTInyUiRI7iYfd8ST0gWSYodOA8q5kKMpqltMfSzzEmC8gObKLZFYs8ZHAJtose0I.lVVPEdZu ks8TEQF5tRH.Ed1l53IBhEdubM1WNIYMYq8aAKJQOPtvz_j6BJSVHDl7CWmDSxwEFCLZYBTM39QW 0Rwl9tCzYpZS.suPmwD3YhB6sxhvwCE4HwkSj5cdETehOjuHbptHBGdpwLRmPyPHVVUpykXMQInl cqV9SMeE70u4FM8ZWBXaCN6sEn1rRPCR1n_ENrIdR2X7H2cCibaPW9Prk.sLCSzAfNgg3zmtzsfe VtJYXLdFcb_Ho4o3uMmXRdhuxMrh30NEZDIzgvJIq3NjX2ikydMrVFKHadyR0A.kRuO2S0FcsIuP 7yqUzgFkh_V2eGMp5JphHfXqjO8ipMQX879ixo20uWIuLlAMScdN2U4s6b_xU0zNgKgN_m9HNCeK M9gJRG.oOqaww5L1Uzv5tMJuGeihWG9O.MjmlqbXC1YM0aijejA_AG2Txpy8PK500vZzRug3sZ.1 jIYQcRibM0JWflPuoto0e2lKMuOGfxwcp1VQf1k5MXP7xIYjmrK12HclKEPKUpqtxwZrwccFFuH. 87z6uSYl_Ee5NwN.Y1YMF0ELlmeOF2L4DJpEusVbGgOUfFNa7Tb3yzfsjcQR1Zkx.WAw4Jkjf_5l 6lK8j2P8caBJBGzbByBHNb3UG.VPf7eJ85suG_BhRznByO4JcGS4fawIZJOOVs2ME2bbMYugaBdS C4XbhHmwOyJ3.MwPCyEbwgXUnyOQfi9.CqLZz1HUX6CdOWJgTOkcYKHNjCWQRGp.HYtfpcjdzrvr lC7qEhyEQPp_kfE9GNEb7V4vR6EYZNhvWh4Do9QSe2q3BlduTqVM74yozTgxz77ffkvaS28H988I GJC.bCiPQEa9xYWNnE5wf_Be_rRi05f2rzXVb7EMMsY6uPVpex8yZtMnNPDPYg0yGqDhBxaNjef8 _NlMlcXd_QBzbuW1Zk7r9oTjvhWHxdVgaIIGQ1uYQ.pz.gJTOi8lwJ2ya8gM2Y8oqC2.57AunCC5 OB2twu1vEGGAoZaHtj48HEPE9K4uh3o3rPU3NZrPahgBl8clX0MwdRo77tLZKJLwmBR7hbEh2.BP OSY.WuFpQvh88NgRXjf93wOIavh4hB5NFBgvyafipRtGt9RhLsinyhVdD9GHdAasZrmZ.V05aR7Z EQHGSDnLEPQAR9mpDcojWe_3w_G5FKBqgUWsVzFQLyJ0Ao_x3i_jgOfy2vYdi02tfeAMqH1GGCMO HABcmbFeZLOI-
X-Sonic-MF: <nadalin@prodigy.net>
X-Sonic-ID: 0aad2c2d-b91a-46e7-b940-80d587f67252
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 Feb 2024 01:34:17 +0000
Received: by hermes--production-gq1-5c57879fdf-llxbt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1e143740d26c681611cc97e36e1a7281; Tue, 20 Feb 2024 01:34:14 +0000 (UTC)
From: nadalin@prodigy.net
To: 'Orie Steele' <orie@transmute.industries>
Cc: 'Roman Danyliw' <rdd@cert.org>, 'oauth' <oauth@ietf.org>
References: <BN2P110MB110725C85B7253C421DDFE71DC4BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <BN2P110MB1107C4999047DB10B00E71ECDC4BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAK2Cwb4okK1T67-4KyZTKBc846wcP7MVizZ2QYgJJFAcUcPz9w@mail.gmail.com> <07e701da6046$40e704b0$c2b50e10$@prodigy.net> <CAN8C-_JjmwhT3+347WybBV4J0f0ki0XH7GzYrMxozDxk25cVzQ@mail.gmail.com>
In-Reply-To: <CAN8C-_JjmwhT3+347WybBV4J0f0ki0XH7GzYrMxozDxk25cVzQ@mail.gmail.com>
Date: Mon, 19 Feb 2024 17:34:10 -0800
Message-ID: <175f01da639c$e7c77ef0$b7567cd0$@prodigy.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1760_01DA6359.D9A55060"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIOsEhqi/t9H2NGLATiCNmpI1/XrAGrwh8gAlXIWE0CqE+0SQFmikdosGlTE2A=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ppCmfd4yid15tueHNBKUqIOsxVg>
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: Tue, 20 Feb 2024 01:34:21 -0000

Orie, thanks for the response

 

I’m still confused on this charter proposal as I read this charter it is to create architecture, patterns and definitions for electronic credentials. The charter should be free of any technology including W3C, if people want clarity about what an electronic credential is then they can help out with the definitions since that is an output, so I don’t agree with how W3C is mentioned in the charter. The way I read the charter is that interested parties will work on various profiles to map/profile various technologies to the create architecture, patterns and definitions documents, this will be done with various members that submit drafts.

 

Relative to WebAuthn what is produced is a credential, its not a JWT or SD-JWT but as the charter reads that is not the only credentials under consideration, if this is the case then the charter severely lacks clarity on what is the goal.

 

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO with no issues, I assume profile will be created by various members that submit drafts, if no one is interested in mDL/ISO then that’s fine.

 

I still think this charter needs more clarity as I point out

 

 

From: Orie Steele <orie@transmute.industries> 
Sent: Friday, February 16, 2024 10:11 AM
To: nadalin@prodigy.net
Cc: Roman Danyliw <rdd@cert.org>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

 

Hey Tony,

 

On Thu, Feb 15, 2024 at 1:36 PM <nadalin@prodigy.net <mailto: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 <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries <http://www.transmute.industries> 

 <https://transmute.industries/>