Skip to content
This repository has been archived by the owner on Apr 18, 2024. It is now read-only.

Suggested Charter text from Roman #23

Closed
wants to merge 1 commit into from
Closed

Suggested Charter text from Roman #23

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
62 changes: 12 additions & 50 deletions charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,18 +4,19 @@

Digital credentials are essential to identity, authorization, licenses, certificates and digitization use cases that are part of modernization efforts targeting efficiency, and transparency, such as digital licenses or certificates of origin.

A digital credential expresses claims or attributes about a subject, such as their name or age, made my an authority known as an issuer, such as a government agency.
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:

The term "holder" is used to describe an entity (person, device, organization, or software agent) that controls disclosure of credentials.
- 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.
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.

When received by an entity, a proof of the digital credential needs to be provided and verified, so that only the legitimate controller of the digital credential can take an 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.

Some holders may wish to carry more than one credential. These credentials, together with associated key material, can be stored in a 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.


## In-Scope
## Goal

The SPICE working group will develop a framework and recommendations for deploying digital credentials based on JOSE and COSE.

Expand All @@ -32,71 +33,32 @@ The following topics will be considered in the milestones:
- Integrity (ensuring tampering with information is always evident)
- Usability and Feasibility (the core operations must be easy to understand and use, and possible to integrate with existing platforms)

## Background

W3C has introduced a 'Three Role Model' in the 'Verifiable Credentials Data Model v2.0' specification. VCDM 2.0 (https://w3c.github.io/vc-data-model)
with the following roles: a holder, an issuer and a verifier.

The wording "Verifiable Credential" (VC) is used in VCDM 2.0. It implies the use of data serialization using JSON-LD.
The wording "Verifiable Presentation" (VP) is used in VCDM 2.0. It implies the use of data serialization using JSON-LD.

In this charter, the VC concept is captured using the wording "digital credential", while the VP concept is captured using the wording "digital presentation".

Some sets of claim names are registered with IANA and originate from the IETF, OIDF and other standards organizations.

For example, [jwt](https://www.iana.org/assignments/jwt/jwt.xhtml) and [cwt](https://www.iana.org/assignments/cwt/cwt.xhtml) both contain expressions for "subject" and "issuer", while the JWT registry has claims such as "name" and "email address", the CWT registry has claims regarding devices, such as "Software Measurement Results", and "Certifications received as Digital Letters of Approval".

IETF working groups and IRTF research groups have developed foundational building blocks with [BBS Signatures](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/), [RSA Blind Signatures](https://datatracker.ietf.org/doc/rfc9474/), [Verifiable Random Functions](https://datatracker.ietf.org/doc/rfc9381/),
or other [Selective-Disclosure](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) and collection limitation techniques.
The WG will coordinate with RATS, OAuth, JOSE, COSE and SCITT working in related areas in the identity and credential space. The WG will also build on cryptographic primitives defined in the CFRG (e.g., BBS Signatures) and will not define novel cryptographic schemes.

The SPICE WG intends to consume cryptographic systems produced by CFRG, similar to how those schemes are consumed in JOSE and COSE.
## Program of Work

The SPICE WG will not develop novel cryptographic schemes, but might provide comments on use cases for schemes under development in CFRG.

## Deliverables

Documents produced by the working group will include the following:
The WG will focus on the following program of work.

### Architecture

An architecture document that defines the terminology (e.g., Issuer, Holder, Verifier, Claims, Credentials, Presentations), and the essential communciation 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. The architecture will also cover the extensibility points, such as discovering key material associated with the roles (to enable digital signatures, proofs and encryption), formats such as JSON and CBOR based claims, and protocols, such as the various ways to transport credentials and presentations. The architecture will not define new key formats, credential formats, or protocols, but it will express how their evolution can support digital credential improvements over time.
An architecture document 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.

Related Drafts:

- https://datatracker.ietf.org/doc/draft-steele-spice-profiles-bcp/
- https://datatracker.ietf.org/doc/draft-steele-spice-transparency-tokens/

### Metadata Discovery

A meta-data discovery document enabling the 3 roles (issuers, holders and verifiers) to discover supported protocols and formats for keys, claims, credentials and proofs.
With high probability this will build on HTTP, but with some consideration for constrained devices, and with a good deal of inspiration from recent HTTP work in OAuth, for example the "vc-jwt-issuer" metadata work in [draft-ietf-oauth-sd-jwt-vc](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/), but without being limited to JSON.

Related Drafts:

- https://datatracker.ietf.org/doc/draft-steele-spice-metadata-discovery/
- https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
- https://datatracker.ietf.org/doc/draft-steele-spice-vcard-credentials/

### Selective Disclosure of Claims

A document specifying the selective disclosure of claims in a secure and privacy-friendly manner.
This document will cover the details of making presentations of credentials, the traceability considerations for different cryptographic approaches, and concrete serialization guidance enabling support for CBOR based versions of SD-JWT or similar approaches, building on BBS.
We expect this document to address features relevant to digital credentials that have been exclusively implemented in JSON or CBOR, and provide an integrated concrete approach for JSON and CBOR based credentials.

Related Drafts:

- https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/
- https://datatracker.ietf.org/doc/draft-steele-spice-transparency-tokens/

## Milestones

- 10 2024 - Submit an informational Architecture document to the IESG for publication
- 02 2025 - Submit a document as a proposed standard covering Metadata Discovery to the IESG for publication
- 02 2025 - Submit a document as a proposed standard covering Selective Disclosure of Claims to the IESG for publication

## Coordination

Coordination with CFRG, RATS, OAuth, JOSE, COSE, and SCITT are important to ensure that the latest work at IETF is leveraged.
Feedback from experts in other IETF working groups is gathered in the SPICE WG without creating fragments of credential work spread across several existing places in the IETF.
Additionally, the SPICE WG will coordinate with other organizations that have specific documents or working groups targeting the definition or application of digital credentials.