Skip to content

Commit

Permalink
docs: add homogeneity requirement (#163)
Browse files Browse the repository at this point in the history 
* docs: add homogeneity requirement

* Apply suggestions from code review

Co-authored-by: Jim Marino <[email protected]>

---------

Co-authored-by: Jim Marino <[email protected]>
  • Loading branch information
@paullatzelsperger @jimmarino
paullatzelsperger and jimmarino authored Jan 16, 2025
1 parent 8634476 commit 8adc351
Showing 1 changed file with 19 additions and 7 deletions.
26 changes: 19 additions & 7 deletions specifications/dcp.profiles.md
View file
Original file line number Diff line number Diff line change
@@ -1,23 +1,33 @@
## Profiles of the Decentralized Claims Protocol


Many different variations of the Verifiable Credentials data model, the revocation system and the proof stack exist which
makes it almost impossible to reach a sufficient level of interoperability. Profiles of the DCP specification help
Different variations of the Verifiable Credentials Data Model, the revocation system, and proof stack
complicate interoperability. Profiles of the DCP specification help
narrow down those possibilities.

This specification defines two profiles, which are referenced by an alias.

## DCP Profile Definitions

| alias | VC Data Model | Revocation System | Proof Stack | Remarks |
|-------------------|-------------------------------------------------------------|--------------------------------------------------------------------------|-----------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `vc20-bssl/jwt` | [VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0) | [BitStringStatusList](https://www.w3.org/TR/vc-bitstring-status-list/) | Enveloped proofs [using JWT](https://www.w3.org/TR/vc-jose-cose/#with-jose) | Ignore `ttl`, use `validUntil` *). No JWE supported. The concrete signature algorithm is not specified, as implementors are expected to handle all reasonably well-known crypto algorithms like RSA, EC and EdDSA |
| `vc11-sl2021/jwt` | [VC Data Model 1.1](https://www.w3.org/TR/vc-data-model) | [StatusList2021](https://www.w3.org/TR/2023/WD-vc-status-list-20230427/) | External proofs using JWT | No JWE supported. The concrete signature algorithm is not specified, as implementors are expected to handle all reasonably well-known crypto algorithms like RSA, EC and EdDSA |
| alias | VC Data Model | Revocation System | Proof Stack | Remarks |
|-------------------|--------------------------------------------------------------|--------------------------------------------------------------------------|----------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `vc20-bssl/jwt` | [VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0) | [BitStringStatusList](https://www.w3.org/TR/vc-bitstring-status-list/) | Enveloped proofs [using JWT/JOSE](https://www.w3.org/TR/vc-jose-cose/#with-jose) | Ignore `ttl`, use `validUntil` *). No JWE supported. The concrete signature algorithm is not specified, as implementors are expected to handle all reasonably well-known crypto algorithms like RSA, EC and EdDSA |
| `vc11-sl2021/jwt` | [VC Data Model 1.1](https://www.w3.org/TR/vc-data-model) | [StatusList2021](https://www.w3.org/TR/2023/WD-vc-status-list-20230427/) | External proofs using JWT | No JWE supported. The concrete signature algorithm is not specified, as implementors are expected to handle all reasonably well-known crypto algorithms like RSA, EC and EdDSA |

*) In its current form, the BitStringStatusList credential data
model [conflicts](https://www.w3.org/TR/vc-bitstring-status-list/#bitstringstatuslistcredential) with the VC DataModel
2.0, specifically regarding the validity period (`ttl` vs `validUntil`).

### Homogeneity requirement

Verifiable Credentials MUST be _homogenous_. This means the
same data model version and proof mechanism must be used for both credentials and presentations. For example, a
verifiable credential secured with an _enveloped proof_ using
JOSE ([VC Data Model 2.0](https://www.w3.org/TR/vc-jose-cose/#with-jose)) is enclosed in a verifiable presentation
that is also secured with JWT/JOSE.

Heterogeneous sets of credentials MUST be enclosed in multiple presentations in such that each presentation only
contains credentials of the same data model and proof mechanism.

## Profile Authoring Recommendations

This non-normative section is intended to provide guidance to authors who aim at defining their own profile definition.
Expand All @@ -30,3 +40,5 @@ For a usable profile, at least the following aspects must be defined:

In addition, it is possible to further constrain the profile, for example by limiting the number of acceptable
cryptographic algorithms.

Profile authors are recommended, when possible, to use a single credential format.

0 comments on commit 8adc351

Please sign in to comment.