I support making the above changes to the charter. OS
On Tue, Feb 20, 2024 at 6:59 PM <nada...@prodigy.net> wrote: > Orie, many thanks for the dump on metadata, I understand now the motive. > > If we keep it simple and just say a metadata Discover proposal for > specific technologies there can be different proposals or the WG can make > the call on which one is the one that they want to work on. We can also > have an OUT OF SCOPE section and specifically say that general key > discovery is out of scope. I don’t think this is too much work as > everything does not have to be done at once. > > - A standard Metadata Discovery protocol for JWT,CWT, > SD-JWT,SD-CWT,CWP and JWP technologies. > > > > - Out of Scope > - General Key discovery is out of scope for this document, there > are several mechanisms for distributing or discovering key material > (references go here), > > > > *From:* Orie Steele <orie@transmute.industries> > *Sent:* Tuesday, February 20, 2024 10:18 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 > > > > 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/> > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth