From 5aa403ee52215944e49f15d3973b8b76a7641d20 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 00:59:50 +0300 Subject: [PATCH 01/69] ARC 113 initial commit --- ARCs/arc-0113.md | 135 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 ARCs/arc-0113.md diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md new file mode 100644 index 000000000..491707e12 --- /dev/null +++ b/ARCs/arc-0113.md @@ -0,0 +1,135 @@ +--- +arc: 113 +title: Verifiable Credentials (VCs) +description: Verifiable Credentials V 2.0 living standard metadata conventions for Algorand blockchain identified (DIDed) elements, urls and URIs. +author: MG (@emg110) +status: Draft +type: Standards Track +category: Data Models +created: 2023-12-18 +--- + +## Abstract + +This standard represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. It is implemented as an extension to: +- [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) +- [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) +- [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) + +And in compliance with: +- [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) +- [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) + +## Specification + +The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability, and the ability to be used in conjunction with DID documents (ARC13), which are essential for verifiable digital identity and decentralized authentication, verification, and presentations. + +### Concept diagram of VCs on Algorand: +```mermaid +flowchart LR + subgraph vc ["Verifiable Credential"] + issuer["Issuer"] -->|Issues| credential["Credential"] + subject["Subject"] -->|Subject of| credential + credential -->|Presented by| holder["Holder"] + + proof -->|Signed by| verifier["Verifier"] + proof -->|Proof of| credential + end + + holder -->|Presents to| verifier["Verifier"] + verifier -->|Verifies| credential + + style vc stroke:#333,stroke-width:2px +``` + +### Flow diagram of VCs on Algorand: + +```mermaid +flowchart LR + holder["Holder"] -->|Requests Credential| issuer["Issuer"] + issuer -->|Issues Credential| holder + holder -->|Creates Presentation| presentation["Verifiable Presentation"] + presentation -->|Presents to| verifier["Verifier"] + verifier -->|Verifies Presentation| presentation + verifier -->|Optionally, Verifies Credential| credential["Verifiable Credential"] + credential -->|Issued by| issuer + + style presentation stroke:#333,stroke-width:2px + +``` +### General Format + +All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MAY," "MUST," "MUST NOT," "OPTIONAL," "RECOMMENDED," "REQUIRED," "SHOULD," and "SHOULD NOT" in this document are to be interpreted as described in [BCP 14 RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here. + +Algorand DID elements used by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. + +Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. + +### Metadata Grammar + +The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. + +### Main Elements + + + +The main types for Verifiable Credentials on Algorand include: +- Verifiable Credentials: + +Verifiable Credentials include Verifiable claims and after review and verify by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and Algorand blockchain. + +```mermaid +flowchart TB + vcs["Verifiable Credential"] --> metadata["Credential Metadata"] + vcs["Verifiable Credential"] --> claims["Claims"] + vcs["Verifiable Credential"] --> proofs["Proofs"] +``` +- Verifiable presentations: + Verifiable Presentations are documents containing VCs to be presented for verification and signing which adds the proof for VCs. + +```mermaid +flowchart TB + vcs["Verifiable Presentation"] --> metadata["Presentation Metadata"] + vcs["Verifiable Presentation"] --> credentials["Verifiable Credentials"] + vcs["Verifiable Presentation"] --> proofs["Proofs"] +``` + +- **Credential Subject**: Identifies the entity the credential is about, which can be linked to an Algorand DID. +- **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. +- **Issuance Date**: The date on which the credential was issued. +- **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. + +The Algorand elements which are used to construct these main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): + +- Algorand DID URI: This is the unique identifier for a subject within the Algorand ecosystem. It follows the standard DID format but is specific to Algorand. + +- Algorand DID Document: This document contains information associated with the Algorand DID, such as verification methods and service endpoints. + +- DID Subject: The entity that the DID represents, which could be a user, an asset, an application, or any identifiable entity on Algorand. + +- DID Controller: The entity that has the capability to make changes to the DID document. This could be the DID subject itself or another authorized entity. + +- Verifiable Data Registry (Algorand Blockchain): The Algorand blockchain acts as the verifiable data registry where DIDs are recorded and can be looked up. GoPlausible API and ABI are the service interfaces delivering this facility and PLAUSIBLE protocol has expanded to include this role on Algorand blockchain as first Verifiable Data Registry! + +- DID Resolver: A system component that takes a DID as input and produces the corresponding DID document as output. GoPlausible API and ABI now include Algorand DID resolver endpoints and also there is a universal ES module (JS) client library [algo-did-resolver](https://www.npmjs.com/package/algo-did-resolver)for dApp integration on client side, available through NPM! + +## Rationale + +The rationale behind ARC113 is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, ARC113 ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. +All protocols and projects on Algorand can use and benefit from VCs on Algorand to make their protocols and dApps more compliant to regulations , e.g GDPR and EU Blockchain regulations! + +Especially for adoption by global organizations, this becomes a must that ecosystem offers integration, adoption and interoperability with Verifiable Credentials as they are widely in use and are common best practice in Web 2.0 as well! + +## Security Considerations + +Security considerations for ARC113 include ensuring the integrity and confidentiality of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. + +## Appendix + +Examples of verifiable credentials and presentations in JSON-LD format will be provided, demonstrating the application of ARC113 in real-world scenarios. + +## Copyright + +This document and its content are released under the Creative Commons Zero (CC0) license, allowing for maximum flexibility and adoption within the Algorand community and beyond. + +Copyright and related rights waived via [CCO](https://creativecommons.org/publicdomain/zero/1.0/). From 39bb1ac283b7e764fe22bc2b7b0ca3d8a79b682f Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 18:34:21 +0300 Subject: [PATCH 02/69] Update --- ARCs/arc-0113.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 491707e12..a684f1695 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -1,11 +1,11 @@ --- arc: 113 title: Verifiable Credentials (VCs) -description: Verifiable Credentials V 2.0 living standard metadata conventions for Algorand blockchain identified (DIDed) elements, urls and URIs. -author: MG (@emg110) +description: Verifiable Credentials V 2.0 living standard URI and metadata model conventions for Algorand blockchain identified (or DIDed) elements. +author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track -category: Data Models +category: URI Scheme & Metadata Model created: 2023-12-18 --- From 0249bab65c11daa0ec75111384060aad8f6538ce Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 18:38:07 +0300 Subject: [PATCH 03/69] Update --- ARCs/arc-0113.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a684f1695..b6b292617 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. It is implemented as an extension to: +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. It is implemented as an extension to: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) @@ -20,6 +20,8 @@ And in compliance with: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) +Note: WORK IN PROGRESS! + ## Specification The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability, and the ability to be used in conjunction with DID documents (ARC13), which are essential for verifiable digital identity and decentralized authentication, verification, and presentations. From e9f12a536f288b6af96d7322cd28e19893bb5d81 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 18:44:59 +0300 Subject: [PATCH 04/69] Update --- ARCs/arc-0113.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index b6b292617..4bbd07a90 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -5,7 +5,7 @@ description: Verifiable Credentials V 2.0 living standard URI and metadata model author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track -category: URI Scheme & Metadata Model +category: Credentials & Metadata Model created: 2023-12-18 --- @@ -20,7 +20,7 @@ And in compliance with: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) -Note: WORK IN PROGRESS! +NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification From 11fdee37b5d61fb825268d09fbb5f304ef310519 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:00:04 +0300 Subject: [PATCH 05/69] Update --- ARCs/arc-0113.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 4bbd07a90..d0f9bd303 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -20,6 +20,10 @@ And in compliance with: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) +The goal to ARC113 is first to make VerifiableCredentials available for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and globally with each and in a decentralized way! + +Important note: ARC113 tries to follow a micro architecture and plugnplay approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verifications and assertions! + NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification From 69e5796ce122968e89723b3ee8577098e2606b9d Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:04:35 +0300 Subject: [PATCH 06/69] Update --- ARCs/arc-0113.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index d0f9bd303..3a261e1fe 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -16,7 +16,11 @@ This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 D - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) -And in compliance with: +This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE! + +ARC 113 by using ARC13 as DID standard and implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) + +ARC113 is in full compliance to: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) From 577b709d7e719923effd150eb49b5259914c6329 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:09:06 +0300 Subject: [PATCH 07/69] Update --- ARCs/arc-0113.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 3a261e1fe..0a3fbf0f1 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,10 +11,17 @@ created: 2023-12-18 ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. It is implemented as an extension to: +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. + +ARC113 can be implemented using/for ARC ASAs as an extension! Including support for: + - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) +- [ARC72](https://arc.algorand.foundation/ARCs/arc-0069) +- [ARC200](https://arc.algorand.foundation/ARCs/arc-0069) + +ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and achievements to proceed on both proofs and integrity parts! This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE! From 8f08e5b241ff9a7c239d7f365a043f84d3453062 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:12:40 +0300 Subject: [PATCH 08/69] Update --- ARCs/arc-0113.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 0a3fbf0f1..977d813ab 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -1,11 +1,11 @@ --- arc: 113 title: Verifiable Credentials (VCs) -description: Verifiable Credentials V 2.0 living standard URI and metadata model conventions for Algorand blockchain identified (or DIDed) elements. -author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital +description: Verifiable Credentials V 2.0 living standard for Algorand blockchain. +author: MG (@emg110), @GoPlausible, @VoiNetwork, @GoraNetwork, @DaffiDigital status: Draft type: Standards Track -category: Credentials & Metadata Model +category: Credentials Conventions and Data model created: 2023-12-18 --- From d41fc44d233c444768d2f4b3df059264c1092d76 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:14:40 +0300 Subject: [PATCH 09/69] Update order --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 977d813ab..422ddf013 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -2,7 +2,7 @@ arc: 113 title: Verifiable Credentials (VCs) description: Verifiable Credentials V 2.0 living standard for Algorand blockchain. -author: MG (@emg110), @GoPlausible, @VoiNetwork, @GoraNetwork, @DaffiDigital +author: MG (@emg110), @VoiNetwork, @GoraNetwork, @DaffiDigital, @GoPlausible status: Draft type: Standards Track category: Credentials Conventions and Data model From 865e783db451022c94165fedf8426401a43a907b Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:19:59 +0300 Subject: [PATCH 10/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 422ddf013..009dbffca 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) living standard's requirements and conventions using Algorand blockchain elements, methods as well as other ARCs. +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) , [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) and [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) living standards requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as other ARCs. ARC113 can be implemented using/for ARC ASAs as an extension! Including support for: From 551b5708a659f99b592903b88ea46ee4d1869d2b Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:21:07 +0300 Subject: [PATCH 11/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 009dbffca..a6b9cad33 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -21,7 +21,7 @@ ARC113 can be implemented using/for ARC ASAs as an extension! Including support - [ARC72](https://arc.algorand.foundation/ARCs/arc-0069) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0069) -ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and achievements to proceed on both proofs and integrity parts! +ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE! From 31b17ad510fe89739eb301f96eb9a566a6571b47 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 16:24:49 +0300 Subject: [PATCH 12/69] Update --- ARCs/arc-0113.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a6b9cad33..a0d24274a 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -25,7 +25,7 @@ ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE! -ARC 113 by using ARC13 as DID standard and implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) +ARC 113 by using ARC13 as DID standard and reference implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) as well! ARC113 is in full compliance to: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) @@ -33,13 +33,13 @@ ARC113 is in full compliance to: The goal to ARC113 is first to make VerifiableCredentials available for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and globally with each and in a decentralized way! -Important note: ARC113 tries to follow a micro architecture and plugnplay approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verifications and assertions! +Important note: ARC113 tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! -NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! +NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification -The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability, and the ability to be used in conjunction with DID documents (ARC13), which are essential for verifiable digital identity and decentralized authentication, verification, and presentations. +The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoprability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. ### Concept diagram of VCs on Algorand: ```mermaid From 4a83834b2174740f56b81dea4153fdd2d7df5973 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 16:25:02 +0300 Subject: [PATCH 13/69] Fix typo --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a0d24274a..13fd34c9a 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -39,7 +39,7 @@ NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification -The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoprability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. +The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. ### Concept diagram of VCs on Algorand: ```mermaid From eefc9e9ee972ef48161dbd0847901fc3d736922e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 11:16:58 +0300 Subject: [PATCH 14/69] Update --- ARCs/arc-0113.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 13fd34c9a..adf187a4e 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,7 +11,9 @@ created: 2023-12-18 ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) , [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) and [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) living standards requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as other ARCs. +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) , [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) and [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) living standards requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. + +ARC113 introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! ARC113 can be implemented using/for ARC ASAs as an extension! Including support for: @@ -23,7 +25,7 @@ ARC113 can be implemented using/for ARC ASAs as an extension! Including support ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! -This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE! +This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE only! ARC 113 by using ARC13 as DID standard and reference implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) as well! From 2b04e75edffb65407c8e6c0459849169533c4738 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 11:18:52 +0300 Subject: [PATCH 15/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index adf187a4e..03a5c482f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -33,7 +33,7 @@ ARC113 is in full compliance to: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) -The goal to ARC113 is first to make VerifiableCredentials available for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and globally with each and in a decentralized way! +The goal to ARC113 is first to adopt VerifiableCredentials standards for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and generated dynamically for each transaction using either an API or an ABI! Important note: ARC113 tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! From 31bf66ae5b86cf14dfd6deb7d2872eeda7d8ca1a Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 11:20:43 +0300 Subject: [PATCH 16/69] Update --- ARCs/arc-0113.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 03a5c482f..1740bf560 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -90,8 +90,6 @@ The metadata for verifiable credentials on Algorand will adhere to the standards ### Main Elements - - The main types for Verifiable Credentials on Algorand include: - Verifiable Credentials: From f0440291714f6f16956aae391a129c48caea756f Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 11:30:07 +0300 Subject: [PATCH 17/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 1740bf560..55804e453 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) , [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/) and [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) living standards requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/)living standards and also [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) draft's, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. ARC113 introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! From 6aaa756e428aa9a3957b3612c993679a6783da2a Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:00:32 +0300 Subject: [PATCH 18/69] Update --- ARCs/arc-0113.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 55804e453..947bdca16 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -43,7 +43,15 @@ NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -### Concept diagram of VCs on Algorand: +### Verifiable Credential main elements and flow: +- **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like oraganizations, groups, universities, NGOs, DAOs, societies, clubs and ...! +- **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. +- **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. +- **Verifier**: An atomic or composite DID available on AVM ledger receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include universities, governments, and banks. +- **Verifiable data registry**: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem. + + + ```mermaid flowchart LR subgraph vc ["Verifiable Credential"] @@ -61,7 +69,7 @@ flowchart LR style vc stroke:#333,stroke-width:2px ``` -### Flow diagram of VCs on Algorand: +Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. ```mermaid flowchart LR From 4f3064b2896c3a7021eb577735d6f99d38c5413e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:01:03 +0300 Subject: [PATCH 19/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 947bdca16..05ffef98c 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -43,7 +43,7 @@ NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -### Verifiable Credential main elements and flow: +## Verifiable Credentials main elements & flow: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like oraganizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. From 241e75c3d1f996106228db170e2d50eef073eed0 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:05:23 +0300 Subject: [PATCH 20/69] Update --- ARCs/arc-0113.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 05ffef98c..431f30fc4 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -43,7 +43,7 @@ NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -## Verifiable Credentials main elements & flow: +### Verifiable Credentials: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like oraganizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. @@ -51,7 +51,6 @@ The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials - **Verifiable data registry**: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem. - ```mermaid flowchart LR subgraph vc ["Verifiable Credential"] @@ -96,7 +95,7 @@ Elements of the query component may contain characters outside the valid range. The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. -### Main Elements +### VC Document Elements The main types for Verifiable Credentials on Algorand include: - Verifiable Credentials: From eb558c97922bbccefda48178de61330b7140f09b Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:25:46 +0300 Subject: [PATCH 21/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 431f30fc4..a5a8b0fce 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -95,7 +95,7 @@ Elements of the query component may contain characters outside the valid range. The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. -### VC Document Elements +### VC Document Types The main types for Verifiable Credentials on Algorand include: - Verifiable Credentials: From ad36654553efdf4a34e86a21bebbd41b7e6ab79a Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:28:14 +0300 Subject: [PATCH 22/69] Update --- ARCs/arc-0113.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a5a8b0fce..f90dd44a1 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -97,8 +97,9 @@ The metadata for verifiable credentials on Algorand will adhere to the standards ### VC Document Types -The main types for Verifiable Credentials on Algorand include: -- Verifiable Credentials: +The main types for Verifiable Credential documents on AVM chains include: + +- Verifiable Claims: Verifiable Credentials include Verifiable claims and after review and verify by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and Algorand blockchain. From 7211ac1e6b00f9b764536e1763dc361b82235b8c Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:31:16 +0300 Subject: [PATCH 23/69] Update --- ARCs/arc-0113.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index f90dd44a1..eef8a90d2 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -39,11 +39,19 @@ Important note: ARC113 tries to follow a micro architecture and plug and play ap NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! +### General Format + +All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MAY," "MUST," "MUST NOT," "OPTIONAL," "RECOMMENDED," "REQUIRED," "SHOULD," and "SHOULD NOT" in this document are to be interpreted as described in [BCP 14 RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here. + +Algorand DID elements used by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. + +Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. + ## Specification The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -### Verifiable Credentials: +### Verifiable Credentials Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like oraganizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. @@ -83,25 +91,17 @@ flowchart LR style presentation stroke:#333,stroke-width:2px ``` -### General Format - -All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MAY," "MUST," "MUST NOT," "OPTIONAL," "RECOMMENDED," "REQUIRED," "SHOULD," and "SHOULD NOT" in this document are to be interpreted as described in [BCP 14 RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here. - -Algorand DID elements used by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. - -Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. - ### Metadata Grammar The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. -### VC Document Types +### Verifiable Credential lifecycle elements The main types for Verifiable Credential documents on AVM chains include: - Verifiable Claims: -Verifiable Credentials include Verifiable claims and after review and verify by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and Algorand blockchain. +Verifiable Credentials include Verifiable claims and after review and verify by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain. ```mermaid flowchart TB From 49acb1586c9d12d2897a03e87675636d42450c8c Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:36:07 +0300 Subject: [PATCH 24/69] Update --- ARCs/arc-0113.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index eef8a90d2..a6e7687e3 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -124,7 +124,8 @@ flowchart TB - **Issuance Date**: The date on which the credential was issued. - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. -The Algorand elements which are used to construct these main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): +### Verifiable Credential implementation +Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): - Algorand DID URI: This is the unique identifier for a subject within the Algorand ecosystem. It follows the standard DID format but is specific to Algorand. From 9f5d91a18acbbed8e4f80984be0398f0c01ae7c0 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:36:27 +0300 Subject: [PATCH 25/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a6e7687e3..9c1a6c48e 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -124,7 +124,7 @@ flowchart TB - **Issuance Date**: The date on which the credential was issued. - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. -### Verifiable Credential implementation +### Verifiable Credential requirements Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): - Algorand DID URI: This is the unique identifier for a subject within the Algorand ecosystem. It follows the standard DID format but is specific to Algorand. From 6e7e398b88ebe249e2979fce179c7f706dac2e17 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:38:23 +0300 Subject: [PATCH 26/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 9c1a6c48e..eff8dd8b4 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -144,7 +144,7 @@ Required decentralized identifiers and implementations which are used to constru The rationale behind ARC113 is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, ARC113 ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. All protocols and projects on Algorand can use and benefit from VCs on Algorand to make their protocols and dApps more compliant to regulations , e.g GDPR and EU Blockchain regulations! -Especially for adoption by global organizations, this becomes a must that ecosystem offers integration, adoption and interoperability with Verifiable Credentials as they are widely in use and are common best practice in Web 2.0 as well! +Especially for adoption by global organizations, this becomes a requirement that ecosystem offers integration, adoption and interoperability with Verifiable Credentials as they are widely in use and are common best practice in Web 2.0 as well! ## Security Considerations From 12be73dac50a80ed564b9f01972a2f82e688f5e2 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:39:26 +0300 Subject: [PATCH 27/69] Fixed Typo --- ARCs/arc-0113.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index eff8dd8b4..0c961eb5b 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -148,11 +148,11 @@ Especially for adoption by global organizations, this becomes a requirement that ## Security Considerations -Security considerations for ARC113 include ensuring the integrity and confidentiality of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. +Security considerations for ARC113 include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. ## Appendix -Examples of verifiable credentials and presentations in JSON-LD format will be provided, demonstrating the application of ARC113 in real-world scenarios. +Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of ARC113 in real-world scenarios. ## Copyright From 8205173dcf2bf15f3a9c0c054291bb040bfae4e4 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:40:33 +0300 Subject: [PATCH 28/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 0c961eb5b..ec5b6ef6b 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -1,7 +1,7 @@ --- arc: 113 title: Verifiable Credentials (VCs) -description: Verifiable Credentials V 2.0 living standard for Algorand blockchain. +description: Verifiable Credentials V 2.0 living standard for Algorand. author: MG (@emg110), @VoiNetwork, @GoraNetwork, @DaffiDigital, @GoPlausible status: Draft type: Standards Track From 67dc4b123a5a2fe97c458703b9ac4eae95004804 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:50:31 +0300 Subject: [PATCH 29/69] Update --- ARCs/arc-0113.md | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index ec5b6ef6b..64ff558b3 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -57,7 +57,34 @@ The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. - **Verifier**: An atomic or composite DID available on AVM ledger receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include universities, governments, and banks. - **Verifiable data registry**: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem. - + +### VC necessities specification: + +- Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner. +- Holders can assemble collections of verifiable credentials from different issuers into a single artifact, a verifiable presentation. +- Issuers can issue verifiable credentials about any subject. +- Acting as issuer, holder, or verifier requires neither registration nor approval by any authority, as the trust involved is bilateral between parties. +- Verifiable presentations allow any verifier to verify the authenticity of verifiable credentials from any issuer. +- Holders can receive verifiable credentials from anyone. +- Holders can interact with any issuer and any verifier through any user agent. +- Holders can share verifiable presentations, which can then be verified without revealing the identity of the verifier to the issuer. +- Holders can store verifiable credentials in any location, without affecting their verifiability and without the issuer knowing anything about where they are stored or when they are accessed. +- Holders can present verifiable presentations to any verifier without affecting authenticity of the claims and without revealing that action to the issuer. +- A verifier can verify verifiable presentations from any holder, containing proofs of claims from any issuer. +- Verification should not depend on direct interactions between issuers and verifiers. +- Verification should not reveal the identity of the verifier to any issuer. +The specification must provide a means for issuers to issue verifiable credentials that support selective disclosure, without requiring all conformant software to support that feature. +- Issuers can issue verifiable credentials that support selective disclosure. +If a single verifiable credential supports selective disclosure, then holders can present proofs of claims without revealing the entire verifiable credential. +- Verifiable presentations can either disclose the attributes of a verifiable credential, or satisfy derived predicates requested by the verifier. Derived predicates are Boolean conditions, such as greater than, less than, equal to, is in set, and so on. +Issuers can issue revocable verifiable credentials. +- The processes of cryptographically protecting and verifying verifiable credentials and verifiable presentations have to be deterministic, bi-directional, and lossless. Any verifiable credential or verifiable presentation has to be transformable to the JSON-LD data model defined in this document via a deterministic process so that its verification can be processed in an interoperable fashion. +- Verifiable credentials and verifiable presentations have to be serializable in one or more machine-readable data formats. The process of serialization and/or de-serialization has to be deterministic, bi-directional, and lossless. Any serialization of a verifiable credential or verifiable presentation needs to be transformable to the generic data model defined in this document in a deterministic process such that the resulting verifiable credential can be processed in an interoperable fashion. The serialized form also needs to be able to be generated from the data model without loss of data or content. +- The data model and serialization must be extendable with minimal coordination. +- Revocation by the issuer should not reveal any identifying information about the subject, the holder, the specific verifiable credential, or the verifier. +- Issuers can disclose the revocation reason. +- Issuers revoking verifiable credentials should distinguish between revocation for cryptographic integrity (for example, the signing key is compromised) versus revocation for a status change (for example, the driver's license is suspended). +- Issuers can provide a service for refreshing a verifiable credential. ```mermaid flowchart LR From ca071712825b562086058b3ea2b94871408d45b8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 13:53:51 +0300 Subject: [PATCH 30/69] Update --- ARCs/arc-0113.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 64ff558b3..a17818051 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -47,6 +47,12 @@ Algorand DID elements used by this ARC follow the URI format in general as outli Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. +A conforming document is a compacted JSON-LD document that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 4. Basic Concepts, 5. Advanced Concepts, and 6. Syntaxes of this document MUST be enforced. A conforming document is either a verifiable credential that MUST be serialized using the application/vc+ld+json media type or a verifiable presentation that MUST be serialized using the application/vp+ld+json media type. A conforming document MUST be secured by at least one securing mechanisms mentioned by this document! + +A conforming issuer implementation produces conforming documents, MUST include all required properties in the conforming documents that it produces, and MUST secure the conforming documents it produces using a securing mechanism as described in securing mechanisms mentioned by this document. + +A conforming verifier implementation consumes conforming documents, MUST perform verification on a conforming document as described in securing mechanisms in this document, MUST check that each required property satisfies the normative requirements for that property, and MUST produce errors when non-conforming documents are detected. + ## Specification The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. From c858539794c6438e98c168a218a39f3f0cc27c52 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:22:10 +0300 Subject: [PATCH 31/69] Fix typo --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a17818051..a760ba31c 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -58,7 +58,7 @@ A conforming verifier implementation consumes conforming documents, MUST perform The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. ### Verifiable Credentials Specification: -- **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like oraganizations, groups, universities, NGOs, DAOs, societies, clubs and ...! +- **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. - **Verifier**: An atomic or composite DID available on AVM ledger receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include universities, governments, and banks. From 94db81a1de7adbbacf269fa0097e3b91fe49c8e8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:26:52 +0300 Subject: [PATCH 32/69] Update --- ARCs/arc-0113.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a760ba31c..9ab1209fc 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -57,7 +57,7 @@ A conforming verifier implementation consumes conforming documents, MUST perform The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -### Verifiable Credentials Specification: +### Verifiable Credentials elements Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. @@ -128,7 +128,7 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. -### Verifiable Credential lifecycle elements +### Verifiable Credential document lifecycle The main types for Verifiable Credential documents on AVM chains include: From 2375171cc7079be50d68eed9439894d64ec63fa6 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:36:38 +0300 Subject: [PATCH 33/69] Update --- ARCs/arc-0113.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 9ab1209fc..4075c5e6a 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -57,14 +57,14 @@ A conforming verifier implementation consumes conforming documents, MUST perform The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -### Verifiable Credentials elements Specification: +### Verifiable Credentials ecosystem Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. - **Subject**: An atomic or composite DID available on AVM ledger, about which claims are made. Example subjects include human beings, animals, and things tagged with DIDs. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, an account DID (the holder) might hold the verifiable credentials of a NFT (the subject), or a TravelX ticket owner (the holder) might hold the verifiable credentials of their ticket (the subject), presentable everywhere from airport to vacation lottery websites. - **Verifier**: An atomic or composite DID available on AVM ledger receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include universities, governments, and banks. - **Verifiable data registry**: A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem. -### VC necessities specification: +### Verifiable Credentials necessities specification: - Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner. - Holders can assemble collections of verifiable credentials from different issuers into a single artifact, a verifiable presentation. @@ -156,6 +156,18 @@ flowchart TB - **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. - **Issuance Date**: The date on which the credential was issued. - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. +### Verifiable Credential document elements + +- **Credential Metadata**: VC inclusive metadata (Issuer, Issuance Date,...). +- **Claims**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. +- **Proofs**: Cryptographic proof that verifies the authenticity of the credential and claims, such as digital signatures. + +```mermaid +flowchart TB + vcs["Verifiable Credential"] --> metadata[Verifiable Credential metadata] + vcs["Verifiable Credential"] --> claims[Verifiable Credential Claims] + vcs["Verifiable Credential"] --> proofs[Verifiable Credential Proofs] +``` ### Verifiable Credential requirements Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): From ccca8f2581b7ff55d91a62b396524a342e3131a6 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:43:55 +0300 Subject: [PATCH 34/69] Update --- ARCs/arc-0113.md | 64 ++++++++++++++++++++++++------------------------ 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 4075c5e6a..49eac515f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -132,42 +132,42 @@ The metadata for verifiable credentials on Algorand will adhere to the standards The main types for Verifiable Credential documents on AVM chains include: -- Verifiable Claims: - -Verifiable Credentials include Verifiable claims and after review and verify by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain. - -```mermaid -flowchart TB - vcs["Verifiable Credential"] --> metadata["Credential Metadata"] - vcs["Verifiable Credential"] --> claims["Claims"] - vcs["Verifiable Credential"] --> proofs["Proofs"] -``` -- Verifiable presentations: +- Verifiable Claims document: + + Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain. + + ```mermaid + flowchart TB + vcs["Verifiable Claim"] --> metadata["Credential Metadata"] + vcs["Verifiable Claim"] --> claims["Claims"] + ``` +- Verifiable presentation document: Verifiable Presentations are documents containing VCs to be presented for verification and signing which adds the proof for VCs. -```mermaid -flowchart TB - vcs["Verifiable Presentation"] --> metadata["Presentation Metadata"] - vcs["Verifiable Presentation"] --> credentials["Verifiable Credentials"] - vcs["Verifiable Presentation"] --> proofs["Proofs"] -``` + ```mermaid + flowchart TB + vcs["Verifiable Presentation"] --> metadata["Presentation Metadata"] + vcs["Verifiable Presentation"] --> credentials["Verifiable Credentials"] + vcs["Verifiable Presentation"] --> proofs["Proofs"] + ``` + + - **Credential Subject**: Identifies the entity the credential is about, which can be linked to an Algorand DID. + - **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. + - **Issuance Date**: The date on which the credential was issued. + - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. -- **Credential Subject**: Identifies the entity the credential is about, which can be linked to an Algorand DID. -- **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. -- **Issuance Date**: The date on which the credential was issued. -- **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. -### Verifiable Credential document elements - -- **Credential Metadata**: VC inclusive metadata (Issuer, Issuance Date,...). -- **Claims**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. -- **Proofs**: Cryptographic proof that verifies the authenticity of the credential and claims, such as digital signatures. +- Verifiable Credential document + + ```mermaid + flowchart TB + vcs["Verifiable Credential"] --> metadata[Verifiable Credential metadata] + vcs["Verifiable Credential"] --> claims[Verifiable Credential Claims] + vcs["Verifiable Credential"] --> proofs[Verifiable Credential Proofs] + ``` + - **Credential Metadata**: VC inclusive metadata (Issuer, Issuance Date,...). + - **Claims**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. + - **Proofs**: Cryptographic proof that verifies the authenticity of the credential and claims, such as digital signatures. -```mermaid -flowchart TB - vcs["Verifiable Credential"] --> metadata[Verifiable Credential metadata] - vcs["Verifiable Credential"] --> claims[Verifiable Credential Claims] - vcs["Verifiable Credential"] --> proofs[Verifiable Credential Proofs] -``` ### Verifiable Credential requirements Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): From 7add4b54f2d0d0440eff76f7fbaae71a9baa7af8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:44:27 +0300 Subject: [PATCH 35/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 49eac515f..f1d13a919 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -134,7 +134,7 @@ The main types for Verifiable Credential documents on AVM chains include: - Verifiable Claims document: - Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain. + Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain or offline via means of stateproofs. ```mermaid flowchart TB From 3370db06a620e401ccf54961c16d06f88bc310e3 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:46:17 +0300 Subject: [PATCH 36/69] Update --- ARCs/arc-0113.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index f1d13a919..f9f41715b 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -140,6 +140,7 @@ The main types for Verifiable Credential documents on AVM chains include: flowchart TB vcs["Verifiable Claim"] --> metadata["Credential Metadata"] vcs["Verifiable Claim"] --> claims["Claims"] + vcs["Verifiable Claim"] --> proofs["Proofs"] ``` - Verifiable presentation document: Verifiable Presentations are documents containing VCs to be presented for verification and signing which adds the proof for VCs. From 5a2b36b45dfcf8b02972fa2b50ef4e413ce744d8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:48:57 +0300 Subject: [PATCH 37/69] Update --- ARCs/arc-0113.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index f9f41715b..372a74933 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -142,6 +142,9 @@ The main types for Verifiable Credential documents on AVM chains include: vcs["Verifiable Claim"] --> claims["Claims"] vcs["Verifiable Claim"] --> proofs["Proofs"] ``` + + Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! + - Verifiable presentation document: Verifiable Presentations are documents containing VCs to be presented for verification and signing which adds the proof for VCs. From 86ae58005ff95ffd9e7971a6adb9dbd86b2f64fd Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:49:15 +0300 Subject: [PATCH 38/69] Update --- ARCs/arc-0113.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 372a74933..5fadca0dd 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -146,6 +146,7 @@ The main types for Verifiable Credential documents on AVM chains include: Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! - Verifiable presentation document: + Verifiable Presentations are documents containing VCs to be presented for verification and signing which adds the proof for VCs. ```mermaid From 6ebf64e9e0559287831bbbcf6a5df5e28e644ae3 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:55:45 +0300 Subject: [PATCH 39/69] Update --- ARCs/arc-0113.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 5fadca0dd..2a47c36c3 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -57,6 +57,8 @@ A conforming verifier implementation consumes conforming documents, MUST perform The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. +[ARC113] identifiers used with Verifiable Credentials ecosystem MUST BE an [ARC13] DID using "algo" DID method and SHOULD NOT use general WEB (did:web) and UUID(did:uuid) DID methods! + ### Verifiable Credentials ecosystem Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! - **Issuer** : An atomic or composite DID available on AVM ledger asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. From 3ac95f0ab190f699d1fb360a17e93877fbba33e3 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 14:56:01 +0300 Subject: [PATCH 40/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 2a47c36c3..ae6a1c783 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -55,7 +55,7 @@ A conforming verifier implementation consumes conforming documents, MUST perform ## Specification -The ARC113 standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. +The [ARC113] standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. [ARC113] identifiers used with Verifiable Credentials ecosystem MUST BE an [ARC13] DID using "algo" DID method and SHOULD NOT use general WEB (did:web) and UUID(did:uuid) DID methods! From a74d8529b2a3b97160fb20deddd31fcfc8b59769 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:02:18 +0300 Subject: [PATCH 41/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index ae6a1c783..b0e224d1e 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -57,7 +57,7 @@ A conforming verifier implementation consumes conforming documents, MUST perform The [ARC113] standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -[ARC113] identifiers used with Verifiable Credentials ecosystem MUST BE an [ARC13] DID using "algo" DID method and SHOULD NOT use general WEB (did:web) and UUID(did:uuid) DID methods! +[ARC113] identifiers used with Verifiable Credentials ecosystem SHOULD BE an [ARC13] DID! ### Verifiable Credentials ecosystem Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! From 5681030bf8c18f6ecdda3a19b2f1cc1a6b4f733d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:16:25 +0300 Subject: [PATCH 42/69] Update --- ARCs/arc-0113.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index b0e224d1e..2c9c029d3 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -135,8 +135,10 @@ The metadata for verifiable credentials on Algorand will adhere to the standards The main types for Verifiable Credential documents on AVM chains include: - Verifiable Claims document: + + Dynamic Verifiable Credentials, the ones that are generated for AVM transactions does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! - Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography and AVM blockchain or offline via means of stateproofs. + Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or stateproofs. ```mermaid flowchart TB @@ -146,6 +148,8 @@ The main types for Verifiable Credential documents on AVM chains include: ``` Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! + + Note2: [ARC113] deviates from VC living standard - Verifiable presentation document: From b3fa7cdcf9f50fec7afb92bddc60e763fc497c90 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:16:35 +0300 Subject: [PATCH 43/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 2c9c029d3..82592eb28 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -138,7 +138,7 @@ The main types for Verifiable Credential documents on AVM chains include: Dynamic Verifiable Credentials, the ones that are generated for AVM transactions does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! - Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or stateproofs. + Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or Algorand stateproofs. ```mermaid flowchart TB From edc05dffc0ca23b1da341d39a61b2cf9b874ec6e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:21:57 +0300 Subject: [PATCH 44/69] Update --- ARCs/arc-0113.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 82592eb28..fcd857241 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -146,6 +146,10 @@ The main types for Verifiable Credential documents on AVM chains include: vcs["Verifiable Claim"] --> claims["Claims"] vcs["Verifiable Claim"] --> proofs["Proofs"] ``` +Any registered Verifiable Credential MUST follow Verifiable Claim issuance first and this is considering: + - The issuer and owner of the Verifiable Credential might be different + - The logic of verification for eligibility of claiming the Verifiable Credential (and its included claims) can be off-chain, on-chain or both! + - Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! From 2fead4871f99b30ca42f98f576df13258d8facdc Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:28:29 +0300 Subject: [PATCH 45/69] Update --- ARCs/arc-0113.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index fcd857241..168201b3f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -135,6 +135,9 @@ The metadata for verifiable credentials on Algorand will adhere to the standards The main types for Verifiable Credential documents on AVM chains include: - Verifiable Claims document: + Verifiable Claims are claimable unverified (except for the issuer which is verifiable) draft Verifiable Credential documents, issued to be claimed by eligible users! + The claim process contains all or part of verifications needed to satisfy claims under Verifiable Credential! + This is notable that a single Verifiable Credential can be a composite of multiple other Verifiable Credentials which have different approval and verification processes that MIGHT happen sequentially or in parallel! Dynamic Verifiable Credentials, the ones that are generated for AVM transactions does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! @@ -149,7 +152,7 @@ The main types for Verifiable Credential documents on AVM chains include: Any registered Verifiable Credential MUST follow Verifiable Claim issuance first and this is considering: - The issuer and owner of the Verifiable Credential might be different - The logic of verification for eligibility of claiming the Verifiable Credential (and its included claims) can be off-chain, on-chain or both! - - + - The decentralized and Web 3.0 initial values is to give the power of ownership, action and control to user so using the Verifiable Claim approach it is user who initiates the Verification and Claim process! Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! From 5e080a0319012f53839856c826a74ef0163bf346 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:32:23 +0300 Subject: [PATCH 46/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 168201b3f..d3e4356a2 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -139,7 +139,7 @@ The main types for Verifiable Credential documents on AVM chains include: The claim process contains all or part of verifications needed to satisfy claims under Verifiable Credential! This is notable that a single Verifiable Credential can be a composite of multiple other Verifiable Credentials which have different approval and verification processes that MIGHT happen sequentially or in parallel! - Dynamic Verifiable Credentials, the ones that are generated for AVM transactions does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! + Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or Algorand stateproofs. From e6c8b68630658aac5b2b8dfbd445cff3da62f98a Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:52:27 +0300 Subject: [PATCH 47/69] Update --- ARCs/arc-0113.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index d3e4356a2..7e99e70df 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -130,6 +130,10 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. +ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. +- @context + The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. + ### Verifiable Credential document lifecycle The main types for Verifiable Credential documents on AVM chains include: From 4c64ded007ac10290e5821758ee7951b20461c5e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:53:56 +0300 Subject: [PATCH 48/69] Update --- ARCs/arc-0113.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 7e99e70df..d308540fa 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -126,13 +126,17 @@ flowchart LR style presentation stroke:#333,stroke-width:2px ``` -### Metadata Grammar +### Metadata Grammar and properties The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. -- @context +- @context: The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. +- id: + - The id property MUST express an identifier that others are expected to use when expressing statements about a specific thing identified by that identifier. + - The id property MUST NOT have more than one value. + - The value of the id property MUST be a URL which MAY be dereferenced. ### Verifiable Credential document lifecycle From 4981b181f7ac130a202875121ff503f15f140a70 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 15:55:01 +0300 Subject: [PATCH 49/69] Update --- ARCs/arc-0113.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index d308540fa..874af844b 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -134,6 +134,8 @@ ARC113 requires for a @context property to be present; this property is defined - @context: The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. - id: + The value of the id property MUST be a single URL. It is RECOMMENDED that the URL in the id be one which, if dereferenced, results in a document containing machine-readable information about the id. + - The id property MUST express an identifier that others are expected to use when expressing statements about a specific thing identified by that identifier. - The id property MUST NOT have more than one value. - The value of the id property MUST be a URL which MAY be dereferenced. From f687e87d9a57d119851bd484d4cd5526b5dca92a Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:09:11 +0300 Subject: [PATCH 50/69] Update --- ARCs/arc-0113.md | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 874af844b..e7091ed3f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -130,15 +130,38 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. +Internationalization: +ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively! +``` +"name": [{ + "@value": "Example University", + "@language": "en" + }, { + "@value": "Université de Exemple", + "@language": "fr" + }, { + "@value": "جامعة المثال", + "@language": "ar", + "@direction": "rtl" + }] +``` + ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. - @context: The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. - id: The value of the id property MUST be a single URL. It is RECOMMENDED that the URL in the id be one which, if dereferenced, results in a document containing machine-readable information about the id. - + - The id property MUST express an identifier that others are expected to use when expressing statements about a specific thing identified by that identifier. - The id property MUST NOT have more than one value. - The value of the id property MUST be a URL which MAY be dereferenced. +- type: + Verifiable claims, credentials and presentations MUST have a type property. That is, any credential or presentation that does not have type property is not verifiable, so is neither a verifiable credential nor a verifiable presentation. +- name: +An OPTIONAL property that expresses the name of the credential. If present, the value of the name property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the name of a credential is concise, human-readable, and could enable an individual to quickly differentiate one credential from any other credentials that they might hold. +- description: +An OPTIONAL property that conveys specific details about a credential. If present, the value of the description property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the description of a credential is no more than a few sentences in length and conveys enough information about the credential to remind an individual of its contents without their having to look through the entirety of the claims. + ### Verifiable Credential document lifecycle From 142a1aa0341a05876eac04f0ffdb42845b3f5733 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:09:31 +0300 Subject: [PATCH 51/69] Update --- ARCs/arc-0113.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index e7091ed3f..73aa49d4f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -132,6 +132,7 @@ The metadata for verifiable credentials on Algorand will adhere to the standards Internationalization: ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively! + ``` "name": [{ "@value": "Example University", From 552ff10757a3b5ee2c7af6705313aec5bc72110d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:12:09 +0300 Subject: [PATCH 52/69] Update --- ARCs/arc-0113.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 73aa49d4f..af3e1e724 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -130,7 +130,7 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. -Internationalization: +#### Internationalization convention: ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively! ``` @@ -146,9 +146,9 @@ ARC113 supports expressing content in different languages. To express a string w "@direction": "rtl" }] ``` - -ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. +#### Properties - @context: + ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. - id: The value of the id property MUST be a single URL. It is RECOMMENDED that the URL in the id be one which, if dereferenced, results in a document containing machine-readable information about the id. From 98178864b2c3a24e0fad4400af31516ca5b82b0f Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:20:31 +0300 Subject: [PATCH 53/69] Update --- ARCs/arc-0113.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index af3e1e724..a63f7053a 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/)living standards and also [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) draft's, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. +This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/)living standards and also [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) and [Verifiable Credential Controllers](https://w3c.github.io/vc-controller-document/) Standard Editor drafts, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. ARC113 introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! @@ -162,6 +162,8 @@ ARC113 supports expressing content in different languages. To express a string w An OPTIONAL property that expresses the name of the credential. If present, the value of the name property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the name of a credential is concise, human-readable, and could enable an individual to quickly differentiate one credential from any other credentials that they might hold. - description: An OPTIONAL property that conveys specific details about a credential. If present, the value of the description property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the description of a credential is no more than a few sentences in length and conveys enough information about the credential to remind an individual of its contents without their having to look through the entirety of the claims. +- credentialSubject +The value of the credentialSubject property is defined as a set of objects where each object MUST be the subject of one or more claims, which MUST be serialized inside the credentialSubject property. Each object MAY also contain an id to identify the subject! ### Verifiable Credential document lifecycle From f02c814d046c7aec4a94edaaba2fe993d5a0b9da Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:34:16 +0300 Subject: [PATCH 54/69] Update --- ARCs/arc-0113.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a63f7053a..1a50f6640 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -162,8 +162,10 @@ ARC113 supports expressing content in different languages. To express a string w An OPTIONAL property that expresses the name of the credential. If present, the value of the name property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the name of a credential is concise, human-readable, and could enable an individual to quickly differentiate one credential from any other credentials that they might hold. - description: An OPTIONAL property that conveys specific details about a credential. If present, the value of the description property MUST be a string or a language value object as described in 11.1 Language and Base Direction. Ideally, the description of a credential is no more than a few sentences in length and conveys enough information about the credential to remind an individual of its contents without their having to look through the entirety of the claims. -- credentialSubject +- credentialSubject: The value of the credentialSubject property is defined as a set of objects where each object MUST be the subject of one or more claims, which MUST be serialized inside the credentialSubject property. Each object MAY also contain an id to identify the subject! +- issuer: +The value of the issuer property MUST be either a URL, or an object containing an id property whose value is a URL; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controller document [VC-CONTROLLER-DOCUMENT](https://w3c.github.io/vc-controller-document/) about the issuer that can be used to verify the information expressed in the credential. ### Verifiable Credential document lifecycle From ddfb9ce0342d8725cc0b2601f9e8ba603ec228f0 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:38:03 +0300 Subject: [PATCH 55/69] Update --- ARCs/arc-0113.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 1a50f6640..2cbd02c12 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -165,7 +165,11 @@ An OPTIONAL property that conveys specific details about a credential. If presen - credentialSubject: The value of the credentialSubject property is defined as a set of objects where each object MUST be the subject of one or more claims, which MUST be serialized inside the credentialSubject property. Each object MAY also contain an id to identify the subject! - issuer: -The value of the issuer property MUST be either a URL, or an object containing an id property whose value is a URL; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controller document [VC-CONTROLLER-DOCUMENT](https://w3c.github.io/vc-controller-document/) about the issuer that can be used to verify the information expressed in the credential. +The value of the issuer property MUST be either a URL, or an object containing an id property whose value is a URL; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controller document [VC-CONTROLLER-DOCUMENT](https://w3c.github.io/vc-controller-document/) about the issuer that can be used to verify the information expressed in the credential. It is also possible to express additional information about the issuer by associating an object with the issuer property! +- validFrom: +If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential becomes valid, which could be a date and time in the future or in the past. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. If a validUntil value also exists, the validFrom value MUST express a datetime that is temporally the same or earlier than the datetime expressed by the validUntil value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! +- validUntil: +If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past or in the future. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value also exists, the validUntil value MUST express a datetime that is temporally the same or later than the datetime expressed by the validFrom value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! ### Verifiable Credential document lifecycle From 7d1d30aa8e8944ad5c67cff926a22f167e86bd1e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:41:07 +0300 Subject: [PATCH 56/69] Update --- ARCs/arc-0113.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 2cbd02c12..6171924bb 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -255,6 +255,8 @@ Especially for adoption by global organizations, this becomes a requirement that Security considerations for ARC113 include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. +This specification recognizes two classes of securing mechanisms: those that use enveloping proofs and those that use embedded proofs. An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. These two classes of securing mechanisms are not mutually exclusive. Securing mechanism specifications other than those referred to previously might also be defined, as necessary! + ## Appendix Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of ARC113 in real-world scenarios. From ca2553465e90a014802eb719c1598789e9756a2f Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:46:44 +0300 Subject: [PATCH 57/69] Update --- ARCs/arc-0113.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 6171924bb..13b890e38 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -255,7 +255,9 @@ Especially for adoption by global organizations, this becomes a requirement that Security considerations for ARC113 include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. -This specification recognizes two classes of securing mechanisms: those that use enveloping proofs and those that use embedded proofs. An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. These two classes of securing mechanisms are not mutually exclusive. Securing mechanism specifications other than those referred to previously might also be defined, as necessary! +This specification recognizes 3 classes of securing mechanisms: those that use enveloping proofs, those that use embedded proofs and state proofs (Zero Knowledge Proofs). An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. An state proof is a verifiable proof that a transaction is added to decentralized ledger as a certain block! These three classes of securing mechanisms are not mutually exclusive. + +//TODO: Securing mechanism specifications based on [ARC52] to be added! E.g DH secret keys or derived keys for encryption! ## Appendix From ff9716d3cd8b848d15591824c54fe13fa7fd0da8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:50:23 +0300 Subject: [PATCH 58/69] Update --- ARCs/arc-0113.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 13b890e38..a03672480 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -170,6 +170,14 @@ The value of the issuer property MUST be either a URL, or an object containing a If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential becomes valid, which could be a date and time in the future or in the past. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. If a validUntil value also exists, the validFrom value MUST express a datetime that is temporally the same or earlier than the datetime expressed by the validUntil value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! - validUntil: If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past or in the future. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value also exists, the validUntil value MUST express a datetime that is temporally the same or later than the datetime expressed by the validFrom value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! +- proof +One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a verifiable credential or a verifiable presentation. Each proof is a separate named graph (referred to as a proof graph) containing a single proof. The specific method used for an embedded proof MUST be identified using the type property. +- credentialStatus + If present, the value of the credentialStatus property MUST include the following: + - id property, which MUST be a URL which MAY be dereferenced. + - type property, which expresses the credential status type. + + The precise content of the credential status information is determined by the specific credentialStatus type definition, and varies depending on factors such as whether it is simple to implement or if it is privacy-enhancing. It is expected that the value will provide enough information to determine the current status of the credential and that machine readable information will be retrievable from the URL. For example, the object could contain a link to an external document which notes whether or not the credential is suspended or revoked. ### Verifiable Credential document lifecycle From 4c689e7e272d503905f5e31009083b13f080f3e3 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 19:53:39 +0300 Subject: [PATCH 59/69] Update --- ARCs/arc-0113.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index a03672480..e658a224c 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -185,8 +185,12 @@ One or more cryptographic proofs that can be used to detect tampering and verify The main types for Verifiable Credential documents on AVM chains include: - Verifiable Claims document: - Verifiable Claims are claimable unverified (except for the issuer which is verifiable) draft Verifiable Credential documents, issued to be claimed by eligible users! - The claim process contains all or part of verifications needed to satisfy claims under Verifiable Credential! + Unverified Verifiable Credential documents are still Verifiable Claims which are claimable unverified (except for the issuer which is verifiable) draft Verifiable Credential documents, issued to be claimed by eligible users! + The claim process MUST contain all or part of verifications needed to satisfy claims under Verifiable Credential! + This is considering: + - The issuer and owner of the Verifiable Credential might be different + - The logic of verification for eligibility of claiming the Verifiable Credential (and its included claims) can be off-chain, on-chain or both! + - The decentralized and Web 3.0 initial values is to give the power of ownership, action and control to user so using the Verifiable Claim approach it is user who initiates the Verification and Claim process! This is notable that a single Verifiable Credential can be a composite of multiple other Verifiable Credentials which have different approval and verification processes that MIGHT happen sequentially or in parallel! Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! @@ -199,10 +203,7 @@ The main types for Verifiable Credential documents on AVM chains include: vcs["Verifiable Claim"] --> claims["Claims"] vcs["Verifiable Claim"] --> proofs["Proofs"] ``` -Any registered Verifiable Credential MUST follow Verifiable Claim issuance first and this is considering: - - The issuer and owner of the Verifiable Credential might be different - - The logic of verification for eligibility of claiming the Verifiable Credential (and its included claims) can be off-chain, on-chain or both! - - The decentralized and Web 3.0 initial values is to give the power of ownership, action and control to user so using the Verifiable Claim approach it is user who initiates the Verification and Claim process! + Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! From 4850aa9f9e7e128172505b75ec9b4c5fcf37d994 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 20:10:41 +0300 Subject: [PATCH 60/69] Update --- ARCs/arc-0113.md | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index e658a224c..0147ac5a4 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -219,13 +219,23 @@ The main types for Verifiable Credential documents on AVM chains include: vcs["Verifiable Presentation"] --> credentials["Verifiable Credentials"] vcs["Verifiable Presentation"] --> proofs["Proofs"] ``` - - - **Credential Subject**: Identifies the entity the credential is about, which can be linked to an Algorand DID. - - **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. - - **Issuance Date**: The date on which the credential was issued. - - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. - + + - id: + The id property is optional. It MAY be used to provide a unique identifier for the verifiable presentation. If present, the normative guidance in Section 4.3 Identifiers MUST be followed. + - type: + The type property MUST be present. It is used to express the type of verifiable presentation. One value of this property MUST be VerifiablePresentation, but additional types MAY be included. The related normative guidance in Section 4.4 Types MUST be followed. + - verifiableCredential + The verifiableCredential property MAY be present. The value MUST be one or more verifiable credential and/or enveloped verifiable credential objects (to be clear, the values MUST NOT be non-object values such as numbers, strings, or URLs). These types of objects are called verifiable credential graphs and MUST express information that is secured using a securing mechanism. See Section 5.12 Verifiable Credential Graphs for further details. + - holder + The verifiable presentation MAY include a holder property. If present, the value MUST be either a URL or an object containing an id property. It is RECOMMENDED that the URL in the holder or its id be one which, if dereferenced, results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the verifiable presentation. If the holder property is absent, information about the holder is expected to either be obtained via the securing mechanism, or to not pertain to the validation of the verifiable presentation. + - proof + The verifiable presentation MAY include a proof property, which refers to a separate named graph containing a single proof. The specific method used for the MUST be identified using the type property. The proof covers of all claims in the following graphs: + + - the verifiable presentation graph; + - all verifiable credential graphs referred to by the verifiableCredential property of the presentation, as well as their corresponding proof graphs. + - Verifiable Credential document + This is the proof-contained, verifiable document and can be shared and used for verifying a credential in general! ```mermaid flowchart TB @@ -233,9 +243,14 @@ The main types for Verifiable Credential documents on AVM chains include: vcs["Verifiable Credential"] --> claims[Verifiable Credential Claims] vcs["Verifiable Credential"] --> proofs[Verifiable Credential Proofs] ``` - - **Credential Metadata**: VC inclusive metadata (Issuer, Issuance Date,...). + + + - **Credential Subject**: Identifies the entity the credential is about, which can be linked to an Algorand DID. + - **Issuer**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. + - **Issuance Date**: The date on which the credential was issued. - **Claims**: The entity that issues and attests to the verifiable credential, identified by an Algorand DID. - - **Proofs**: Cryptographic proof that verifies the authenticity of the credential and claims, such as digital signatures. + - **Proof**: Cryptographic proof that verifies the authenticity of the credential, such as digital signatures. + ### Verifiable Credential requirements From 9bc901ff11fc44b8cb69c95e855d1cbc26eeb3c7 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 20:11:07 +0300 Subject: [PATCH 61/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 0147ac5a4..f65e8dbac 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -285,7 +285,7 @@ This specification recognizes 3 classes of securing mechanisms: those that use e ## Appendix -Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of ARC113 in real-world scenarios. +// TODO: Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of ARC113 in real-world scenarios. ## Copyright From fe3e4a60e6269c3bfecbebfacbbe2f386df48a42 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 20:25:07 +0300 Subject: [PATCH 62/69] Update --- ARCs/arc-0113.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index f65e8dbac..54d30de18 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -131,7 +131,18 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. #### Internationalization convention: -ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively! +ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively: + +``` +"[=property=]": { + "@value": "The string value", + "@language": "`LANGUAGE`" + "@direction": "`DIRECTION`" +} + +``` + +Example name with all different internationalization properties: ``` "name": [{ From b4bc589fef6ebfb36d36ea60948d904518bd3cd2 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 29 Dec 2023 10:54:01 +0300 Subject: [PATCH 63/69] Add trust model --- ARCs/arc-0113.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 54d30de18..c80f67d7b 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -292,6 +292,25 @@ Security considerations for ARC113 include ensuring the integrity and verifiabil This specification recognizes 3 classes of securing mechanisms: those that use enveloping proofs, those that use embedded proofs and state proofs (Zero Knowledge Proofs). An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. An state proof is a verifiable proof that a transaction is added to decentralized ledger as a certain block! These three classes of securing mechanisms are not mutually exclusive. +### Trust Model + +The [ARC113] verifiable credentials trust model, based on Algorand technology features, is as follows: + +The verifier trusts the issuer to issue the credential that it received. To establish this trust, a credential is expected to either: + - Include a transaction or arbitrary data, signed by specific algo DID controller, that cryptographically proves the issuer generated the credential! + - Use the transaction stateproof that verifies the issuer generated the verifiable credential and that the verifiable credential was not tampered with, because of the nature of Algorand blockchain. +Important note: Both these trust scenarios are strong and post-quantum resistant for ARC113 implementations because of direct Algorand technology properties and specifications! + +All entities trust the verifiable data registry to be tamper-proof and to be a correct record of which data is controlled by which entities, because it is an on-chain stored value based on a valid and known ABI call transaction. + +The holder and verifier trust the issuer to issue true (that is, not false) credentials about the subject, and to revoke them quickly when appropriate. This is notable that with [ARC113] scenarios during which a Verifiable Claim is initially generated by the verifier through issuer decentralized service ABI endpoints (methods), this trust model changes so that holder and verifier trust the Issuer's smart contract logic to provide deterministically true VCs and approvals or rejections! + +If the holder needs the repository to store credentials securely, and to not release them to anyone other than the holder, then [ARC113] uses and recommends using [ARC52] DH based symmetric secret implementation to make sure credentials are only shared between Holder and Verifier and stored with Issuer registry that securely that way (the DH key enveloped version of credentials will be stored on Issuer's registry) + +This trust model differentiates itself from other trust models by ensuring the: + - Issuer and the verifier do not need to trust the repository + - Issuer does not need to know or trust the verifier. + //TODO: Securing mechanism specifications based on [ARC52] to be added! E.g DH secret keys or derived keys for encryption! ## Appendix From 06d5abca7713c4d183a5405b97b877553ed994c7 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 29 Dec 2023 13:59:10 +0300 Subject: [PATCH 64/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index c80f67d7b..bb62e4c78 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -2,7 +2,7 @@ arc: 113 title: Verifiable Credentials (VCs) description: Verifiable Credentials V 2.0 living standard for Algorand. -author: MG (@emg110), @VoiNetwork, @GoraNetwork, @DaffiDigital, @GoPlausible +author: MG (@emg110), @GoPlausible, @VoiNetwork, @GoraNetwork, @DaffiDigital status: Draft type: Standards Track category: Credentials Conventions and Data model From 33e6ed685f2a5a21fe5f84dc7dfcee39a306dbd4 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 29 Dec 2023 14:00:42 +0300 Subject: [PATCH 65/69] Update --- ARCs/arc-0113.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index bb62e4c78..989f00802 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -13,9 +13,9 @@ created: 2023-12-18 This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/)living standards and also [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) and [Verifiable Credential Controllers](https://w3c.github.io/vc-controller-document/) Standard Editor drafts, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. -ARC113 introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! +[ARC113] introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! -ARC113 can be implemented using/for ARC ASAs as an extension! Including support for: +[ARC113] can be implemented using/for ARC ASAs as an extension! Including support for: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) @@ -23,19 +23,19 @@ ARC113 can be implemented using/for ARC ASAs as an extension! Including support - [ARC72](https://arc.algorand.foundation/ARCs/arc-0069) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0069) -ARC113 as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! +[ARC113] as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE only! ARC 113 by using ARC13 as DID standard and reference implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) as well! -ARC113 is in full compliance to: +[ARC113] is in full compliance to: - [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) - [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) -The goal to ARC113 is first to adopt VerifiableCredentials standards for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and generated dynamically for each transaction using either an API or an ABI! +The goal to [ARC113] is first to adopt VerifiableCredentials standards for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and generated dynamically for each transaction using either an API or an ABI! -Important note: ARC113 tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! +Important note: [ARC113] tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! @@ -131,7 +131,7 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. #### Internationalization convention: -ARC113 supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively: +[ARC113] supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively: ``` "[=property=]": { @@ -159,7 +159,7 @@ Example name with all different internationalization properties: ``` #### Properties - @context: - ARC113 requires for a @context property to be present; this property is defined by [JSON-LD]. + [ARC113] requires for a @context property to be present; this property is defined by [JSON-LD]. The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. - id: The value of the id property MUST be a single URL. It is RECOMMENDED that the URL in the id be one which, if dereferenced, results in a document containing machine-readable information about the id. @@ -204,7 +204,7 @@ The main types for Verifiable Credential documents on AVM chains include: - The decentralized and Web 3.0 initial values is to give the power of ownership, action and control to user so using the Verifiable Claim approach it is user who initiates the Verification and Claim process! This is notable that a single Verifiable Credential can be a composite of multiple other Verifiable Credentials which have different approval and verification processes that MIGHT happen sequentially or in parallel! - Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC (ARC113)! + Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC ([ARC113])! Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or Algorand stateproofs. @@ -281,14 +281,14 @@ Required decentralized identifiers and implementations which are used to constru ## Rationale -The rationale behind ARC113 is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, ARC113 ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. +The rationale behind [ARC113] is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, [ARC113] ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. All protocols and projects on Algorand can use and benefit from VCs on Algorand to make their protocols and dApps more compliant to regulations , e.g GDPR and EU Blockchain regulations! Especially for adoption by global organizations, this becomes a requirement that ecosystem offers integration, adoption and interoperability with Verifiable Credentials as they are widely in use and are common best practice in Web 2.0 as well! ## Security Considerations -Security considerations for ARC113 include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. +Security considerations for [ARC113] include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. This specification recognizes 3 classes of securing mechanisms: those that use enveloping proofs, those that use embedded proofs and state proofs (Zero Knowledge Proofs). An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. An state proof is a verifiable proof that a transaction is added to decentralized ledger as a certain block! These three classes of securing mechanisms are not mutually exclusive. @@ -299,7 +299,7 @@ The [ARC113] verifiable credentials trust model, based on Algorand technology fe The verifier trusts the issuer to issue the credential that it received. To establish this trust, a credential is expected to either: - Include a transaction or arbitrary data, signed by specific algo DID controller, that cryptographically proves the issuer generated the credential! - Use the transaction stateproof that verifies the issuer generated the verifiable credential and that the verifiable credential was not tampered with, because of the nature of Algorand blockchain. -Important note: Both these trust scenarios are strong and post-quantum resistant for ARC113 implementations because of direct Algorand technology properties and specifications! +Important note: Both these trust scenarios are strong and post-quantum resistant for [ARC113] implementations because of direct Algorand technology properties and specifications! All entities trust the verifiable data registry to be tamper-proof and to be a correct record of which data is controlled by which entities, because it is an on-chain stored value based on a valid and known ABI call transaction. @@ -315,7 +315,7 @@ This trust model differentiates itself from other trust models by ensuring the: ## Appendix -// TODO: Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of ARC113 in real-world scenarios. +// TODO: Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of [ARC113] in real-world scenarios. ## Copyright From c7fbc36f9ba46ef20f6d84c4701b303c5f53a9a0 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 29 Dec 2023 14:01:20 +0300 Subject: [PATCH 66/69] Update --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 989f00802..3fc10213f 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -45,7 +45,7 @@ All authoring guidelines, diagrams, examples, and notes in this specification ar Algorand DID elements used by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. -Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. +Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in [RFC 3986]. A conforming document is a compacted JSON-LD document that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 4. Basic Concepts, 5. Advanced Concepts, and 6. Syntaxes of this document MUST be enforced. A conforming document is either a verifiable credential that MUST be serialized using the application/vc+ld+json media type or a verifiable presentation that MUST be serialized using the application/vp+ld+json media type. A conforming document MUST be secured by at least one securing mechanisms mentioned by this document! From c92a0738c9b3469af897a9664ba5f6122d9737b9 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 3 Jan 2024 14:23:55 +0300 Subject: [PATCH 67/69] Update ARCs/arc-0113.md Thanks to @nullun Co-authored-by: nullun --- ARCs/arc-0113.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index 3fc10213f..ae4eb5f80 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -20,8 +20,8 @@ This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 D - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) -- [ARC72](https://arc.algorand.foundation/ARCs/arc-0069) -- [ARC200](https://arc.algorand.foundation/ARCs/arc-0069) +- [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) +- [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) [ARC113] as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! From f556f2c5b93386102e5177e47077e0cc50293519 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane?= Date: Thu, 11 Jan 2024 09:59:29 +0100 Subject: [PATCH 68/69] Fix linting --- ARCs/arc-0113.md | 83 ++++++++++++++++++++++++------------------------ 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index ae4eb5f80..d45fa94aa 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -1,49 +1,50 @@ --- arc: 113 title: Verifiable Credentials (VCs) -description: Verifiable Credentials V 2.0 living standard for Algorand. -author: MG (@emg110), @GoPlausible, @VoiNetwork, @GoraNetwork, @DaffiDigital +description: Verifiable Credentials V 2.0 for Algorand. +author: MG (@emg110), GoPlausible (@GoPlausible), VoiNetwork (@VoiNetwork), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) status: Draft type: Standards Track -category: Credentials Conventions and Data model +category: ARC created: 2023-12-18 +requires: 13, 52, 110 --- ## Abstract -This ARC represents the [W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023)](https://www.w3.org/TR/vc-data-model-2.0/) and [Verifiable Credential Data Integrity 1.0](https://w3c.github.io/vc-data-integrity/)living standards and also [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/) and [Verifiable Credential Controllers](https://w3c.github.io/vc-controller-document/) Standard Editor drafts, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. +This ARC represents the W3C Verifiable Credentials Data Model Version 2.0 (17 December 2023) and Verifiable Credential Data Integrity 1.0living standards and also Verifiable Credentials API v0.3 and Verifiable Credential Controllers Standard Editor drafts, requirements, conventions and recommendations adopted for Algorand and AVM elements, methods as well as related ARCs. -[ARC113] introduces the Verifiable Credentials ABI v0.3 in accordance to [Verifiable Credentials API v0.3](https://w3c-ccg.github.io/vc-api/), deliverable through ABI calls with proper arguments according to [ARC4](https://arc.algorand.foundation/ARCs/arc-0004)! +[ARC-113](./arc-0113.md) introduces the Verifiable Credentials ABI v0.3 in accordance to Verifiable Credentials API v0.3, deliverable through ABI calls with proper arguments according to [ARC-4](./arc-0004.md)! -[ARC113] can be implemented using/for ARC ASAs as an extension! Including support for: +It can be implemented using/for ARC ASAs as an extension! Including support for: -- [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) -- [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) -- [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) -- [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) -- [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) +- [ARC-3](./arc-0003.md) +- [ARC-19](./arc-0019.md) +- [ARC-69](./arc-0069.md) +- [ARC-72](./arc-0072.md) +- [ARC-200](./arc-0200.md) -[ARC113] as well as ARC13, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on both proofs and integrity parts! +ARC-113 as well as [ARC-13](./arc-0013.md), heavily depend and rely on [ARC-52](./arc-0052.md) line of work and reference implementation to proceed on both proofs and integrity parts! -This ARC partially complies to [Securing Verifiable Credentials using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-credentials-with-jose) with focus on JOSE only! +This ARC partially complies to Securing Verifiable Credentials using JOSE and COSE with focus on JOSE only! -ARC 113 by using ARC13 as DID standard and reference implementation, partially follows [did:web Method Specification](https://w3c-ccg.github.io/did-method-web) as well! +ARC-113 by using ARC-13 as DID standard and reference implementation, partially follows did:web Method Specification as well! -[ARC113] is in full compliance to: -- [ARC13](https://arc.algorand.foundation/ARCs/arc-0013) -- [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) +[ARC-113] is in full compliance to: +- [ARC-13](./arc-0013.md) +- [ARC-110](./arc-0110.md) -The goal to [ARC113] is first to adopt VerifiableCredentials standards for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and generated dynamically for each transaction using either an API or an ABI! +The goal to [ARC-113] is first to adopt VerifiableCredentials standards for already in place transaction history of chain and secondly to set AVM native conventions and methods as extension to original standard so that registering new VCs can be accessed publicly and generated dynamically for each transaction using either an API or an ABI! -Important note: [ARC113] tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! +Important note: [ARC-113] tries to follow a micro architecture and plug and play approach in a way that Verifiers in general can offer their services and then depending on the service being available onchain (decentralized) or off chain (web 2.0) then can be included through either main verifiers or service extended (URI based services) verification relations! NOTE: THIS IS A DRAFT ARC! WORK IN PROGRESS! ALL HELP WELCOME! ### General Format -All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MAY," "MUST," "MUST NOT," "OPTIONAL," "RECOMMENDED," "REQUIRED," "SHOULD," and "SHOULD NOT" in this document are to be interpreted as described in [BCP 14 RFC2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here. +All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MAY," "MUST," "MUST NOT," "OPTIONAL," "RECOMMENDED," "REQUIRED," "SHOULD," and "SHOULD NOT" in this document are to be interpreted as described in BCP 14 RFC2119 and RFC8174 when, and only when, they appear in all capitals, as shown here. -Algorand DID elements used by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. +Algorand DID elements used by this ARC follow the URI format in general as outlined in RFC 3986. This ARC aims to be as future-proof as possible; therefore, some generalized architectural elements and conventions (e.g., fragments and paths) may be set forth that may not find immediate use in the current ecosystem tooling. Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in [RFC 3986]. @@ -55,9 +56,9 @@ A conforming verifier implementation consumes conforming documents, MUST perform ## Specification -The [ARC113] standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. +The [ARC-113] standard aims to seamlessly integrate the W3C Verifiable Credentials (VCs) Data Model, integrity and API for Algorand and AVM elements, leveraging all available tech stack and existing ARCs. This integration ensures that VCs on Algorand maintain usability, extendability and interoperability as well as compliance to DID standards through [ARC-13]! This integration and harmony is essential for verifiable digital identity and decentralized credentials, authentication, verification, and their presentations. -[ARC113] identifiers used with Verifiable Credentials ecosystem SHOULD BE an [ARC13] DID! +[ARC-113] identifiers used with Verifiable Credentials ecosystem SHOULD BE an [ARC-13] DID! ### Verifiable Credentials ecosystem Specification: - **Holder**: An atomic or composite DID available on AVM ledger. Example holders include individual Algorand accounts like students, employees, and customers or composite ones like organizations, groups, universities, NGOs, DAOs, societies, clubs and ...! @@ -131,7 +132,7 @@ flowchart LR The metadata for verifiable credentials on Algorand will adhere to the standards set forth in the W3C Verifiable Credentials Data Model, adapted to fit the unique identifiers and structures of the Algorand blockchain. This includes the use of Algorand-specific terms and properties within the credential's metadata. #### Internationalization convention: -[ARC113] supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively: +[ARC-113] supports expressing content in different languages. To express a string with language and base direction information, one can use an object that contains the @value, @language, and @direction properties to express the text value, language tag, and base direction, respectively: ``` "[=property=]": { @@ -159,7 +160,7 @@ Example name with all different internationalization properties: ``` #### Properties - @context: - [ARC113] requires for a @context property to be present; this property is defined by [JSON-LD]. + [ARC-113] requires for a @context property to be present; this property is defined by [JSON-LD]. The value of the @context property MUST be an ordered set where the first item is a URL with the value [https://www.w3.org/ns/credentials/v2]. For reference, a copy of the base context is provided in Appendix. Subsequent items in the array MUST be composed of any combination of URLs and/or objects where each is processable as a [JSON-LD] Context. - id: The value of the id property MUST be a single URL. It is RECOMMENDED that the URL in the id be one which, if dereferenced, results in a document containing machine-readable information about the id. @@ -176,11 +177,11 @@ An OPTIONAL property that conveys specific details about a credential. If presen - credentialSubject: The value of the credentialSubject property is defined as a set of objects where each object MUST be the subject of one or more claims, which MUST be serialized inside the credentialSubject property. Each object MAY also contain an id to identify the subject! - issuer: -The value of the issuer property MUST be either a URL, or an object containing an id property whose value is a URL; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controller document [VC-CONTROLLER-DOCUMENT](https://w3c.github.io/vc-controller-document/) about the issuer that can be used to verify the information expressed in the credential. It is also possible to express additional information about the issuer by associating an object with the issuer property! +The value of the issuer property MUST be either a URL, or an object containing an id property whose value is a URL; in either case, the issuer selects this URL to identify itself in a globally unambiguous way. It is RECOMMENDED that the URL be one which, if dereferenced, results in a controller document VC-CONTROLLER-DOCUMENT about the issuer that can be used to verify the information expressed in the credential. It is also possible to express additional information about the issuer by associating an object with the issuer property! - validFrom: -If present, the value of the validFrom property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential becomes valid, which could be a date and time in the future or in the past. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. If a validUntil value also exists, the validFrom value MUST express a datetime that is temporally the same or earlier than the datetime expressed by the validUntil value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! +If present, the value of the validFrom property MUST be an XMLSCHEMA11-2 dateTimeStamp string value representing the date and time the credential becomes valid, which could be a date and time in the future or in the past. Note that this value represents the earliest point in time at which the information associated with the credentialSubject property becomes valid. If a validUntil value also exists, the validFrom value MUST express a datetime that is temporally the same or earlier than the datetime expressed by the validUntil value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC-113] universal library as a method output! - validUntil: -If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past or in the future. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value also exists, the validUntil value MUST express a datetime that is temporally the same or later than the datetime expressed by the validFrom value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC113] universal library as a method output! +If present, the value of the validUntil property MUST be an [XMLSCHEMA11-2] dateTimeStamp string value representing the date and time the credential ceases to be valid, which could be a date and time in the past or in the future. Note that this value represents the latest point in time at which the information associated with the credentialSubject property is valid. If a validFrom value also exists, the validUntil value MUST express a datetime that is temporally the same or later than the datetime expressed by the validFrom value. This [XMLSCHEMA11-2] dateTimeStamp string format is available through [ARC-113] universal library as a method output! - proof One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a verifiable credential or a verifiable presentation. Each proof is a separate named graph (referred to as a proof graph) containing a single proof. The specific method used for an embedded proof MUST be identified using the type property. - credentialStatus @@ -204,7 +205,7 @@ The main types for Verifiable Credential documents on AVM chains include: - The decentralized and Web 3.0 initial values is to give the power of ownership, action and control to user so using the Verifiable Claim approach it is user who initiates the Verification and Claim process! This is notable that a single Verifiable Credential can be a composite of multiple other Verifiable Credentials which have different approval and verification processes that MIGHT happen sequentially or in parallel! - Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC ([ARC113])! + Dynamic Verifiable Credentials, the ones that are generated for AVM transactions and delivered by universal [ARC-113] verifiable registry and resolver API, ABI and UI, does not need this step and Verifiable Claim document does not exist for them since the Verifiable Credential is generated all at once based on this ARC ([ARC-113])! Verifiable Credentials are issued as Verifiable claims and after review and verification by verifier then will include the proof used by verifier and therefore can be verified by any third party through cryptography or Algorand stateproofs. @@ -218,7 +219,7 @@ The main types for Verifiable Credential documents on AVM chains include: Note: Proofs on Verifiable Claim stage are limited to OPTIONAL Issuer proof references only! - Note2: [ARC113] deviates from VC living standard + Note2: [ARC-113] deviates from VC living standard - Verifiable presentation document: @@ -265,7 +266,7 @@ The main types for Verifiable Credential documents on AVM chains include: ### Verifiable Credential requirements -Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC13](https://arc.algorand.foundation/ARCs/arc-0013)): +Required decentralized identifiers and implementations which are used to construct VC main elements are (in compliance to [ARC-13](./arc-0013.md)): - Algorand DID URI: This is the unique identifier for a subject within the Algorand ecosystem. It follows the standard DID format but is specific to Algorand. @@ -277,48 +278,48 @@ Required decentralized identifiers and implementations which are used to constru - Verifiable Data Registry (Algorand Blockchain): The Algorand blockchain acts as the verifiable data registry where DIDs are recorded and can be looked up. GoPlausible API and ABI are the service interfaces delivering this facility and PLAUSIBLE protocol has expanded to include this role on Algorand blockchain as first Verifiable Data Registry! -- DID Resolver: A system component that takes a DID as input and produces the corresponding DID document as output. GoPlausible API and ABI now include Algorand DID resolver endpoints and also there is a universal ES module (JS) client library [algo-did-resolver](https://www.npmjs.com/package/algo-did-resolver)for dApp integration on client side, available through NPM! +- DID Resolver: A system component that takes a DID as input and produces the corresponding DID document as output. GoPlausible API and ABI now include Algorand DID resolver endpoints and also there is a universal ES module (JS) client library algo-did-resolverfor dApp integration on client side, available through NPM! ## Rationale -The rationale behind [ARC113] is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, [ARC113] ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. +The rationale behind [ARC-113] is to provide a robust framework for creating, issuing, and verifying digital credentials on the Algorand blockchain. By aligning with the W3C Verifiable Credentials standard, [ARC-113] ensures interoperability with global digital identity systems, enhancing the utility and trustworthiness of credentials within the Algorand ecosystem. All protocols and projects on Algorand can use and benefit from VCs on Algorand to make their protocols and dApps more compliant to regulations , e.g GDPR and EU Blockchain regulations! Especially for adoption by global organizations, this becomes a requirement that ecosystem offers integration, adoption and interoperability with Verifiable Credentials as they are widely in use and are common best practice in Web 2.0 as well! ## Security Considerations -Security considerations for [ARC113] include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. +Security considerations for [ARC-113] include ensuring the integrity and verifiability of verifiable credentials, secure management of cryptographic keys, and adherence to privacy-preserving principles in credential issuance and verification. This specification recognizes 3 classes of securing mechanisms: those that use enveloping proofs, those that use embedded proofs and state proofs (Zero Knowledge Proofs). An enveloping proof is one that wraps a serialization of this data model. One such enveloping proof mechanism is elaborated on in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] specification. An embedded proof is a mechanism where the proof is included in the data model. One such embedded proof mechanism is Verifiable Credential Data Integrity [VC-DATA-INTEGRITY]. An state proof is a verifiable proof that a transaction is added to decentralized ledger as a certain block! These three classes of securing mechanisms are not mutually exclusive. ### Trust Model -The [ARC113] verifiable credentials trust model, based on Algorand technology features, is as follows: +The [ARC-113] verifiable credentials trust model, based on Algorand technology features, is as follows: The verifier trusts the issuer to issue the credential that it received. To establish this trust, a credential is expected to either: - Include a transaction or arbitrary data, signed by specific algo DID controller, that cryptographically proves the issuer generated the credential! - Use the transaction stateproof that verifies the issuer generated the verifiable credential and that the verifiable credential was not tampered with, because of the nature of Algorand blockchain. -Important note: Both these trust scenarios are strong and post-quantum resistant for [ARC113] implementations because of direct Algorand technology properties and specifications! +Important note: Both these trust scenarios are strong and post-quantum resistant for [ARC-113] implementations because of direct Algorand technology properties and specifications! All entities trust the verifiable data registry to be tamper-proof and to be a correct record of which data is controlled by which entities, because it is an on-chain stored value based on a valid and known ABI call transaction. -The holder and verifier trust the issuer to issue true (that is, not false) credentials about the subject, and to revoke them quickly when appropriate. This is notable that with [ARC113] scenarios during which a Verifiable Claim is initially generated by the verifier through issuer decentralized service ABI endpoints (methods), this trust model changes so that holder and verifier trust the Issuer's smart contract logic to provide deterministically true VCs and approvals or rejections! +The holder and verifier trust the issuer to issue true (that is, not false) credentials about the subject, and to revoke them quickly when appropriate. This is notable that with [ARC-113] scenarios during which a Verifiable Claim is initially generated by the verifier through issuer decentralized service ABI endpoints (methods), this trust model changes so that holder and verifier trust the Issuer's smart contract logic to provide deterministically true VCs and approvals or rejections! -If the holder needs the repository to store credentials securely, and to not release them to anyone other than the holder, then [ARC113] uses and recommends using [ARC52] DH based symmetric secret implementation to make sure credentials are only shared between Holder and Verifier and stored with Issuer registry that securely that way (the DH key enveloped version of credentials will be stored on Issuer's registry) +If the holder needs the repository to store credentials securely, and to not release them to anyone other than the holder, then [ARC-113] uses and recommends using [ARC-52] DH based symmetric secret implementation to make sure credentials are only shared between Holder and Verifier and stored with Issuer registry that securely that way (the DH key enveloped version of credentials will be stored on Issuer's registry) This trust model differentiates itself from other trust models by ensuring the: - Issuer and the verifier do not need to trust the repository - Issuer does not need to know or trust the verifier. -//TODO: Securing mechanism specifications based on [ARC52] to be added! E.g DH secret keys or derived keys for encryption! +//TODO: Securing mechanism specifications based on [ARC-52] to be added! E.g DH secret keys or derived keys for encryption! ## Appendix -// TODO: Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of [ARC113] in real-world scenarios. +// TODO: Examples of verifiable credentials and presentations in [JSON-LD] format will be provided, demonstrating the application of [ARC-113] in real-world scenarios. ## Copyright This document and its content are released under the Creative Commons Zero (CC0) license, allowing for maximum flexibility and adoption within the Algorand community and beyond. -Copyright and related rights waived via [CCO](https://creativecommons.org/publicdomain/zero/1.0/). +Copyright and related rights waived via CCO. From 9b422f0240eab22309c4936fb2714c5f0efe75d2 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 20 Sep 2024 08:05:21 +0300 Subject: [PATCH 69/69] Update arc-0113.md --- ARCs/arc-0113.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0113.md b/ARCs/arc-0113.md index d45fa94aa..cabe7ea38 100644 --- a/ARCs/arc-0113.md +++ b/ARCs/arc-0113.md @@ -2,7 +2,7 @@ arc: 113 title: Verifiable Credentials (VCs) description: Verifiable Credentials V 2.0 for Algorand. -author: MG (@emg110), GoPlausible (@GoPlausible), VoiNetwork (@VoiNetwork), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) +author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) status: Draft type: Standards Track category: ARC