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

[Michael Prorock <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
>> *Sent:* Monday, February 19, 2024 6:15 PM
>> *To:* Anthony Nadalin <[e-mail]>
>> *Cc:* Roman Danyliw <[e-mail]>; oauth <[e-mail]>
>> *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
>>
>>
>>
>> Inline:
>>
>> On Mon, Feb 19, 2024, 7:34 PM <[e-mail]> 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 <[e-mail]>
>> *Sent:* Friday, February 16, 2024 10:11 AM
>> *To:* [e-mail]
>> *Cc:* Roman Danyliw <[e-mail]>; oauth <[e-mail]>
>> *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
>>
>>
>>
>> Hey Tony,
>>
>>
>>
>> On Thu, Feb 15, 2024 at 1:36 PM <[e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>