diff --git a/docs/docusaurus/connections/connection.md b/docs/docusaurus/connections/connection.md index 7d5cc1f6f0..08b3c642a4 100644 --- a/docs/docusaurus/connections/connection.md +++ b/docs/docusaurus/connections/connection.md @@ -2,15 +2,15 @@ A connection is a stateful relationship between two parties that enables secure communication. -The [Connection protocol](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#connection-protocol) is required to establish secure connections between agents, +The [Connection protocol](docs/concepts/glossary#connection-protocol) is required to establish secure connections between agents, allowing them to exchange information and interact. ## Roles The connection protocol has two roles: -1. [Inviter](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#inviter): A subject that initiates a connection request by sending a [connection invitation](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#connection-invitation). -2. [Invitee](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#connection-request). +1. [Inviter](docs/concepts/glossary#inviter): A subject that initiates a connection request by sending a [connection invitation](docs/concepts/glossary#connection-invitation). +2. [Invitee](docs/concepts/glossary#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](docs/concepts/glossary#connection-request). ## Prerequisites @@ -55,7 +55,7 @@ ConnectionResponseSent --> [*] 1. Receive the OOB invitation (`InvitationReceived` state) 2. Accept the invitation (connection is created in `ConnectionRequestPending` state) -3. Send the connection request via [DIDComm](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#didcomm) (connection achieves `ConnectionRequestSent` state) +3. Send the connection request via [DIDComm](docs/concepts/glossary#didcomm) (connection achieves `ConnectionRequestSent` state) 4. Receive the connection response (connection achieves `ConnectionResponseReceived` state) The following diagram represents the Invitee's Connection state transitions: diff --git a/docs/docusaurus/credentials/issue.md b/docs/docusaurus/credentials/issue.md index c9617ae686..dc34a4fb17 100644 --- a/docs/docusaurus/credentials/issue.md +++ b/docs/docusaurus/credentials/issue.md @@ -1,13 +1,13 @@ # Issue Credentials -In Atala PRISM, the [Issue Credentials Protocol](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credentials) between a VC issuer and a VC holder. +In Atala PRISM, the [Issue Credentials Protocol](docs/concepts/glossary#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](docs/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder. ## Roles In the Issue Credentials Protocol, there are two roles: -1. The [Issuer](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#issuer) is responsible for creating a new credential offer, sending it to a Holder, and issuing the VC once the offer is accepted. -2. The [Holder](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#holder) is responsible for accepting a credential offer from an issuer and receiving the VC. +1. The [Issuer](docs/concepts/glossary#issuer) is responsible for creating a new credential offer, sending it to a Holder, and issuing the VC once the offer is accepted. +2. The [Holder](docs/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and receiving the VC. The Issuer and Holder interact with the PRISM Agent API to perform the operations defined in the protocol. @@ -18,7 +18,7 @@ Before using the Issuing Credentials protocol, the following conditions must be 1. Issuer and Holder PRISM Agents up and running 2. A connection must be established between the Issuer and Holder PRISM Agents (see [Connections](../connections/connection.md)) -3. The Issuer must have a published PRISM DID, and the [DID document](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-document) must have at least one `assertionMethod` key for issuing credentials (see [Create DID](../dids/create.md) and [Publish DID](../dids/publish.md)) +3. The Issuer must have a published PRISM DID, and the [DID document](docs/concepts/glossary#did-document) must have at least one `assertionMethod` key for issuing credentials (see [Create DID](../dids/create.md) and [Publish DID](../dids/publish.md)) 4. The Holder must have a PRISM DID, and the DID document must have at least one `authentication` key for presenting the proof. ## Overview @@ -29,7 +29,7 @@ The protocol consists of the following main parts: 1. The Issuer creates a new credential offer using the [`/issue-credentials/credential-offers`](/agent-api/#tag/Issue-Credentials-Protocol/operation/createCredentialOffer) endpoint, which includes information such as the schema identifier and claims. 2. The Holder can then retrieve the offer using the [`/issue-credentials/records`](/agent-api/#tag/Issue-Credentials-Protocol/operation/getCredentialRecords) endpoint and accept the offer using the [`/issue-credentials/records/{recordId}/accept-offer`](/agent-api/#tag/Issue-Credentials-Protocol/operation/acceptCredentialOffer) endpoint. -3. The Issuer then uses the [`/issue-credentials/records/{recordId}/issue-credential`](/agent-api/#tag/Issue-Credentials-Protocol/operation/issueCredential) endpoint to issue the credential, which gets sent to the Holder via [DIDComm](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#didcomm). The Holder receives the credential, and the protocol is complete. +3. The Issuer then uses the [`/issue-credentials/records/{recordId}/issue-credential`](/agent-api/#tag/Issue-Credentials-Protocol/operation/issueCredential) endpoint to issue the credential, which gets sent to the Holder via [DIDComm](docs/concepts/glossary#didcomm). The Holder receives the credential, and the protocol is complete. The schema identifier defines the structure and the credential type issued, while the claims provide specific information about the individual, such as their name or qualifications. @@ -152,7 +152,7 @@ curl "http://localhost:8090/prism-agent/issue-credentials/records" \ To accept the offer, the Holder can make a `POST` request to the [`/issue-credentials/records/{recordId}/accept-offer`](/agent-api/#tag/Issue-Credentials-Protocol/operation/acceptCredentialOffer) endpoint with a JSON payload that includes the following information: 1. `holder_record_id`: The unique identifier of the issue credential record known by the holder PRISM Agent. -2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) string, such as `did:prism:subjectIdentifier`. +2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](docs/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`. ```shell # Holder POST request to accept the credential offer diff --git a/docs/docusaurus/credentials/present-proof.md b/docs/docusaurus/credentials/present-proof.md index 9665743a3e..e298036eed 100644 --- a/docs/docusaurus/credentials/present-proof.md +++ b/docs/docusaurus/credentials/present-proof.md @@ -1,8 +1,8 @@ # Present proof -The [Present Proof Protocol](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#present-proof-protocol) allows: -- a [Verifier](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifier) to request a verifiable credential presentation from a Holder/Prover -- a [Holder/Prover](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#holder) responds by presenting a cryptographic proof to the Verifier +The [Present Proof Protocol](docs/concepts/glossary#present-proof-protocol) allows: +- a [Verifier](docs/concepts/glossary#verifier) to request a verifiable credential presentation from a Holder/Prover +- a [Holder/Prover](docs/concepts/glossary#holder) responds by presenting a cryptographic proof to the Verifier The protocol provides endpoints for a Verifier to request new proof presentations from Holder/Provers and for a Holder/Prover to respond to the presentation request using a specific verifiable credential they own. @@ -11,7 +11,7 @@ The protocol provides endpoints for a Verifier to request new proof presentation The present proof protocol has two roles: 1. Verifier: A subject requesting a proof presentation by sending a request presentation message, then verifying the presentation. -2. Holder/Prover: A [subject](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#subject) that receives a [proof presentation](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message. +2. Holder/Prover: A [subject](docs/concepts/glossary#subject) that receives a [proof presentation](docs/concepts/glossary#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message. ## Prerequisites @@ -19,7 +19,7 @@ Before using the Proof Presentation protocol, the following conditions must be p 1. Holder/Prover and Verifier PRISM Agents must be up and running 2. A connection must be established between the Holder/Prover and Verifier PRISM Agents (see [Connections](../connections/connection.md)) -3. The Holder/Prover should hold a [verifiable credential (VC)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credential) received from an [Issuer](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#issuer) see [Issue](./issue.md). +3. The Holder/Prover should hold a [verifiable credential (VC)](docs/concepts/glossary#verifiable-credential) received from an [Issuer](docs/concepts/glossary#issuer) see [Issue](./issue.md). ## Overview diff --git a/docs/docusaurus/dids/create.md b/docs/docusaurus/dids/create.md index 244bb40fbf..01ec017dcf 100644 --- a/docs/docusaurus/dids/create.md +++ b/docs/docusaurus/dids/create.md @@ -1,16 +1,16 @@ # Create DID -PRISM DIDs are a type of [decentralized identifier (DID)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) used across the Atala PRISM product suite. +PRISM DIDs are a type of [decentralized identifier (DID)](docs/concepts/glossary#decentralized-identifier) used across the Atala PRISM product suite. -It is a variation of a [sidetree protocol](https://identity.foundation/sidetree/spec/) and uses the Cardano blockchain as the underlying ledger for [DID resolution](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-resolution) and operation publication. +It is a variation of a [sidetree protocol](https://identity.foundation/sidetree/spec/) and uses the Cardano blockchain as the underlying ledger for [DID resolution](docs/concepts/glossary#did-resolution) and operation publication. Please refer to the [PRISM method specification](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md) for a more detailed explanation of how it works. -PRISM DIDs can be created entirely offline without interacting with the blockchain by constructing a DID create-operation, a [protocol buffer (protobuf)](/documentation/docs/concepts/glossary.md#protocol-buffer) message with a set of public keys and services. +PRISM DIDs can be created entirely offline without interacting with the blockchain by constructing a DID create-operation, a [protocol buffer (protobuf)](docs/concepts/glossary#protocol-buffer) message with a set of public keys and services. Once the create-operation gets constructed, deriving a DID from this operation is possible, which is well-defined by the [PRISM DID method](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md). ## Roles -1. [DID Controller](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-controller) is the organization or individual who has control of the DID. +1. [DID Controller](docs/concepts/glossary#did-controller) is the organization or individual who has control of the DID. ## Prerequisites @@ -53,7 +53,7 @@ The result should show an empty list, as no DIDs exist on this PRISM Agent insta ### 2. Create a PRISM Agent managed DID using DID registrar endpoint -The DID controller can create a new DID by sending a [DID document](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-document) template to the Agent. +The DID controller can create a new DID by sending a [DID document](docs/concepts/glossary#did-document) template to the Agent. Since key pairs are generated and managed by PRISM Agent, DID controller only has to specify the key `id` and its purpose (e.g., `authentication`, `assertionMethod`, etc.). The current PRISM DID method supports a key with a single purpose, but it is extendible to support a key with multiple purposes in the future. diff --git a/docs/docusaurus/dids/deactivate.md b/docs/docusaurus/dids/deactivate.md index aaffb66a4a..e0fd276e58 100644 --- a/docs/docusaurus/dids/deactivate.md +++ b/docs/docusaurus/dids/deactivate.md @@ -1,7 +1,7 @@ # Deactivate DID DID deactivation is an important feature that provides greater control for managing digital identity. -DID deactivation can be helpful if the [DID](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) is compromised or unused. +DID deactivation can be helpful if the [DID](docs/concepts/glossary#decentralized-identifier) is compromised or unused. This feature is crucial for the security and risk management of identity owners. Similar to [DID update](./update.md), deactivating a PRISM DID is a process of putting deactivate-operation on the blockchain so that other participants know that the DID is no longer active. @@ -20,7 +20,7 @@ The PRISM DID method only allows published DID to be deactivated. ## Overview DID deactivation operates similarly to the DID update, where deactivate-operation publishes to the blockchain, and confirmation blocks must be created before participants consider it deactivated. -Once the DID is deactivated, all content in the [DID document](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-document) gets deleted, and no operation will affect the DID afterward. +Once the DID is deactivated, all content in the [DID document](docs/concepts/glossary#did-document) gets deleted, and no operation will affect the DID afterward. The same concept also holds for PRISM DID deactivation in that the fork can occur if any subsequent operation occurs before the operation is confirmed. Please refer to the `SECURE_DEPTH` parameter in [PRISM method - protocol parameters](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#versioning-and-protocol-parameters) for the number of confirmation blocks. At the time of writing, this number is 112 blocks. diff --git a/docs/docusaurus/dids/publish.md b/docs/docusaurus/dids/publish.md index 46b4cc731f..f9243d1d47 100644 --- a/docs/docusaurus/dids/publish.md +++ b/docs/docusaurus/dids/publish.md @@ -1,7 +1,7 @@ # Publish DID PRISM DID creation involves generating key pairs and additional data (e.g., services) to construct a create-operation. -The create-operation allows [DID Controller](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-controller) to derive two types of [DIDs](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifiers): +The create-operation allows [DID Controller](docs/concepts/glossary#did-controller) to derive two types of [DIDs](docs/concepts/glossary#decentralized-identifiers): 1. [Long-form DID](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#long-form-dids-unpublished-dids). It has the following format `did:prism::` 2. Short-form DID. It has the following format `did:prism:` @@ -117,7 +117,7 @@ Example response with status `PUBLISHED` } ``` -> **Note:** The `status` here is the internal status of the DID on the PRISM Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-resolution) metadata is for that purpose. +> **Note:** The `status` here is the internal status of the DID on the PRISM Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](docs/concepts/glossary#did-resolution) metadata is for that purpose. ### 4. Resolve a short-form DID diff --git a/docs/docusaurus/dids/update.md b/docs/docusaurus/dids/update.md index abd93fbea1..c9dcb16dec 100644 --- a/docs/docusaurus/dids/update.md +++ b/docs/docusaurus/dids/update.md @@ -1,11 +1,11 @@ # Update DID -PRISM DID method allows [DID Controller](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-controller) to update the content of the [DID document(https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#did-document) by constructing a DID update-operation. +PRISM DID method allows [DID Controller](docs/concepts/glossary#did-controller) to update the content of the [DID document(docs/concepts/glossary#did-document) by constructing a DID update-operation. The update-operation describes the update action on the DID document. For example, DID Controller can add a new key to the DID document by constructing an update-operation containing the `AddKeyAction`. It is also possible for DID Controller to compose multiple actions in the same update-operation. The [PRISM DID method - Update DID section](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#update-did) includes a complete list of supported update actions. -The PRISM DID method only allows published [DID](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) to be updated. +The PRISM DID method only allows published [DID](docs/concepts/glossary#decentralized-identifier) to be updated. Each DID update-operation is cryptographically linked, creating a lineage of DID operations. The lineage is not allowed to contain forks. diff --git a/docs/docusaurus/index.md b/docs/docusaurus/index.md index 1ac30a8c06..13d47edf52 100644 --- a/docs/docusaurus/index.md +++ b/docs/docusaurus/index.md @@ -3,9 +3,9 @@ Welcome to the Atala PRISM Tutorials! These tutorials will help you get started with using Atala PRISM. -The tutorials will guide you through setting up a connection, working with [Decentralized Identifiers (DIDs)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifer), and using [verifiable credentials](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credentials). +The tutorials will guide you through setting up a connection, working with [Decentralized Identifiers (DIDs)](docs/concepts/glossary#decentralized-identifer), and using [verifiable credentials](docs/concepts/glossary#verifiable-credentials). -Whether you are new to [self-sovereign identity (SSI)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#self-sovereign-identity) or have prior experience, these tutorials will provide the necessary information and skills to build and use SSI-based applications. +Whether you are new to [self-sovereign identity (SSI)](docs/concepts/glossary#self-sovereign-identity) or have prior experience, these tutorials will provide the necessary information and skills to build and use SSI-based applications. Throughout all code examples in tutorials, the following conventions are in use: diff --git a/docs/docusaurus/schemas/create.md b/docs/docusaurus/schemas/create.md index 9c7bd0f462..bcdbdd0c03 100644 --- a/docs/docusaurus/schemas/create.md +++ b/docs/docusaurus/schemas/create.md @@ -1,6 +1,6 @@ # Create the credential schema -The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential schema](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#credential-schema) records. +The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential schema](docs/concepts/glossary#credential-schema) records. The OpenAPI specification and ReDoc documentation describe the endpoint. @@ -12,7 +12,7 @@ The following guide demonstrates how to create a driving license credential sche ### 1. Define the JSON Schema for the Verifiable Credential -Assume that you need a credential schema for the driving license, and the [verifiable credential](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credential) must have the following +Assume that you need a credential schema for the driving license, and the [verifiable credential](docs/concepts/glossary#verifiable-credential) must have the following fields: - emailAddress - the email address of the driver @@ -340,7 +340,7 @@ The response should contain the JSON object representing the schema you just cre ``` The PRISM Agent instance's triple `author`, `id`, and `version` are unique. -So, having a single [DID](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) reference that the author uses, creating the credential schema with the same `id` and `version` +So, having a single [DID](docs/concepts/glossary#decentralized-identifier) reference that the author uses, creating the credential schema with the same `id` and `version` is impossible. ### 4. Update the credential schema diff --git a/docs/docusaurus/schemas/credential-schema.md b/docs/docusaurus/schemas/credential-schema.md index 3a9c3fab48..6e334bbba5 100644 --- a/docs/docusaurus/schemas/credential-schema.md +++ b/docs/docusaurus/schemas/credential-schema.md @@ -7,8 +7,8 @@ the Atala PRISM Platform. ## 1. Introduction -[Credential Schema](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#credential-schema) is a data template for [Verifiable Credentials](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credential). -It contains [claims](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#claims) (attributes) of the Verifiable Credentials, credential schema author, type, name, version, and proof +[Credential Schema](docs/concepts/glossary#credential-schema) is a data template for [Verifiable Credentials](docs/concepts/glossary#verifiable-credential). +It contains [claims](docs/concepts/glossary#claims) (attributes) of the Verifiable Credentials, credential schema author, type, name, version, and proof of authorship. By putting schema definitions on a public blockchain, they are available for all verifiers to examine to determine the semantic interoperability of the Credential. @@ -38,7 +38,7 @@ Limitations and constraints of the PRISM Platform v2.0: ### Credential Schema -The Credential Schema is a template that defines a set of attributes the [Issuer](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#issuer) uses to issue the Verifiable Credential. +The Credential Schema is a template that defines a set of attributes the [Issuer](docs/concepts/glossary#issuer) uses to issue the Verifiable Credential. ### Schema Registry @@ -46,7 +46,7 @@ The registry is where the Credential Schema is published and available for parti ### Issuer, Holder, Verifier -These are well-known roles in the [SSI](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#self-sovereign-identity) domain. +These are well-known roles in the [SSI](docs/concepts/glossary#self-sovereign-identity) domain. ## 2. Credential Schema Attributes @@ -61,7 +61,7 @@ The locally unique identifier of the schema. ### longId (String) -Resource identifier of the given credential schema composed from the author's [DID]((https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#decentralized-identifier) reference, id, and version fields. +Resource identifier of the given credential schema composed from the author's [DID]((docs/concepts/glossary#decentralized-identifier) reference, id, and version fields. **Example:** `{author}/{id}?version={version}` > **Note:** According to the [W3C specification](https://w3c-ccg.github.io/vc-json-schemas/#id), this field is locally unique and combines the Issuer `DID`, `uuid`, and `version`. diff --git a/docs/docusaurus/schemas/delete.md b/docs/docusaurus/schemas/delete.md index 6244eaf82a..da4fa21ed5 100644 --- a/docs/docusaurus/schemas/delete.md +++ b/docs/docusaurus/schemas/delete.md @@ -1,6 +1,6 @@ # Delete the credential schema -Unfortunately, after publishing (especially in the [Verifiable Data Registry (VDR)](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-data-registry), deleting the credential schema is impossible. +Unfortunately, after publishing (especially in the [Verifiable Data Registry (VDR)](docs/concepts/glossary#verifiable-data-registry), deleting the credential schema is impossible. PRISM Platform v2.0 doesn't publish the credential schema in the VDR. This capability will get implemented in the later version of the platform. That's why the platform does not expose the REST API for deletion. diff --git a/docs/docusaurus/schemas/update.md b/docs/docusaurus/schemas/update.md index 0e42ea4220..ca0392030f 100644 --- a/docs/docusaurus/schemas/update.md +++ b/docs/docusaurus/schemas/update.md @@ -16,7 +16,7 @@ The following guide demonstrates how to update a driving license credential sche ### 1. Define the updated JSON Schema for the Verifiable Credential Assume that you need to update the credential schema from the previous tutorial. -So, there is an existing driving license, and the [verifiable credential](https://github.com/input-output-hk/atala-prism-docs/blob/main/documentation/docs/concepts/glossary.md#verifiable-credential) must additionally include two fields: +So, there is an existing driving license, and the [verifiable credential](docs/concepts/glossary#verifiable-credential) must additionally include two fields: - bloodType - the blood type of the driver - organDonor - indicates whether or not the person is an organ donor