From orie@transmute.industries Tue Feb 20 10:18:28 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 80141C180B50 for ; Tue, 20 Feb 2024 10:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_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 k5-_AYonYm7h for ; Tue, 20 Feb 2024 10:18:24 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4D669C180B51 for ; Tue, 20 Feb 2024 10:18:24 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-29954681b59so1900739a91.2 for ; Tue, 20 Feb 2024 10:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1708453103; x=1709057903; 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=xaTiU/ganzvoW5tfkPHaQEidjhVXraD0+uqCDm8Awn0=; b=Kk7qGXh4jIfzd9nw4uQPtFEaUEGsUlL9rhPlBGvJE65vWgXmDQ/JFiV2MlgFiabWzz wAJxDJVxd5aaiU5wTs/vGs6tnh/0zqkP9VGGB01ZzFth8uSKgLdXxNtqK9YiGwzApGx/ XFP8DYFzUFLdI096QZqrtaUN+JIwMjWSweWmVh+B9j5mnC9l121oKNQ6YYm8pTMwLhZc qnyKz/oxDr5mvrWlOfCRiCUcyjVhl4wzmrJnvsppINo4T+UwndgNlZ0z2yK0wetQMgMZ kZzvD5iBQV/ac810G12Gfdo29gZGvNaL/+BTWEfQJ+gUHWUQyhht8oEt7oKpscjd8Lhl f0MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708453103; x=1709057903; 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=xaTiU/ganzvoW5tfkPHaQEidjhVXraD0+uqCDm8Awn0=; b=tTxW1YJUKSLLkMhns1n2bG7oy2c01CeRttDM0RXsZkvDDbPJVTpFHAFBLF8WWHenep +RaPiCkImYD4L4B1P6su/GvsRqPJJvWGUuF1VSKJxa6nt92vSSFHIWHM1pfyIuB6vZed N89AYvifZaeTPJZtR+WK/mrObYNjWt0gf0ficKXRX//8cyjTuUYBOsIImkD0Wfmyp4ki yWU2gg8NW+5AVsGboC6PXbKRcnq29M2cjP9T0VOm51IC4I9bELrTMQLbh3trGyMULEJ9 4wENrPF70UZ9AoONy6z9o1LzyCSwMob4I/67APMSqvIHswTi0jo8GVQnebxYTia3qsff IS8A== X-Forwarded-Encrypted: i=1; AJvYcCXqnnCoPf5SzNpsA065ayDferInysVKdNi346vPWQ05K9apTNE3KW9VB2Sov1+vTIg76o32tjBpJl8zRPqXPQ== X-Gm-Message-State: AOJu0Yz2/RmZmEIPi25VVWz3pQ7JA6S9UdW9/OTAusTwSiaTcx35MvgO 0dHo0VELUGMsTTsucsV6IuRHX3Q12AwFrUOqg87KlDW77JO9OLvxEUU+8hc1EFtcT7NojEGhZPF DthHsrVwftknBOOoWuSVuhLd/4uM/PuICge2DzA== X-Google-Smtp-Source: AGHT+IFaefC5kuD5kZDyG/kiVuUejq5rq2bNWuFqROvjtfy5sc5tp+lQDwzDQnF0S/A2hzG1EVD/ieDtmZyXfEXyyqQ= X-Received: by 2002:a17:90a:5911:b0:299:4aad:6bb1 with SMTP id k17-20020a17090a591100b002994aad6bb1mr8097865pji.1.1708453103228; Tue, 20 Feb 2024 10:18:23 -0800 (PST) MIME-Version: 1.0 References: <07e701da6046$40e704b0$c2b50e10$@prodigy.net> <175f01da639c$e7c77ef0$b7567cd0$@prodigy.net> <1b6601da641a$5f55b270$1e011750$@prodigy.net> In-Reply-To: <1b6601da641a$5f55b270$1e011750$@prodigy.net> From: Orie Steele Date: Tue, 20 Feb 2024 12:18:11 -0600 Message-ID: To: nadalin@prodigy.net Cc: Roman Danyliw , oauth Content-Type: multipart/alternative; boundary="0000000000005570fc0611d43ce7" 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 18:18:28 -0000 --0000000000005570fc0611d43ce7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for making this so clear, and easy to review. I'd like to unpack some of the intention behind the "metadata discovery" deliverable, and hopefully this commentary will help others chime in, on if it should be cut from scope. The original intention was to generalize this capability from the OAuth draft, to work with formats other than SD-JWT, what follows are excerpts from https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/: > This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT. The JWT Issuer is identified by the iss claim in the JWT. Use of the JWT Issuer Metadata is OPTIONAL. > JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer Metadata configuration available at the path formed by concatenating the string /.well-known/jwt-issuer to the iss claim value in the JWT. The iss MUST be a case-sensitive URL using the HTTPS scheme that contains scheme, host and, optionally, port number and path components, but no query or fragment components. > A JWT Issuer Metadata configuration MUST be queried using an HTTP GET request at the path defined in Section 4. > The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when iss is set to https://example.com: > GET /.well-known/jwt-issuer HTTP/1.1 > Host: example.com > If the iss value contains a path component, any terminating / MUST be removed before inserting /.well-known/ and the well-known URI suffix between the host component and the path component. > The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when iss is set to https://example.com/user/1234: > GET /.well-known/jwt-issuer/user/1234 HTTP/1.1 > Host: example.com > A successful response MUST use the 200 OK HTTP and return the JWT Issuer Metadata configuration using the application/json content type. > An error response uses the applicable HTTP status code value. """ { "issuer":"https://example.com", "jwks":{ "keys":[ { "kid":"doc-signer-05-25-2022", "e":"AQAB", "n":"nj3YJwsLUFl...5z50wMuzifQrMI9bQ", "kty":"RSA" } ] } } """ The problem I see with removing a general purpose deliverable for this, is that we will see this kind of "key discovery stuff" repeated over and over again, as it is in SD-JWT-VC, possibly with minor or major differences that impact interoperability, and make it difficult for an issuer to upgrade from supporting SD-JWT to SD-CWT or CWP or go the other direction (there are good reasons the believe a vendor might want to support multiple credential formats). My preference would be to define this "metadata discovery thing" in one place, and then refer to it like this in digital credential documents: "Key discovery is out of scope for this document, there are several mechanisms for distributing or discovering key material, see $ref1, $ref2, etc." Other documents might take a different approach: $ref is mandatory to support, other mechanisms for distributing or discovering key material are optional, see $ref2, etc... As you may be aware, DIDs are a mechanism for distributing key material, but for which resolution is not concretely defined, this has caused them to be very difficult to use, and it produced formal objects to their publication in W3C. https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html OIDC also supports discovering issuer key material, through well known endpoints. Moving key material discovery out of scope for IETF deliverables is often a reasonable approach, but it is problematic if it is done for CWTs and JWTs differently. The objective of the "metadata discovery document" was to ensure that SD-CWT and SD-CWP could reference a document that did what SD-JWT-VC is doing, without repeating the text that it currently includes. It might even be possible for SD-JWT-VC to share that metadata discovery document as a normative reference, and then interoperability and reuse could be achieved across JWT,CWT, SD-JWT,SD-CWT,CWP and JWP digital credential profiles. However, if this feels like biting off too much for a new working group charter, I would not be opposed to defering it to a potential rechartering discussion, its possible OAUTH, or WIMSE will have solved the problem for the formats above by then anyway. Regards, OS On Tue, Feb 20, 2024 at 10:32=E2=80=AFAM wrote: > Introduction > > Digital credentials are essential to identity, authorization, licenses, > certificates, and digitization use cases that are part of modernization > efforts targeting efficiency and transparency. > > A digital credential expresses claims or attributes about a subject, such > as their name or age, and their cryptographic keys. Some sets of claim > names have already been defined by the IETF and other standards developme= nt > groups (e.g., OpenID Foundation). > > Digital credentials typically involve at least three entities but can > include more: > > - An "issuer", an entity (person, device, organization, or software > agent) that constructs and secures digital credentials. > - A "holder", an entity (person, device, organization, or software > agent) that controls the disclosure of credentials. > - A "verifier", an entity (person, device, organization, or software > agent) that verifies and validates secured digital credentials. > > In some contexts, holders may be willing either to partially disclose som= e > values of their attributes or to demonstrate some properties about their > attributes without disclosing their values. When disclosed by an entity, = a > proof of the digital credential needs to be provided and verified, so tha= t > only the legitimate holder of the digital credential can take advantage o= f > its possession. > > Some holders may wish to carry more than one digital credential. These > credentials, together with associated key material, can be stored in an > identity digital wallet. > > The W3C has published the 'Verifiable Credentials Data Model v2.0' > specification (VCDM) with data serialization in JSON-LD. In this charter, > the VCDM defined concept of =E2=80=9Cverifiable credential=E2=80=9D and = =E2=80=9Cverifiable > presentation=E2=80=9D is captured using the wording "digital credential" = and > "digital presentation" respectively. > > Goal > > The SPICE WG will profile existing IETF technologies and address residual > gaps that would enable their use in digital credentials and presentations > based upon JWT and CWT technologies. > > - The JOSE WG is already standardizing a token format for > unlinkability & selective disclosure in the form of JWP/CWP ( > draft-ietf-jose-json-web-proof > ). > The SPICE WG will profile these token formats for use with digital > credentials. > - The OAUTH WG is already standardizing a token format for > unlinkability & selective disclosure in the form of SD-JWT/SD-JWT-VC ( > draft-ietf-oauth-selective-disclosure-jwt > > and draft-ietf-oauth-sd-jwt-vc > ). The > SPICE WG will define SD-CWT/SD-CWT-VC, analogs for these JWT-based tok= ens > but based on CWT. > > The SPICE WG will coordinate with the RATS, OAuth, JOSE, COSE and SCITT > working groups that develop architecture, patterns and definition documen= ts > related to the identity and credential space. The SPICE WG will build on > cryptographic primitives defined in the CFRG (e.g., BBS Signatures) and > will not define novel cryptographic schemes. > > The SPICE WG will not develop digital credentials for any particular use > case. The SPICE WG will create general-purpose profiles which will enable > credential issuers, holders and verifiers to easily build on existing IET= F > CWT and JWT technologies. > > Program of Work > > The SPICE WG is expected to develop: > > - An informational Architecture that defines the terminology (e.g., > Issuer, Holder,Verifier, Claims, Credentials, Presentations) and the > essential communication patterns between roles, such as credential > issuance, where an issuer delivers a credential to a holder, and > presentation, where a holder delivers a presentation to a verifier. > - Proposed standard documents for digital credential profiles covering > JWP and CWP (from JOSE) that enable digital credentials with unlinkabi= lity > and selective disclosure. This work will include registering claims th= at > are in the JWT and CWT registries to enable digital credentials to > transition from one security format to another (i.e., JSON/CBOR). > - A proposed standard document defining SD-CWT, a profile of CWT > inspired by SD-JWT (from OAuth) that enables digital credentials with > unlinkability and selective disclosure. > - A proposed standard Metadata Discovery protocol using HTTPS/CoAP for > CBOR-based digital credentials to enable the 3 roles (issuers, holders= and > verifiers) to discover supported protocols and formats for keys, claim= s, > credential types and proofs. The design will be inspired by the OAuth > "vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc > ) which > supports ecosystems using JSON serialization. > > Milestones > > - 04-2025 - Submit an informational Architecture document to the IESG > for publication > - 10-2025 - Submit a proposed standard document covering a JWP/CWP > profile for digital credentials to the IESG for publication > - 10-2025 - Submit a proposed standard document defining SD-CWT to the > IESG for publication > - 03-2026 - Submit a document as a proposed standard covering Metadata > Discovery to the IESG for publication > > Introduction > > > Goal > > Program of Work > > > Milestones > > > > > > > > > > > *From:* Orie Steele > *Sent:* Monday, February 19, 2024 6:15 PM > *To:* Anthony Nadalin > *Cc:* Roman Danyliw ; oauth > *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter > > > > 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 signe= d > 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 V= Cs > 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 variou= s > 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 > > > > --=20 ORIE STEELE Chief Technology Officer www.transmute.industries --0000000000005570fc0611d43ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for making this so clear, and easy to review.
I'd like to unpack some of the intention behind=C2=A0the "met= adata discovery" deliverable, and hopefully this commentary will help = others chime in, on if it should be cut from scope.

The original=C2= =A0intention was to generalize this capability from the OAuth draft, to wor= k with formats other than SD-JWT, what follows are excerpts from https://data= tracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/:

> This spec= ification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metada= ta configuration of the JWT Issuer of the JWT. The JWT Issuer is identified= by the iss claim in the JWT. Use of the JWT Issuer Metadata is OPTIONAL.
> JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issue= r Metadata configuration available at the path formed by concatenating the = string /.well-known/jwt-issuer to the iss claim value in the JWT. The iss M= UST be a case-sensitive URL using the HTTPS scheme that contains scheme, ho= st and, optionally, port number and path components, but no query or fragme= nt components.

> A JWT Issuer Metadata configuration MUST be quer= ied using an HTTP GET request at the path defined in Section 4.

>= The following is a non-normative example of a HTTP request for the JWT Iss= uer Metadata configuration when iss is set to https://example.com:

> GET /.well-known/jwt-issuer HTTP/1.= 1
> Host: example.com
> If t= he iss value contains a path component, any terminating / MUST be removed b= efore inserting /.well-known/ and the well-known URI suffix between the hos= t component and the path component.

> The following is a non-norm= ative example of a HTTP request for the JWT Issuer Metadata configuration w= hen iss is set to https://example= .com/user/1234:

> GET /.well-known/jwt-issuer/user/1234 HTTP/= 1.1
> Host: example.com

>= ; A successful response MUST use the 200 OK HTTP and return the JWT Issuer = Metadata configuration using the application/json content type.
> An = error response uses the applicable HTTP status code value.

"&qu= ot;"
{
=C2=A0 =C2=A0"issuer":"https://example.com",
=C2=A0 =C2=A0"jwks"= ;:{
=C2=A0 =C2=A0 =C2=A0 "keys":[
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "kid":&q= uot;doc-signer-05-25-2022",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "e":"AQAB",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "n":"nj3YJwsLUFl...5z50wMuzifQrMI9bQ",
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "kty":"RSA"
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0= }
}
"""

The problem I see with removing a gener= al purpose deliverable for this, is that we will see this kind of "key= discovery stuff" repeated over and over again, as it is in SD-JWT-VC,= possibly with minor or major differences that impact interoperability, and= make it difficult for an issuer to upgrade from supporting SD-JWT to SD-CW= T or CWP or go the other direction (there are good reasons the believe a ve= ndor might want to support multiple credential formats).

My preferen= ce would be to define this "metadata discovery thing" in one plac= e, and then refer to it like this in digital credential documents:

&= quot;Key discovery is out of scope for this document, there are several mec= hanisms for distributing or discovering key material, see $ref1, $ref2, etc= ."

Other documents might take a different approach:

$ref= is mandatory to support, other mechanisms for distributing or discovering = key material are optional, see $ref2, etc...

As you may be aware, DI= Ds are a mechanism for distributing key material, but for which resolution = is not concretely=C2=A0defined, this has caused them to be very difficult t= o use, and it produced formal objects to their publication in W3C.

<= a href=3D"https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000= .html">https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.ht= ml

OIDC also supports discovering issuer key material, through w= ell known endpoints.

Moving key material discovery out of scope for = IETF deliverables is often a reasonable approach, but it is problematic if = it is done for CWTs and JWTs differently.

The objective of the "= ;metadata discovery document" was to ensure that SD-CWT and SD-CWP cou= ld reference a document that did what SD-JWT-VC is doing, without repeating= the text that it currently includes.

It might even be possible for = SD-JWT-VC to share that metadata discovery document as a normative referenc= e, and then interoperability and reuse could be achieved across JWT,CWT, SD= -JWT,SD-CWT,CWP and JWP digital credential profiles.

However, if thi= s feels like biting off too much for a new working group charter, I would n= ot be opposed=C2=A0to defering=C2=A0it to a potential rechartering discussi= on, its possible OAUTH, or WIMSE will have solved the problem for the forma= ts above by then anyway.

Regards,

OS





<= br>



On Tue, Feb 20, 2024 at 10:32=E2=80=AFAM <nadalin@prodigy.net> wrote:

Introduction

D= igital credentials are essential to identity, authorization, licenses, cert= ificates, and digitization use cases that are part of modernization efforts= targeting efficiency and transparency.

A digital credential expresses claims or attributes about = a subject, such as their name or age, and their cryptographic keys. Some se= ts of claim names have already been defined by the IETF and other standards= development groups (e.g., OpenID Foundation).

Digital credentials typically involve at least thre= e entities but can include more:

    =
  • An "issuer", an entity (pe= rson, device, organization, or software agent) that constructs and secures = digital credentials.
  • A "holder", an entity (person, device, organization, or= software agent) that controls the disclosure of credentials.=
  • A "verifier", = an entity (person, device, organization, or software agent) that verifies a= nd validates secured digital credentials.

In some contexts, holders may be willing either to= partially disclose some values of their attributes or to demonstrate some = properties about their attributes without disclosing their values. When dis= closed by an entity, a proof of the digital credential needs to be provided= and verified, so that only the legitimate holder of the digital credential= can take advantage of its possession.

Some holders may wish to carry more than one digital creden= tial. These credentials, together with associated key material, can be stor= ed in an identity digital wallet.

The W3C has published the 'Verifiable Credentials Data Mo= del v2.0' specification (VCDM) with data serialization in JSON-LD. In t= his charter, the VCDM defined concept of =E2=80=9Cverifiable credential=E2= =80=9D and =E2=80=9Cverifiable presentation=E2=80=9D is captured using the = wording "digital credential" and "digital presentation"= respectively.

Goal

= The SPICE WG will profile existing IETF technologies and address resid= ual gaps that would enable their use in digital credentials and presentatio= ns based upon JWT and CWT technologies.

The S= PICE WG will coordinate with the RATS, OAuth, JOSE, COSE and SCITT working = groups that develop architecture, patterns and definition documents related= to the identity and credential space. The SPICE WG will build on cryptogra= phic primitives defined in the CFRG (e.g., BBS Signatures) and will not def= ine novel cryptographic schemes.

The SPICE WG will not develop digital credentials for any part= icular use case. The SPICE WG will create general-purpose profiles whic= h will enable credential issuers, holders and verifiers to easily build on = existing IETF CWT and JWT technologies.

Program of Work

The SPICE WG is expected to develop:=

  • An informational Architecture that defines the terminolog= y (e.g., Issuer, Holder,Verifier, Claims, Credentials, Presentations) and t= he essential communication patterns between roles, such as credential issua= nce, where an issuer delivers a credential to a holder, and presentation, w= here a holder delivers a presentation to a verifier.
  • Proposed standard documents for d= igital credential profiles covering JWP and CWP (from JOSE) that enable dig= ital credentials with unlinkability and selective disclosure. This work wil= l include registering claims that are in the JWT and CWT registries to enab= le digital credentials to transition from one security format to another (i= .e., JSON/CBOR).
  • A proposed standard document defining SD-CWT, a profile of CWT inspir= ed by SD-JWT (from OAuth) that enables digital credentials with unlinkabili= ty and selective disclosure.
  • A proposed standard Metadata Discovery protocol using = HTTPS/CoAP for CBOR-based digital credentials to enable the 3 roles (issuer= s, holders and verifiers) to discover supported protocols and formats for k= eys, claims, credential types and proofs. The design will be inspired by th= e OAuth "vc-jwt-issuer" metadata work (draft-ietf= -oauth-sd-jwt-vc) which supports ecosystems using JSON serialization.

Milestones

  • 04-2025 - Submit an informational Architecture document t= o the IESG for publication
  • 10-2025 - Submit a proposed standard document covering a JW= P/CWP profile for digital credentials to the IESG for publication=
  • 10-2025 - Submit a p= roposed standard document defining SD-CWT to the IESG for publication
  • <= span style=3D"font-family:"Segoe UI",sans-serif">03-2026 - Submit= a document as a proposed standard covering Metadata Discovery to the IESG = for publication

Introduction

Goal

Pr= ogram of Work

Milestones

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Orie Steele <orie@transmute.industries>=
Sent: Monday, February 19, 2024 6:15 PM
To: Anthony N= adalin <nadalin= @prodigy.net>
Cc: Roman Danyliw <rdd@cert.org>; oauth <oauth@ietf.org>
Subject:<= /b> Re: [OAUTH-WG] FW: Call for consensus on SPICE charter

=C2=A0

Inline:

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

Orie, thanks for the response

=C2=A0

I=E2= =80=99m still confused on this charter proposal as I read this charter it i= s to create architecture, patterns and definitions for electronic cr= edentials. The charter should be free of any technology including W3C, if p= eople want clarity about what an electronic credential is then they can hel= p out with the definitions since that is an output, so I don=E2=80=99t agre= e with how W3C is mentioned in the charter.

<= /blockquote>

=C2=A0

As you pointed out below, W3C has define= d credentials that are simply public keys bound to an origin (used as authe= nticators), and issuer signed claims about a subject (like JWTs)<= /u>

=C2=A0

So far the people who have been most active seem in= terested in generalizing the "signed public key and attributes" v= ersion of a digital credential. That definition lines up well with JWT and = CWT with the cnf claim, and mDoc (as I understand it).

=C2=A0

Most of the value W3C VC Data Model provides is focused on c= reating 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 fr= om W3C.

=C2=A0=

Some of the protocol connection p= oints also come from IETF documents, for example aud, nonce and cnf.=

=C2=A0

=

Most of the value JWT and CWT provide, is throu= gh 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 c= redentials is registered.

=C2=A0

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

=C2=A0

Creating conventions for claims in a credential f= ormat is profiling. iso mdoc is a profile of COSE Sign1 in that sense.

=C2=A0

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.

=C2=A0

A major reason for spice forming was to explore alternative claims struc= tures, and to align CWT and JWT conventions for credentials that DO NOT req= uire JSON-LD.

=C2= =A0

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 do= cuments, this will be done with various members that submit drafts.<= u>

=C2=A0

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

=C2=A0

I don't think there is utility in IETF creating a profile for = webauthn based credentials, because they are not meant to be presented beyo= nd the origin they are bound to.

=C2=A0

=C2=A0

ISO is just another standards org, W3C, OIDF, OASIS, etc work with ISO wi= th no issues, I assume profile will be created by various members that subm= it drafts, if no one is interested in mDL/ISO then that=E2=80=99s fine.<= /u>

=C2=A0

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

=C2=A0

Can you suggest= text?

=C2=A0

=C2=A0

From: Orie Steele <orie@transmute.industr= ies>
Sent: Friday, February 16, 2024 10:11 AM
To: nadalin@prodigy= .net
Cc: Roman Danyliw <rdd@cert.org>; oauth <oauth@ietf.org>
Subject: Re: [OAU= TH-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&g= t; wrote:

1) Do = you support the charter text? Or do you have objections or blocking concern= s (please describe what they might be and how you would propose addressing = the concern)?

Not sure I support at this point, I understand the nee= d 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 m= DL work in ISO that already has patterns and definitions along with credent= ial formats (mdoc)=C2=A0 and transports (ble/http/nfc). I don=E2=80=99t bel= ieve the IETF should ignore these efforts since most of the driving licence= and passport communities/companies are adopting this as one of the standar= ds that issuers and verifiers will use. The same is true for W3C WebAuthn.<= u>


WebAuthN cannot produce standard digital=C2=A0signatures, a= nd so it cannot be used to produce standard digital credentials (for exampl= e it cannot be used to produce JWT or SD-JWT).
It could produce authenti= cations for public keys that could be bound to credentials, but because of = the origin binding in WebAuthN, this would not fit well with the "audi= ence" typically used for digital credentials (usually there is no audi= ence)

You might find this thread on possible relation between mDoc a= nd CWT interesting:

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

<= /div>


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 believe that the WG if formed should also th= ink about holder verification and patterns and attestations that can be use= d.

=C2=A0<= u>

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

=C2=A0

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


This sounds like an applicati= on to me.
How do you see this related to "credential formats" = or "issuer/holder/verifier metadata"?
=C2=A0

=



There are other models th= an the 3 party that VCs use, so these also need to be considered in the arc= hitecture,=C2=A0 patterns and definitions documents to enable profiles for = other technologies.


Agreed, OAuth JWTs/SD-JWTs, and ISO mDo= cs are examples we have discussed.
Are there others you would like to se= e 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 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 b= e better done in W3C as this does not seem to fit well with the charter<= /u>


Discovering atte= stations for wallets seems to fit here, why should URLs or URNs (DIDs) be s= pecifically marked as out of scope?

For consideration, JWK / COSE Ke= y Thumbprints are good alternatives to DIDs which have been standardized / = 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 par= ties will have to contribute if they want to have other technologies includ= ed but the charter in general does not seem to allow this, so removing spec= ific technology will allow this to happen.

=C2=A0

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



I would be happy to give provi= de specific text changes to the charter.


I think it would be great if you could offer te= xt that refines your comment about format support, and holder/wallet metada= ta / attestations.
=C2=A0



2) If you do support th= e charter text:


3) Are you willing to author or participate in t= he 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 th= ese outputs with the other industry technologies.


Thank you for your comments.
=C2=A0=



_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth


=C2=A0

-- <= /span>

=C2=A0

ORIE STEELE
<= /span>Chief Technology Officer
www.transmute.industries

<= /div>

--


ORIE STEELE
Chief Technology Officer
www.transmute.industries


--0000000000005570fc0611d43ce7--