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

[Orie Steele <[e-mail]>]

I support making the above changes to the charter.

OS

On Tue, Feb 20, 2024 at 6:59 PM <[e-mail]> 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 <[e-mail]>
> *Sent:* Tuesday, February 20, 2024 10:18 AM
> *To:* [e-mail]
> *Cc:* Roman Danyliw <[e-mail]>; oauth <[e-mail]>
> *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 <[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/>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>