henkbirkholz / ietf-spice-charter

0 stars 0 forks source link

Proposal to address the majority of comments from Gunter #7

Open henkbirkholz opened 4 months ago

henkbirkholz commented 4 months ago

fixes #1 (if ready to merge)

henkbirkholz commented 4 months ago

high level comments In general the charter looks different from other charter styles observed.

It would require a major refactoring of the whole charter text to address the overall structure comment. There are other charter examples that look more similar, such as: https://datatracker.ietf.org/doc/charter-ietf-rats/ or https://datatracker.ietf.org/doc/charter-ietf-scitt/

henkbirkholz commented 4 months ago

OLD A digital credential expresses claims, assertions, 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).

With Éric's suggestions A digital credential links claims about a subject 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).

NEW A digital credential intends to link claims regarding a subject and their cryptographic keys. Various sets of claim names have already been defined by the IETF and other standards development groups, such as the OpenID Foundation.

henkbirkholz commented 4 months ago

Éric's suggestion might already address some of this comment.

OLD Digital credentials typically involve at least three entities. An issuer constructs and secures a digital credential for a holder. 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. Holders disclose credentials, attributes, or proofs regarding attributes in what is called a "digital presentation" to a verifier.

COMMENTS What are the three entities being referred towards? i realized at the end of reading the charter that this is —issuers, holders, and verifiers—. maybe this can be explitly mentioned before digging deeper in the documented considerations?

Éric's suggestions Digital credentials typically involve at least three entities: issuer, holder, and verifier. An issuer constructs and secures a digital credential for a holder. 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. Holders disclose credentials, attributes, or proofs regarding attributes in what is called a "digital presentation" to a verifier.

henkbirkholz commented 4 months ago

OLD The SPICE WG will profile existing IETF technologies and address residual gaps that would enable their use in digital credentials and presentations.

With Éric's suggestions The SPICE WG will analyze existing and emerging IETF technologies and address residual gaps that would enable their use in digital credentials and presentations.

NEW The SPICE WG shall analyze existing and emerging IETF technologies and address any remaining gaps to facilitate their application in digital credentials and presentations.

henkbirkholz commented 4 months ago

OLD 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). The SPICE WG will profile these token formats for use with digital credentials.

NEW The JOSE WG is currently standardizing a token format for unlinkability and selective disclosure as specified in JWP/CWP (draft-ietf-jose-json-web-proof). The SPICE WG shall profile these token formats for application in digital credentials.

henkbirkholz commented 4 months ago

OLD 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 and 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.

NEW The OAUTH WG is currently standardizing a token format for unlinkability and selective disclosure in the form of SD-JWT/SD-JWT-VC (draft-ietf-oauth-selective-disclosure-jwt and draft-ietf-oauth-sd-jwt-vc). The SPICE WG shall define SD-CWT/SD-CWT-VC, which are analogous to these JWT-based tokens, but based on CWT.

henkbirkholz commented 4 months ago

OLD The SPICE WG coordinates with RATS, OAuth, JOSE, COSE, and SCITT working groups that develop documents related to the identity and credential space. The SPICE WG builds on existing cryptographic primitives and does not define novel cryptographic schemes.

NEW The SPICE WG shall coordinate with RATS, OAuth, JOSE, COSE, and SCITT working groups that are involved in developing documents pertinent to the identity and credential space. The SPICE WG shall build build upon existing cryptographic primitives and shall not define novel cryptographic schemes.

henkbirkholz commented 4 months ago

OLD The SPICE WG develops digital credential profiles which can support a number of use cases. To help guide engineering decisions, requirements for proposed standards in the program of work will be created in coordination with the working groups listed above. The profiles developed by the SPICE WG will enable digital credentials to leverage existing IETF technologies.

NEW The SPICE WG shall develop digital credential profiles that support various use cases. Requirements for proposed standards in the program of work shall be established in coordination with the aforementioned working groups. The profiles developed by the SPICE WG shall enable digital credentials to leverage existing IETF technologies.

henkbirkholz commented 4 months ago

OLD The privacy and security considerations related to the impact of confidential computing, remote attestation, trusted execution environments (TEE), and hardware security modules (HSM) on digital credentials will be developed in coordination with relevant IETF WGs (e.g., TEEP) and feedback from experts on the mailing list.

NEW Privacy and security considerations concerning the impact of confidential computing, remote attestation, trusted execution environments (TEE), and hardware security modules (HSM) on digital credentials shall be developed in coordination with relevant IETF WGs (e.g., TEEP) and incorporate feedback from experts on the mailing list.

henkbirkholz commented 4 months ago

All occurrences of "proposed standard" in the program of work are now capitalized the way your suggestion for one of the program of work items does (to keep the style consistent).

OLD A proposed standard Metadata & Capability Discovery protocol for JWT, CWT, SD-JWT, SD-CWT, CWP and JWP using HTTPS/CoAP for CBOR-based digital credentials to enable the 3 roles (issuers, holders and verifiers) to discover supported capabilities, 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) which supports ecosystems using JSON serialization.

NEW A Proposed Standard Metadata & Capability Discovery protocol shall be developed for JWT, CWT, SD-JWT, SD-CWT, CWP and JWP using HTTPS/CoAP. This protocol, intended for CBOR-based digital credentials shall enable the three roles —issuers, holders and verifiers— to discover supported capabilities, protocols, and formats for keys, claims, credential types and proofs. The design shall be inspired by the OAuth "vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc), which supports ecosystems using JSON serialization.

henkbirkholz commented 4 months ago

The Milstones are now removed from the charter text as suggested by Roman in #3 and done in #5

OLD 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 & Capability Discovery protocol to the IESG for publication

brentzundel commented 4 months ago

OLD A digital credential expresses claims, assertions, 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).

With Éric's suggestions A digital credential links claims about a subject 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).

NEW A digital credential intends to link claims regarding a subject and their cryptographic keys. Various sets of claim names have already been defined by the IETF and other standards development groups, such as the OpenID Foundation.

This makes it sound like a digital credential is all about linking a subject's keys to claims. I suggested a different wording in one of the other PRs.

henkbirkholz commented 3 months ago

OLD A digital credential expresses claims, assertions, 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). With Éric's suggestions A digital credential links claims about a subject 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). NEW A digital credential intends to link claims regarding a subject and their cryptographic keys. Various sets of claim names have already been defined by the IETF and other standards development groups, such as the OpenID Foundation.

This makes it sound like a digital credential is all about linking a subject's keys to claims. I suggested a different wording in one of the other PRs.

NEW NEW A digital credential intends to link claims regarding a subject and their cryptographic keys. Various sets of claim names that can represent credential attributes have already been defined by the IETF (per RFC 7519 and RFC 8392) and other standards development groups, such as the OpenID Foundation.

This change also includes a minimal addition to address the confusion that John encountered in #2. Sorry that comments result in overlapping changes, but that's how it is.