diff --git a/index.html b/index.html index 6d975a7..95d7845 100644 --- a/index.html +++ b/index.html @@ -512,9 +512,9 @@

BitstringStatusListCredential

credentialSubject.statusPurpose -The purpose of the status entry MUST be a string. While the value of the -string is arbitrary, the following values MUST be used for their intended -purpose: +The value of the purpose property of the status entry, `statusPurpose`, MUST be +one or more strings. While the value of each string is arbitrary, the following +values MUST be used for their intended purpose: @@ -790,8 +790,9 @@

Validate Algorithm

STATUS_VERIFICATION_ERROR.
  • -Verify that the |status purpose| is equal to the -`statusPurpose` value in the |statusListCredential|. If the values are not +Verify that the |status purpose| is equal to a `statusPurpose` value in the +|statusListCredential|. Note: The |statusListCredential| might contain multiple +status purposes in a single list. If the values are not equal, raise a STATUS_VERIFICATION_ERROR.
  • @@ -1256,10 +1257,11 @@

    Internationalization Considerations

    Appendix

    Examples

    +

    Revocable Verifiable Credential

    +data-vc-vm="https://example.edu/issuers/565049/keys/1">
     {
       "@context": [
         "https://www.w3.org/ns/credentials/v2",
    @@ -1284,10 +1286,11 @@ 

    Revocable Verifiable Credential

    +

    Status List Verifiable Credential

    +data-vc-vm="https://example.edu/issuers/565049/keys/1">
     {
       "@context": [
         "https://www.w3.org/ns/credentials/v2",
    @@ -1306,6 +1309,115 @@ 

    Status List Verifiable Credential

    }
    + +
    +

    Multiple Status Lists in One Verifiable Credential

    + +

    +This specification enables an issuer to associate multiple status lists +with a single verifiable credential. +

    + +
    +{
    +  "@context": [
    +    "https://www.w3.org/ns/credentials/v2",
    +    "https://www.w3.org/ns/credentials/examples/v2"
    +  ],
    +  "id": "https://example.com/credentials/23894672394",
    +  "type": ["VerifiableCredential"],
    +  "issuer": "did:example:12345",
    +  "issuanceDate": "2021-04-05T14:27:42Z",
    +  // note the use of an array to represent the set of
    +  // status entries
    +  "credentialStatus": [{
    +    "id": "https://example.com/credentials/status/3#94567",
    +    "type": "BitstringStatusListEntry",
    +    "statusPurpose": "revocation",
    +    "statusListIndex": "94567",
    +    "statusListCredential": "https://example.com/credentials/status/3"
    +  }, {
    +    "id": "https://example.com/credentials/status/4#12345",
    +    "type": "BitstringStatusListEntry",
    +    "statusPurpose": "suspension",
    +    "statusListIndex": "12345",
    +    "statusListCredential": "https://example.com/credentials/status/4"
    +  }],
    +  "credentialSubject": {
    +    "id": "did:example:6789",
    +    "type": "Person"
    +  }
    +}
    +        
    +
    + +
    +

    Multiple Status Entries in a Single List

    + +

    +It is possible for a single status list to contain multiple types of status +purposes. Doing so can make the retrieval of a list slightly more efficient +than fetching multiple status lists. +

    + +

    +The "space efficiency" argument for this feature is weak. One list with two types +of status entries must, presumably, be twice as long as a list with one type of +status entries, to ensure proper privacy protections. One privacy benefit of +doing so is that bit flips cannot be known to be associated with a particular +status unless one is also in control of the VC that the status is about. +Therefore, mixing "revocation" and "suspension" in a single list that is twice +as large has positive privacy implications.

    +The "retrieval efficiency" argument is also weak. Performing two HTTP retrievals +instead of one is probably not significant. Performing upwards of five or six, +on a list that is five or six times larger, might result in fairly meager +savings over modern versions of HTTP that bundle requests over a single channel +(such as HTTP/2 or HTTP/3). The requests themselves would save a handful of +bytes with no significant improvement in retrieval speed.

    +The Working Group is looking for feedback from implementers and is considering +striking this feature during the Candidate Recommendation period, since it would +simplify the specification for implementations to not have to support sets of +`statusPurpose` values in the status list credentials (again, a meager savings +in space efficiency at a small cost to retrieval efficiency). +

    + +
    +{
    +  "@context": [
    +    "https://www.w3.org/ns/credentials/v2",
    +    "https://www.w3.org/ns/credentials/examples/v2"
    +  ],
    +  "id": "https://example.com/credentials/23894672394",
    +  "type": ["VerifiableCredential"],
    +  "issuer": "did:example:12345",
    +  "issuanceDate": "2021-04-05T14:27:42Z",
    +  // note the use of a single list to store multiple
    +  // status entries
    +  "credentialStatus": [{
    +    "id": "https://example.com/credentials/status/5#94567",
    +    "type": "BitstringStatusListEntry",
    +    "statusPurpose": "revocation",
    +    "statusListIndex": "94567",
    +    "statusListCredential": "https://example.com/credentials/status/5"
    +  }, {
    +    "id": "https://example.com/credentials/status/5#12345",
    +    "type": "BitstringStatusListEntry",
    +    "statusPurpose": "suspension",
    +    "statusListIndex": "12345",
    +    "statusListCredential": "https://example.com/credentials/status/5"
    +  }],
    +  "credentialSubject": {
    +    "id": "did:example:6789",
    +    "type": "Person"
    +  }
    +}
    +        
    +
    +