From orie@transmute.industries Mon Feb 19 18:14:59 2024 Return-Path: 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 22CE0C14CF13 for ; Mon, 19 Feb 2024 18:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_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 hraOnkF9YjPj for ; Mon, 19 Feb 2024 18:14:55 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 76395C14CEFF for ; Mon, 19 Feb 2024 18:14:55 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-5ce6b5e3c4eso2616506a12.2 for ; Mon, 19 Feb 2024 18:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1708395295; x=1709000095; 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=iwT1hDvOYmQd2i0ZCfirQ8LE9nZhWYCYWI8sWGrKB/4=; b=jZ4WWgRx86ouIgUEgRCBn1olm9bONlEuzXkQytIZle4z+ZvYc7+X1ZA4v6xAsM1E7T 3GxKak8Dfm5D6FgY0yno/9fD07yR+jSoGIMoszMH8o8MEVgyD7o5KWxm0y55P7YZKTYu Stv9/8D3XTyZislZglvrmxcnGXO+6WMVBQ9CKQl3llmhiEfu6nNQv5VotjvTlJrNCkm+ 7Y4sDPDfrE23HXAlYw7IVeOw7nBcqvSr8xfHyH+/3jEA46p2VbMWZlTLaPsEOU6zTR85 lOBB+0K1QQjSaRJDLhQdr6+ohKGhZNdd7M4lnnr6/dJ8HqPa3N+gRMK785xm+qlTgLLM wwXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708395295; x=1709000095; 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=iwT1hDvOYmQd2i0ZCfirQ8LE9nZhWYCYWI8sWGrKB/4=; b=FgzNUiho33fNixyhC8osimjUXj8xMmL88tsoivZPmoRyOaac0ARbo87N9QTI6kQk2x Sfp85IvRplOE++/hpIaUr4zisESOv7vBJoDAsAXROZ3cKYW0TOi0rgjjdW9NsJ8zHfSt G51/eNF9x64XF0PjanC8nqQr7fluKT5SG2MIt2AxP0tXak534DmdUZiNNoiEnGxdv4dB 8S2g/WfIg2LF4gS/q29oi8ZplFYIgbCa97LeG5lZ8pmL/A/PXNtt6bl5wuRILXembuWJ EGjSCbs5M3Vlf+nTPrlFHN5+H8QjHob6rnhbgJC+/LZ4v9tMa7XKsT7ZYsRXEzYHVE7W +yfw== X-Forwarded-Encrypted: i=1; AJvYcCUF9C9dOtCCFTpTbhAkrIMC9GbO0Fh7fphYWaSvbnb0OzyJC0uoRjSgoNBNAWQPiEaf6u3tNkizb9xsNt8a5Q== X-Gm-Message-State: AOJu0Yy89fwtArt6fScnDsPkV7Y/PIeueP0W7lgcTdPR0BAKWzi7mqWN 7dUXBv/2iznVS9bv/PUP/czAa8yzDqkiy1cU2TRHKHhWsaFFoSf6yj8FhySNIcxo0yE5/ckPrP4 zRBVpq93L6gvVugmiXl1QU1HdyrqNUGHbmFHXAw== X-Google-Smtp-Source: AGHT+IFZW6FruGRWgUnEnWgAt0eKVWMnEW08mYez9IrjWEE6sQLqHzCWhvwPa8eEIwGkrSuQauWJhm9R90dKs0Z0cZo= X-Received: by 2002:a05:6a21:8ccc:b0:19c:881d:78e6 with SMTP id ta12-20020a056a218ccc00b0019c881d78e6mr13862218pzb.42.1708395294652; Mon, 19 Feb 2024 18:14:54 -0800 (PST) MIME-Version: 1.0 References: <07e701da6046$40e704b0$c2b50e10$@prodigy.net> <175f01da639c$e7c77ef0$b7567cd0$@prodigy.net> In-Reply-To: <175f01da639c$e7c77ef0$b7567cd0$@prodigy.net> From: Orie Steele Date: Mon, 19 Feb 2024 20:14:41 -0600 Message-ID: To: Anthony Nadalin Cc: Roman Danyliw , oauth Content-Type: multipart/alternative; boundary="000000000000ac8d950611c6c6bf" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2024 02:14:59 -0000 --000000000000ac8d950611c6c6bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inline: On Mon, Feb 19, 2024, 7:34=E2=80=AFPM wrote: > Orie, thanks for the response > > > > I=E2=80=99m still confused on this charter proposal as I read this charte= r 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=E2=80=99t= agree > with how W3C is mentioned in the charter. > As you pointed out below, W3C has defined credentials that are simply public keys bound to an origin (used as authenticators), and issuer signed claims about a subject (like JWTs) So far the people who have been most active seem interested in generalizing the "signed public key and attributes" version of a digital credential. That definition lines up well with JWT and CWT with the cnf claim, and mDoc (as I understand it). Most of the value W3C VC Data Model provides is focused on creating a structure for the claims that go in the credential. The security of W3C VCs based on JWT, SD-JWT, and COSE comes from the IETF drafts not from W3C. Some of the protocol connection points also come from IETF documents, for example aud, nonce and cnf. Most of the value JWT and CWT provide, is through the public claims and private claims in the associated IANA registries. For example, this is where the cnf claim that ties proof of possession to credentials is registered. It's my understanding that mdocs have a namespace approach to claims as well. Creating conventions for claims in a credential format is profiling. iso mdoc is a profile of COSE Sign1 in that sense. You can consider the W3C documents that rely on JWT, CWT and COSE as profiles of those IETF standards. Instead of using JWT or CWT claimsets, the W3C uses JSON-LD. A major reason for spice forming was to explore alternative claims structures, and to align CWT and JWT conventions for credentials that DO NOT require JSON-LD. 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 clarit= y > on what is the goal. > I don't think there is utility in IETF creating a profile for webauthn based credentials, because they are not meant to be presented beyond the origin they are bound to. > > 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=E2=80=99s fin= e. > > > > I still think this charter needs more clarity as I point out > Can you suggest text? > > > > > *From:* Orie Steele > *Sent:* Friday, February 16, 2024 10:11 AM > *To:* nadalin@prodigy.net > *Cc:* Roman Danyliw ; oauth > *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter > > > > Hey Tony, > > > > On Thu, Feb 15, 2024 at 1:36=E2=80=AFPM 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=E2=80=99t= believe > the IETF should ignore these efforts since most of the driving licence an= d > 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 us= ed > 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 no= t > 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 definitio= ns. > > > 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 tex= t. > > > > 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 thi= s > 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 W3= C > as this does not seem to fit well with the charter > > > Discovering attestations for wallets seems to fit here, why should URLs o= r > 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 > > =E2=80=A2 Are you willing to review the WG drafts? > > yes > > =E2=80=A2 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 > > > --000000000000ac8d950611c6c6bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline:

On Mon, Feb 19, 2024, 7:34=E2=80=AFPM <nadalin@prodigy.net> wrote:
=

Or= ie, thanks for the response

= =C2=A0

I=E2=80=99m still confused on = this charter proposal as I read this charter it is to create architecture, = patterns and definitions for electronic credentials. The charter sho= uld be free of any technology including W3C, if people want clarity about w= hat an electronic credential is then they can help out with the definitions= since that is an output, so I don=E2=80=99t agree with how W3C is mentione= d in the charter.


As you pointed out below, W3C has defined cre= dentials that are simply public keys bound to an origin (used as authentica= tors), and issuer signed claims about a subject (like JWTs)

So far the people who have been most = active seem interested in generalizing the "signed public key and attr= ibutes" version of a digital credential. That definition lines up well= with JWT and CWT with the cnf claim, and mDoc (as I understand it).
<= div dir=3D"auto">
Most of the value W3C VC Data = Model provides is focused on creating a structure for the claims that go in= the credential. The security of W3C VCs based on JWT, SD-JWT, and COSE com= es from the IETF drafts not from W3C.

Some of the protocol connection points also come from IETF do= cuments, for example aud, nonce and cnf.

<= div dir=3D"auto">Most of the value JWT and CWT provide, is through the publ= ic claims and private claims in the associated IANA registries. For example= , this is where the cnf claim that ties proof of possession to credentials = is registered.

It's = my understanding that mdocs have a namespace approach to claims as well.

Creating conventions for c= laims in a credential format is profiling. iso mdoc is a profile of COSE Si= gn1 in that sense.

You c= an consider the W3C documents that rely on JWT, CWT and COSE as profiles of= those IETF standards. Instead of using JWT or CWT claimsets, the W3C uses = JSON-LD.

A major reason = for spice forming was to explore alternative claims structures, and to alig= n CWT and JWT conventions for credentials that DO NOT require JSON-LD.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

The way I read the charter is that interes= ted parties will work on various profiles to map/profile various technologi= es to the create architecture, patt= erns and definitions documents, this will be done with various members that= submit drafts.

=C2=A0

Relative to WebAuthn what is produced is a cred= ential, its not a JWT or SD-JWT but as the charter reads that is not the on= ly credentials under consideration, if this is the case then the charter se= verely lacks clarity on what is the goal.


I don't think ther= e is utility in IETF creating a profile for webauthn based credentials, bec= ause they are not meant to be presented beyond the origin they are bound to= .

=C2=A0

ISO is just another sta= ndards org, W3C, OIDF, OASIS, etc work with ISO with no issues, I assume pr= ofile will be created by various members that submit drafts, if no one is i= nterested in mDL/ISO then that=E2=80=99s fine.

=C2=A0

I still think th= is charter needs more clarity as I point out


Can you suggest tex= t?

=C2=A0<= /u>

=C2= =A0

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

=C2=A0

=

Hey Tony,

=C2=A0

On Thu, Feb 15= , 2024 at 1:36=E2= =80=AFPM <nadalin@prodigy.net> wrote:

1) Do you support the charter text? Or do you have objections or blocki= ng concerns (please describe what they might be and how you would propose a= ddressing the concern)?

Not sure I support at this point, I understa= nd 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 suc= h as the mDL work in ISO that already has patterns and definitions along wi= th credential formats (mdoc)=C2=A0 and transports (ble/http/nfc). I don=E2= =80=99t believe the IETF should ignore these efforts since most of the driv= ing 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=C2= =A0signatures, and so it cannot be used to produce standard digital credent= ials (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 wit= h the "audience" typically used for digital credentials (usually = there is no audience)

You might find this thread on possible relatio= n between mDoc and CWT interesting:

https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qe= ntlGg1Snjw1A/


The architecture, patterns and= definitions should be free from technology, I don't know why W3C is me= ntioned in the introduction as the only technology, this should not be in t= he introduction but along with other technologies such as mDL/mdoc, webauth= n, etc when describing profiles. As the goal would be for interested partie= s to produce profiles of other technologies to fit the architecture documen= t with patterns and definitions.


W3C is mentioned because some W3C members asked for a t= erm other than "Verifiable Credentials" to be used... and they as= serted the "Verifiable Credentials" implies the JSON-LD data mode= l developed in W3C.

ISO was not emphasized because formal coordinati= on would require contribution from ISO experts, and we have had relatively = low engagement=C2=A0from them.
=C2=A0


I belie= ve that the WG if formed should also think about holder verification and pa= tterns and attestations that can be used.

=C2=A0

Interesting. I think this is covered under the metadata discovery d= eliverable, but if you feel it could be made more clear, please send text.<= u>

=C2=A0

=

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


This sounds like an applic= ation to me.
How do you see this related to "credential formats&quo= t; or "issuer/holder/verifier metadata"?
=C2=A0<= /p>



There are other models than the 3 party that VCs use, so t= hese also need to be considered in the architecture,=C2=A0 patterns and def= initions documents to enable profiles for other technologies.=


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



I believe in the 1st 3 items in Goals but=C2=A0 I= don't believe it would be in the best interest to define a metatdata p= rotocol, as this sounds like this would be a protocol for obtaining DID doc= uments, 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 th= at may be better done in W3C as this does not seem to fit well with the cha= rter


Discover= ing attestations for wallets seems to fit here, why should URLs or URNs (DI= Ds) be specifically marked as out of scope?

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

-=C2=A0https://datatracker.ietf.org/doc/draft-ietf-cose-key-= thumbprint/
=C2=A0


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 th= e charter in general does not seem to allow this, so removing specific tech= nology will allow this to happen.

=C2=A0

= We chose to use "Digital Credential" and "Digital Presentati= on" specifically to keep the door open to CWT and COSE Sign1 structure= s which are used in IETF and ISO.
=C2=A0



= 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 sup= port, and holder/wallet metadata / attestations.
=C2=A0



2) If you do support the char= ter text:


3) Are you willing to author or participate in the dev= eloped of the WG drafts?

yes

=E2=80=A2 Are you willing to rev= iew the WG drafts?

yes

=E2=80=A2 Are you interested in implem= enting the WG drafts?

I'm willing to see how we can use these ou= tputs with the other industry technologies.

<= div>


Thank you for your comments.
=C2=A0



_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth


=C2=A0

--

<= div>

=C2=A0

ORIE STEELE
Chief Technology Officer
www.transmute.indust= ries

<= /u>

<= /div> --000000000000ac8d950611c6c6bf--