Orie, that is a very helpful write up. I believe that the "metadata discovery document" is something related to a key use case that pops up over and over again, and that we should keep it in scope.
Mike Prorock CTO, Founder https://mesur.io/ On Tue, Feb 20, 2024 at 11:18 AM Orie Steele <orie@transmute.industries> wrote: > 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 AM <nada...@prodigy.net> 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 development >> 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 >> some 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 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 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 “verifiable credential” and “verifiable >> presentation” 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 >> <https://datatracker.ietf.org/doc/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 >> >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/> >> and draft-ietf-oauth-sd-jwt-vc >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>). The >> SPICE WG will define SD-CWT/SD-CWT-VC, analogs for these JWT-based tokens >> 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 documents >> 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 IETF 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 >> unlinkability and selective disclosure. This work will include registering >> claims that 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, >> claims, credential types and proofs. The design will be inspired by the >> OAuth "vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc >> <https://datatracker.ietf.org/doc/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 >> <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#introduction> >> >> Goal <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#goal> >> >> Program of Work >> <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#program-of-work> >> >> Milestones >> <https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#milestones> >> >> >> >> >> >> >> >> >> >> *From:* Orie Steele <orie@transmute.industries> >> *Sent:* Monday, February 19, 2024 6:15 PM >> *To:* Anthony Nadalin <nada...@prodigy.net> >> *Cc:* Roman Danyliw <r...@cert.org>; oauth <oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter >> >> >> >> Inline: >> >> On Mon, Feb 19, 2024, 7:34 PM <nada...@prodigy.net> wrote: >> >> 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. >> >> >> >> 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 clarity >> 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’s fine. >> >> >> >> I still think this charter needs more clarity as I point out >> >> >> >> Can you suggest text? >> >> >> >> >> >> *From:* Orie Steele <orie@transmute.industries> >> *Sent:* Friday, February 16, 2024 10:11 AM >> *To:* nada...@prodigy.net >> *Cc:* Roman Danyliw <r...@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 <nada...@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/> >> >> > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
