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

[Henk Birkholz <[e-mail]>]

Hello OAUTH list,

I assume I understand what you just were supporting Orie, but could you 
please phrase that in OLD vs. NEW email notation here on the list?


Viele Grüße,

Henk

p.s. I typically do not post here, but this discussion was confined to oauth

On 21.02.24 14:50, Orie Steele wrote:
> I support making the above changes to the charter.
> 
> OS
> 
> On Tue, Feb 20, 2024 at 6:59 PM <[e-mail] 
> <mailto:[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____
>           o 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] <mailto:[e-mail]>
>     *Cc:* Roman Danyliw <[e-mail] <mailto:[e-mail]>>; oauth
>     <[e-mail] <mailto:[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/
>     <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 <https://example.com>:
> 
>      > GET /.well-known/jwt-issuer HTTP/1.1
>      > Host: example.com <http://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 <https://example.com/user/1234>:
> 
>      > GET /.well-known/jwt-issuer/user/1234 HTTP/1.1
>      > Host: example.com <http://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 <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 <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]
>     <mailto:[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]
>         <mailto:[e-mail]>>
>         *Sent:* Monday, February 19, 2024 6:15 PM
>         *To:* Anthony Nadalin <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* Roman Danyliw <[e-mail] <mailto:[e-mail]>>; oauth
>         <[e-mail] <mailto:[e-mail]>>
>         *Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE
>         charter____
> 
>         ____
> 
>         Inline:____
> 
>         On Mon, Feb 19, 2024, 7:34 PM <[e-mail]
>         <mailto:[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]
>             <mailto:[e-mail]>>
>             *Sent:* Friday, February 16, 2024 10:11 AM
>             *To:* [e-mail] <mailto:[e-mail]>
>             *Cc:* Roman Danyliw <[e-mail] <mailto:[e-mail]>>;
>             oauth <[e-mail] <mailto:[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]
>             <mailto:[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/ <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/ <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] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/oauth
>                 <https://www.ietf.org/mailman/listinfo/oauth>____
> 
> 
>             ____
> 
>             ____
> 
>             -- ____
> 
>             ____
> 
>             *ORIE STEELE
>             *Chief Technology Officer
>             www.transmute.industries <http://www.transmute.industries>____
> 
>             <https://transmute.industries/>____
> 
> 
>     ____
> 
>     __ __
> 
>     -- ____
> 
>     __ __
> 
>     *ORIE STEELE
>     *Chief Technology Officer
>     www.transmute.industries <http://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