Skip to content

Commit

Permalink
Fix broken links
Browse files Browse the repository at this point in the history
  • Loading branch information
Dr-Electron committed Sep 3, 2024
1 parent 1d7816e commit dadeb67
Show file tree
Hide file tree
Showing 29 changed files with 41 additions and 41 deletions.
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
# Verifiable Presentations

A verifiable presentation is the recommended data format for sharing one or more [verifiable credentials](./verifiable-credentials.mdx).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for [validation](#validation).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for validation.

For instance: after an issuer [creates and issues](./../how-tos/verifiable-credentials/create.mdx) a [verifiable credential](./verifiable-credentials.mdx) to a holder, such as a university issuing a degree to a graduate,
For instance, after an issuer [creates and issues](./../how-tos/verifiable-credentials/create.mdx) a [verifiable credential](./verifiable-credentials.mdx) to a holder, such as a university issuing a degree to a graduate,
the holder stores it securely until asked to present it.
A company could then request proof of that university degree: the holder can [create a verifiable presentation](./../how-tos/verifiable-credentials/create.mdx)
containing their credential, which is already signed by their university, and present it to the company to [validate](./../how-tos/verifiable-credentials/create.mdx#validate-a-vc).
containing their credential, already signed by their university, and present it to the company to [validate](./../how-tos/verifiable-credentials/create.mdx#validate-a-vc).

Note that verifiable presentations that contain personal data should, as with verifiable credentials, be transmitted and stored securely off-chain to satisfy data privacy regulations such as [GDPR](https://gdpr.eu/).

Expand All @@ -20,7 +20,7 @@ See the [Verifiable Credentials Data Model Specification](https://www.w3.org/TR/

### Replay Attacks

A verifiable presentation without a challenge could potentially be stored by a malicious actor
A malicious actor could potentially store a verifiable presentation without a challenge
and replayed to a different verifier, impersonating the holder.
This is because the holder's signature on a presentation would still be seen as valid indefinitely,
until they [rotate](https://www.w3.org/TR/did-core/#verification-method-rotation) the verification method used.
Expand All @@ -35,5 +35,5 @@ The challenge string should be sufficiently random and unique for each verifiabl
being predicted.

Holders may additionally specify that their signature on a verifiable presentation expires after a short duration, as
per `JwtPresentationOptions`. However, verifiers and different implementations could choose to ignore that property,
per `JwtPresentationOptions`. However, verifiers and different implementations could ignore that property,
so setting a signature expiration alone should not be relied upon.
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ resolve the DID Documents of the [verifiable credential](./../../explanations/ve
and presentation holder to verify their signatures.

Resolving the necessary DID Documents is
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example)
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example-code)

When direct access to these DID Documents is desired, the `Resolver` also provides standalone methods to:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ while a service can provide metadata around the identity via URIs.

## Verification Methods

As demonstrated by the [example](#example) below, the IOTA Identity framework offers easy-to-use methods for adding
As demonstrated by the [example](#full-example-code) below, the IOTA Identity framework offers easy-to-use methods for adding
[verification methods](https://www.w3.org/TR/did-core/#verification-methods).

### Properties
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ In the IOTA Identity Framework, you can create a Verifiable Credential with the



## Signing {#signing}
## Signing

After preparing the verifiable credential, the issuer creates a signed JWT containing VC in the claims using one of their private keys. This is what allows verifiers to independently validate the credential using the corresponding public key from the issuer's DID Document.

Expand Down Expand Up @@ -71,7 +71,7 @@ and for enforcing [subject-holder relationships](https://www.w3.org/TR/vc-data-m

## Example

The following code showcases how an issuer can [create, sign](#create-and-sign-vc),
The following code showcases how an issuer can [create, sign](#create-and-sign-a-vc),
and [validate](#validate-a-vc) a verifiable credential.
In this example, the issuer signs a `UniversityDegreeCredential` with Alice's name and DID.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem';

# Revoke a Verifiable Credential

The [example](#example) below demonstrates two methods that an issuer can use to revoke a verifiable credential
The [example](#full-example-code) below demonstrates two methods that an issuer can use to revoke a verifiable credential
using the IOTA Identity Framework:

1. By using the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) field in a credential and linking to a
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -188,7 +188,7 @@ Because of its space efficiency, a roaring bitmap is preferred for representing

The [RevocationList2020 specification](https://w3c-ccg.github.io/vc-status-rl-2020/) and [StatusList2021 specification](https://w3c-ccg.github.io/vc-status-list-2021/) both describe a similar revocation mechanism using a verifiable credential that contains a bitmap, similar to the `RevocationBitmap2022` approach. The credential is hosted outside of the DID document and the verifier thus needs to fetch it from an external resource, likely one controlled by the issuer. This has privacy implications as the issuer can track where a fetch request for the credential came from and potentially infer who the credential was verified by and for what purpose. The issuer can also potentially infer which credential was checked. Because `RevocationBitmap2022` is embedded in the issuer's DID document, which can be obtained without the their knowledge, this approach does not suffer from these privacy shortcomings. See also the [privacy considerations](#privacy-considerations).

A downside of embedding the revocation list in the DID document is that storage in a distributed ledger (DLT) is usually more expensive than other storage hosting solutions. The DLT might also impose message size limitations, capping the total number of revocations that can be done (see also [compression](#compression)).
A downside of embedding the revocation list in the DID document is that storage in a distributed ledger (DLT) is usually more expensive than other storage hosting solutions. The DLT might also impose message size limitations, capping the total number of revocations that can be done (see also [compression](#compression-and-maximum-size)).

Another difference is that `RevocationList2020` specifies a minimum initial size of 131,072 for its bitstring, to mitigate the potential for correlating individuals when few credentials have been issued. `RevocationBitmap2022` uses a roaring bitmap instead of a bitstring, so the maximum size is not fixed (apart from the upper bound of an unsigned 32-bit integer). This means the bitmap cannot be used to correlate small populations without more information not present in the bitmap itself. However, both schemes still reveal publicly how many credentials have been revoked, which could be used to infer other information if more knowledge about how an issuer assigns credential revocation indexes is known.

Expand Down
2 changes: 1 addition & 1 deletion docs/build/identity.rs/1.0/docs/workflow.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ With the release process, we can deliver versions of our software to the communi

The final list of changes from the [changelog](#changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.

The determined version of the release is used to create the [hotfix](#hotfix) or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.
The determined version of the release is used to create the hotfix or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.

Notice the `v` in front of the version. We [tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) all release in git in the form of `vMAJOR.MINOR.PATCH`. For bindings, we prefix the tag with the binding name, so a tag for Wasm would look like `wasm-v1.2.3`. Bindings and the core Rust library are versioned and released independently.

Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Verifiable Presentations

A verifiable presentation is the recommended data format for sharing one or more [verifiable credentials](./verifiable-credentials.mdx).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for [validation](#validation).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for validation.

For instance, after an issuer [creates and issues](./../how-tos/verifiable-credentials/create.mdx) a [verifiable credential](./verifiable-credentials.mdx) to a holder, such as a university issuing a degree to a graduate,
the holder stores it securely until asked to present it.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ resolve the DID Documents of the [verifiable credential](./../../explanations/ve
and presentation holder to verify their signatures.

Resolving the necessary DID Documents is
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example)
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example-code)

When direct access to these DID Documents is desired, the `Resolver` also provides standalone methods to:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ while a service can provide metadata around the identity via URIs.

## Verification Methods

As demonstrated by the [example](#example) below, the IOTA Identity framework offers easy-to-use methods for adding
As demonstrated by the [example](#full-example-code) below, the IOTA Identity framework offers easy-to-use methods for adding
[verification methods](https://www.w3.org/TR/did-core/#verification-methods).

### Properties
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ In the IOTA Identity Framework, you can create a Verifiable Credential with the



## Signing {#signing}
## Signing

After preparing the verifiable credential, the issuer creates a signed JWT containing VC in the claims using one of their private keys. This is what allows verifiers to validate the credential independently using the corresponding public key from the issuer's DID Document.

Expand Down Expand Up @@ -71,7 +71,7 @@ and for enforcing [subject-holder relationships](https://www.w3.org/TR/vc-data-m

## Example

The following code showcases how an issuer can [create, sign](#create-and-sign-vc),
The following code showcases how an issuer can [create, sign](#create-and-sign-a-vc),
and [validate](#validate-a-vc) a verifiable credential.
In this example, the issuer signs a `UniversityDegreeCredential` with Alice's name and DID.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem';

# Revoke a Verifiable Credential

The [example](#example) below demonstrates two methods that an issuer can use to revoke a verifiable credential
The [example](#full-example-code) below demonstrates two methods that an issuer can use to revoke a verifiable credential
using the IOTA Identity Framework:

1. By using the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) field in a credential and linking
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -188,7 +188,7 @@ Because of its space efficiency, a roaring bitmap is preferred for representing

The [RevocationList2020 specification](https://w3c-ccg.github.io/vc-status-rl-2020/) and [StatusList2021 specification](https://w3c-ccg.github.io/vc-status-list-2021/) both describe a similar revocation mechanism using a verifiable credential that contains a bitmap, similar to the `RevocationBitmap2022` approach. The credential is hosted outside of the DID document and the verifier thus needs to fetch it from an external resource, likely one controlled by the issuer. This has privacy implications as the issuer can track where a fetch request for the credential came from and potentially infer who the credential was verified by and for what purpose. The issuer can also potentially infer which credential was checked. Because `RevocationBitmap2022` is embedded in the issuer's DID document, which can be obtained without the their knowledge, this approach does not suffer from these privacy shortcomings. See also the [privacy considerations](#privacy-considerations).

A downside of embedding the revocation list in the DID document is that storage in a distributed ledger (DLT) is usually more expensive than other storage hosting solutions. The DLT might also impose message size limitations, capping the total number of revocations that can be done (see also [compression](#compression)).
A downside of embedding the revocation list in the DID document is that storage in a distributed ledger (DLT) is usually more expensive than other storage hosting solutions. The DLT might also impose message size limitations, capping the total number of revocations that can be done (see also [compression](#compression-and-maximum-size)).

Another difference is that `RevocationList2020` specifies a minimum initial size of 131,072 for its bitstring, to mitigate the potential for correlating individuals when few credentials have been issued. `RevocationBitmap2022` uses a roaring bitmap instead of a bitstring, so the maximum size is not fixed (apart from the upper bound of an unsigned 32-bit integer). This means the bitmap cannot be used to correlate small populations without more information not present in the bitmap itself. However, both schemes still reveal publicly how many credentials have been revoked, which could be used to infer other information if more knowledge about how an issuer assigns credential revocation indexes is known.

Expand Down
2 changes: 1 addition & 1 deletion docs/build/identity.rs/1.1/docs/workflow.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ With the release process, we can deliver versions of our software to the communi

The final list of changes from the [changelog](#changelog) informs the version of the release. If at least one change mapping to a major version is included, the major version needs to be incremented. In that case, the minor and patch versions are set to `0`. If there are no changes related to a major version, but changes related to a minor version are present, the minor version needs to be incremented while the patch version is set to `0`. Otherwise, only the patch version is incremented. Determining the version of the release is the responsibility of the person performing the release.

The determined version of the release is used to create the [hotfix](#hotfix) or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.
The determined version of the release is used to create the hotfix or [release](#release) branch. For example, a major release from the previous version `v2.3.1` will create the `release/v3.0.0` branch.

Notice the `v` in front of the version. We [tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) all release in git in the form of `vMAJOR.MINOR.PATCH`. For bindings, we prefix the tag with the binding name, so a tag for Wasm would look like `wasm-v1.2.3`. Bindings and the core Rust library are versioned and released independently.

Expand Down
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Verifiable Presentations

A verifiable presentation is the recommended data format for sharing one or more [verifiable credentials](./verifiable-credentials.mdx).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for [validation](#validation).
It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for validation.

For instance, after an issuer [creates and issues](./../how-tos/verifiable-credentials/create.mdx) a [verifiable credential](./verifiable-credentials.mdx) to a holder, such as a university issuing a degree to a graduate,
the holder stores it securely until asked to present it.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ resolve the DID Documents of the [verifiable credential](./../../explanations/ve
and presentation holder to verify their signatures.

Resolving the necessary DID Documents is
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example)
[performed automatically when verifying presentations via the `Resolver`](../verifiable-presentations/create-and-validate.mdx#example-code)

When direct access to these DID Documents is desired, the `Resolver` also provides standalone methods to:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ while a service can provide metadata around the identity via URIs.

## Verification Methods

As demonstrated by the [example](#example) below, the IOTA Identity framework offers easy-to-use methods for adding
As demonstrated by the [example](#full-example-code) below, the IOTA Identity framework offers easy-to-use methods for adding
[verification methods](https://www.w3.org/TR/did-core/#verification-methods).

### Properties
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ In the IOTA Identity Framework, you can create a Verifiable Credential with the



## Signing {#signing}
## Signing

After preparing the verifiable credential, the issuer creates a signed JWT containing VC in the claims using one of their private keys. This is what allows verifiers to validate the credential independently using the corresponding public key from the issuer's DID Document.

Expand Down Expand Up @@ -71,7 +71,7 @@ and for enforcing [subject-holder relationships](https://www.w3.org/TR/vc-data-m

## Example

The following code showcases how an issuer can [create, sign](#create-and-sign-vc),
The following code showcases how an issuer can [create, sign](#create-and-sign-a-vc),
and [validate](#validate-a-vc) a verifiable credential.
In this example, the issuer signs a `UniversityDegreeCredential` with Alice's name and DID.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ import TabItem from '@theme/TabItem';

# Revoke a Verifiable Credential

The [example](#example) below demonstrates two methods that an issuer can use to revoke a verifiable credential
The [example](#full-example-code) below demonstrates two methods that an issuer can use to revoke a verifiable credential
using the IOTA Identity Framework:

1. By using the [`credentialStatus`](https://www.w3.org/TR/vc-data-model/#status) field in a credential and linking
Expand Down
Loading

0 comments on commit dadeb67

Please sign in to comment.