Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history 
Co-authored-by: Alberto Solavagione <[email protected]>
Co-authored-by: Lucas Tortora <[email protected]>
Co-authored-by: Luca Giorgino <[email protected]>
  • Loading branch information
@UMR1352 @AlbertoSvg
@lucas-tortora @lucagiorgino
4 people authored May 21, 2024
1 parent de004d9 commit 5df3457
Show file tree
Hide file tree
Showing 2 changed files with 19 additions and 18 deletions.
6 changes: 3 additions & 3 deletions ...1.3/docs/how-tos/verifiable-credentials/zero-knowledge-selective-disclosure.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -26,10 +26,10 @@ undisclosed, whereas for SD-JWT VCs it's the issuer that decides which fields ma

## Concepts
### Issuance
The issuer of a ZK-SD-VC creates the credential, signs it using the [BBS+](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) signature scheme
The issuer of a ZK-SD-VC creates the credential, signs it using the [BBS+](https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-05.html) signature scheme
and sends both the credential and the signature to the holder. To facilitate this process, the credential is first encoded
as a [JSON Proof Token](https://www.ietf.org/archive/id/draft-ietf-jose-json-proof-token-02.html) (JPT), which is then used as the payload of a
[JSON Web Proof](https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof-00.html) (JWP) and sent to the holder as JPT.
[JSON Web Proof](https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-02.html) (JWP) and sent to the holder as JPT.
:::note
JWPs and JPTs can be reasoned about as the Zero Knowledge (ZK) based counterparts of JWSs and JWTs.
:::
Expand Down Expand Up @@ -111,7 +111,7 @@ Here's an example presented JWP in its JPT JSON serialization format where the u
### Verification

The verifier decodes the received JPT presentation and asserts the validity of the ZKP it contains, thus proving the
authenticity and integrity of the presented credential, without knowledge of any of the undisclosed fields.
authenticity and integrity of the presented credential, without knowledge of any of the undisclosed fields and of the issuer signature.

<Tabs groupId="language" queryString>

Expand Down
31 changes: 16 additions & 15 deletions ...ld/identity.rs/1.3/docs/references/specifications/revocation-timeframe-2024.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,36 +16,37 @@ tags:
## Abstract

This specification describes a new revocation mechanism - `RevocationTimeframe2024` - that extends [`RevocationBitmap2022`](../revocation-bitmap-2022)
in order to address its linkability security concerns, at least when used in combination with selectively-disclosable (SD-able) VCs.
to address its linkability security concerns, at least when used in combination with selectively disclosable (SD-able) VCs.

## Introduction

`RevocationBitmap2022` allows for a simple and straightforward way for an issuer to invalidate an issued VC before its expiration. While this method prevents the analysis of usage by the issuer through hosting the revocation information on-chain
it comes with a high risk of linkability by colluding verfiers as they can store the bitmap index and use it to identify users. Additionally verifiers can monitor the revocation information and at later point, outside of nay interaction, check the revocation status.
it comes with a high risk of linkability by colluding verifiers as they can store the bitmap index and use it to identify users. Additionally, verifiers can monitor the revocation information and at a later point, outside of any interaction, check the revocation status.
To address this privacy concern, `RevocationTimeframe2024` was designed as an extension that builds on top of `RevocationBitmap2022`, therefore sharing
most of its logic.

## Concepts
`RevocationTimeframe2024` should be used together with selectively disclosable credentials - either [SD-JWT](../../../how-tos/verifiable-credentials/selective-disclosure)
or [ZK-SD](../../../how-tos/verifiable-credentials/zero-knowledge-selective-disclosure) - in order to conceal to the verifier
the credential's index in the issuers revocation bitmap to avoid linkability.
the credential's index in the issuer's revocation bitmap to avoid linkability.

### Validity Timeframe
If the revocation index is concealed to the verifier how can it assert the validity of the presented credential?
To solve this issue `RevocationTimeframe2024` introduces the concept of a _validity timeframe_, i.e. a limited span of time
in which the credential is guaranted to be non-revoked. By having a validity timeframe embedded in the credentials status
the verifier can prove the credentials validity by verifying the credentials signature.

The downside of this mechanism is that the holder of a credential using `RevocationTimeframe2024` has to contact the credentials issuer
If the revocation index is concealed from the verifier how can it assert the validity of the presented credential?
To solve this issue `RevocationTimeframe2024` introduces the concept of a _validity timeframe_, i.e. a limited time span
in which the credential is guaranteed to be non-revoked. By having a validity timeframe embedded in the credential's status
the verifier can prove the credential's validity by verifying the credential's signature.

The downside of this mechanism is that the credential holder using `RevocationTimeframe2024` has to contact the credential's issuer
to update the signature - i.e. re-issue the credential - at the end of the credentials validity timeframe. Furthermore,
given as how a credentials validity timeframe proves the validity of the credential itself, the updates made by the issuer to the credentials status -
i.e revoking or unrevoking it - won't be reflected on the credential until the start of a new validity timeframe. For this reason,
given how a credentials validity timeframe proves the validity of the credential itself, the updates made by the issuer to the credential's status -
i.e., revoking or un-revoking it - won't be reflected on the credential until a new validity timeframe starts. For this reason,
issuers should choose a validity timeframe length with respect to how frequently they expect to change the credential's status;
frequent updates deems shorter validity timeframes.
frequent updates deem shorter validity timeframes.

:::note
A credential holder does not need to have its credential re-issued at the end of every validity timeframe, but only when
they need to present the credential to a verifier and the credentials validity timeframe has expired.
they need to present the credential to a verifier and its validity timeframe has expired.
:::

## Data Model
Expand All @@ -57,8 +58,8 @@ For an issuer to enable verifiers to check the status of a verifiable credential
| Property | Description |
| :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `id` | The constraints on the `id` property are listed in the [Verifiable Credentials Data Model specification](https://www.w3.org/TR/vc-data-model/). The `id` MUST be a [DID URL](https://www.w3.org/TR/did-core/#did-url-syntax) that is the URL to a [Revocation Bitmap Service](#revocation-bitmap-service) in the DID Document of the issuer. |
| `type` | The `type` property MUST be `"RevocationBitmap2022"`. |
| `revocationBitmapIndex` | The `revocationBitmapIndex` property MUST be an unsigned, 32-bit integer expressed as a string. This is the index of the credential in the issuers revocation bitmap. Each index SHOULD be unique among all credentials linking to the same [Revocation Bitmap Service](#revocation-bitmap-service). |
| `type` | The `type` property MUST be `"RevocationTimeframe2024"`. |
| `revocationBitmapIndex` | The `revocationBitmapIndex` property MUST be an unsigned, 32-bit integer expressed as a string. This is the index of the credential in the issuers revocation bitmap. Each index SHOULD be unique among all credentials linking to the same [Revocation Bitmap Service](#revocation-bitmap-service). To ensure user unlinkability, this value MUST NOT be disclosed to the verifier (this is done by default). |
| `startValidityTimeframe`| The `startValidityTimeframe` property MUST be a [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)-compliant timestamp. |
| `endValidityTimeframe`| The `endValidityTimeframe` property MUST be a [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339)-compliant timestamp. |

Expand All @@ -80,7 +81,7 @@ An example of a verifiable credential with a `credentialStatus` of type `Revocat
"issuer": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw",
"issuanceDate": "2022-06-13T08:04:36Z",
"credentialStatus": {
"id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw?index=5#revocation",
"id": "did:iota:EvaQhPXXsJsGgxSXGhZGMCvTt63KuAFtaGThx6a5nSpw#my-revocation-service",
"type": "RevocationTimeframe2024",
"revocationBitmapIndex": "5"
"startValidityTimeframe": "2024-05-03T08:00:00Z",
Expand Down

0 comments on commit 5df3457

Please sign in to comment.