From 850a3b0fce141564c5446c55f8748885dd243ec5 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 22:03:38 +0300 Subject: [PATCH 001/116] ARC-0013 Initial commit --- ARCs/arc-0013.md | 407 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 407 insertions(+) create mode 100644 ARCs/arc-0013.md diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md new file mode 100644 index 000000000..a96a357c2 --- /dev/null +++ b/ARCs/arc-0013.md @@ -0,0 +1,407 @@ +--- +arc: 13 +title: Decentiralized identifiers (DIDs) +description: DID (Decentralized identifier) V 1.0 living standard URI format conventions for Algorand blockchain identifier elements. +author: MG (@emg110) +status: Draft +type: Standards Track +category: Interface and Convention +created: 2023-12-18 +--- + +## Abstract + +This standard represents [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standard's requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +- [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) +- [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) +- [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) +- [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) +- [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) +- [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) + +To implement DID naming , namespace, ABNF grammar and DID registry specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in this ARC's scope! + +Algorand specific features have been reflected into this ARC in full extent: +- Composability +- Elements and namespace conventions +- Methods and operations +- Tech stack (available and in use) +- Requirements + +## Specification +The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. + +### 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 specified 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. + +### ABNF Grammar +The generic DID scheme is a URI scheme conformant with [RFC3986]. The ABNF definition can be found below, which uses the syntax in [RFC5234] and the corresponding definitions for ALPHA and DIGIT. All other rule names not defined in the ABNF below are defined in [RFC3986]. All DIDs MUST conform to the DID Syntax ABNF Rules. + +The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with the general DID ABNF grammar, with specific adaptations for Algorand's unique elements: + +``` +DID Syntax ABNF: +did = "did:" method-name ":" method-specific-id +method-name = 1*method-char +method-char = %x61-7A / DIGIT +method-specific-id = *( *idchar ":" ) 1*idchar +idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded +pct-encoded = "%" HEXDIG HEXDIG + +``` +-------------- + +``` +The Algorand extended DID Syntax ABNF: +did = "did:" method-name ":" method-specific-id +method-name = "algo" ; Algorand method name +algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers +algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "logicsig"; Algorand namespace identifiers +method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier +algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem + + + +``` + +### Main elements + +The main elements of the Algorand DID based on the DID data model are: + +- DID Scheme: did:algo: The unique scheme for Algorand DIDs. +- Network Identifier: testnet_ or mainnet_ Specifies the Algorand network (testnet or mainnet). +- Namespace: Identifies the type of Algorand element the DID represents (e.g., asa, txn, app). +- Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). + +## Rationale +ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and beyond. + +Note: Algorand account addresses have no namespace and are considered root namespace under :algo! + +UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities! As comparability is one of Algorand product mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! + +NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! + +## Security Considerations + +1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial. +2. DID Document Integrity: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. +3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. + +Note: The UUID namespace MUST be isolated by network for security reasons! +## DID lifecycle + +A DID has different life stages depicted here and this stage status is reflected in value of DID "status" field! The status different values: +- Non-Existing +- 0: OK +- 1: FLAG:SUSPEND +- 2: FLAG:REVOKE + +Note: There is no deletion in real practice for DIDs on blockchain, however deleting from registry and non-existing box storage record for that DID is taken as deletion definition for DID lifecycle on Algorand blockchain! + +```mermaid + +flowchart LR + creation[Creation] + registration[Registration] + resolution[Resolution] + use[Use] + suspension[Suspension -Optional] + revocation[Revocation -Optional] + deletion[Deletion] + creation -->|DID is generated| registration + registration -->|DID is registered| resolution + resolution -->|DID is resolved to DID Document| use + use -->|DID is actively used| suspension + suspension -->|DID is temporarily inactive| revocation + revocation -->|DID is permanently deactivated| deletion + +``` +## Implementations: + +### Algorand DID Registry +The DID registry is a must have when it comes to implement a global scaled DID compliant system! +GoPlausible has implemented the Algorand DID registry and resolution which already contains did resolution for all Algorand elements on TESTNET and MAINNET! + +```mermaid +flowchart TB + subgraph did_architecture ["Algorand DID Architecture"] + did_uri["Algorand DID URI"] + did_doc["Algorand DID Document"] + did_subject["DID Subject (e.g. asa, app, txn,...)"] + did_controller["DID Controller (Entity controlling the DID Document)"] + verifiable_data_registry["Verifiable Data Registry (Algorand Blockchain)"] + did_resolver["DID Resolver (Resolves DID to DID Document)"] + did_url_dereferencer["DID URL Dereferencer (Resolves DID URL to a Resource)"] + + did_uri -->|Resolves to| did_doc + did_doc -->|Describes| did_subject + did_doc -->|Controlled by| did_controller + did_uri -->|Recorded on| verifiable_data_registry + did_uri -->|Resolved by| did_resolver + did_uri -->|Dereferenced by| did_url_dereferencer + end + + style did_architecture stroke:#333,stroke-width:2px + +``` + +### Algorand DID Resolver UI +A fully working Resolver UI has been implemented and is available under GoPlausible MAINNET and TESTNET dApps (Algorand Universal DID Resolver) under standard endpoint (did-resolver/did:algo...) + +Algorand DID Resolver MAINNET UI: [goplausible.xyz/did-resolver/...](https://goplausible.xyz/did-resolver/did:algo:nfd:emg110.algo) + +Algorand DID Resolver TESTNET UI: [testnet.goplausible.xyz/did-resolver/...](https://testnet.goplausible.xyz/did-resolver/did:algo:nfd:emg110.algo) + +Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! + +### Algorand DID Resolver API +A fully working Resolver API has been implemented and is available under GoPlausible MAINNET and TESTNET APIs (Algorand Universal DID Resolver) under standard endpoint (/identifiers/1.0.0/did:algo...) + +Algorand DID Resolver MAINNET API: [goplausible.xyz/api/identifiers/1.0.0/...](https://goplausible.xyz/api/identifiers/1.0.0/did:algo:nfd:emg110.algo) + +Algorand DID Resolver TESTNET API: [testnet.goplausible.xyz/api/identifiers/1.0.0/...](https://testnet.goplausible.xyz/api/identifiers/1.0.0/did:algo:nfd:emg110.algo) + +### Algorand DID Resolver Client library +A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! + +The codebase instantiates an Algorand DID Resolver standard instance with DID and NETWORK arguments! + +Then resolver instance has two methods: + +- resolve(did: did) : This retrieves the DID document for given +- did_uri(id: string): This method creates a DID URI from Algorand element ID (TXN, ASA, APP) + +Algorand DID Resolver Client: [algo-did-resolver NPM Package](https://npm.org/algo-did-resolver) + +### Algorand DID Resolver ABI +A fully working Resolver ABI has been implemented and is available under GoPlausible MAINNET and TESTNET main contracts and serve as Algorand Universal DID Registry: + +GoPlausible MAINNET contract: [946441472](https://algoexplorer.io/application/946441472) + +GoPlausible TESTNET contract: [119642157](https://testnet.algoexplorer.io/application/119642157) + +Through these two ABI methods: + +``` + { + "name": "algo_did_register", + "args": [ + { + "type": "pay", + "name": "pay_box_mbr_fees" + }, + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + { + "type": "bytes[]", + "name": "Algorand DID doc", + "desc":"DID docs up to 8kb will be stored as box value and above 8kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format"" + } + + ], + "returns": { + "type": "string" + }, + "desc": "Called publicly by an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value! + + }, + { + "name": "algo_did_status", + "args": [ + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + ], + "returns": { + "type": "string" + }, + "desc": "Called publicly to get the DID status in registry" + }, + { + "name": "algo_did_status_set", + "args": [ + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + { + "type": "uint64", + "name": "Algorand DID status" + "desc": "Algorand DID status ['0:FLAG','1:OK']" + } + ], + "returns": { + "type": "string", + "desc": "Updated DID URI" + }, + "desc": "Called using registrar account to set DID status! Default registered DID status is 1" + }, + { + "name": "algo_did_resolve", + "args": [ + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + ], + "returns": { + "type": "string", + "desc": "Algorand DID document for given DID URI" + }, + "desc": "Called publicly to get DID document given a DID URI!" + }, + +``` + +## Appendix A: DID examples for all namespaces + +Examples of DIDs for each Algorand element type for both testnet and mainnet instance +- No namespace: +``` +did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q + +did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q +``` +- ASA: +``` +did:algo:testnet_asa:12400859 + +did:algo:mainnet_asa:31566704 +``` +- TXN: +``` +did:algo:testnet_txn:L3OEIRCTGDXALCIDLOLGXOM3OECHVNPI2GXN6PTNOEJJQIJ4FIWA + +did:algo:mainnet_txn:67HI3JHICQQB7KCWKCDYNANN57KL5LAUVQ3BJJFGRYEMAIEYBBVQ +``` +- APP: +``` +did:algo:testnet_app:110096026 + +did:algo:mainnet_app:350338509 +``` + +- UUID: +``` +did:algo:testnet_uuid:c6bc3d9f-3e2c-4170-99e7-b9809f229ecb + +did:algo:mainnet_uuid:6ba7b814-9dad-11d1-80b4-00c04fd430c8 +``` +- NFD/ANS: +``` +did:algo:nfd:emg110.algo +did:algo:ans:emg110.algo + +did:algo:nfd:emg110.algo +did:algo:ans:emg110.algo +``` +## Appendix B: DID document example TXN DID for a rekeyed account +```json +{ + "@context": [ + "https://w3id.org/did-resolution/v1"], + "didDocument": { + "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "@context": [ + "https://www.w3.org/ns/did/v1", + "https://w3id.org/security/suites/ed25519-2020/v1", + "https://w3id.org/security/v1" + ], + "verificationMethod": [ + { + "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#sender", + "publicKeyMultibase": "zCh9PDTZzeWxk2WdH4M1e8k2951D5D11jz7Uti9HRBGiK", + "type": "Ed25519VerificationKey2020" + }, + { + "controller": "did:algo:JKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", + "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#auth", + "publicKeyMultibase": "zGrjYfS1jotUQPyNqib75XNpGsS4ZL1MoPaEVF19a4W5h", + "type": "Ed25519VerificationKey2020" + }, + { + "controller": "did:algo:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", + "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", + "publicKeyMultibase": "zGrjYfS1jotUQPyNqib75XNpGsS4ZL1MoPaEVF19a4W5h", + "type": "Ed25519VerificationKey2020" + } + ], + "authentication": [ + + "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#auth" + ], + "service": [ + { + "id": "did:algo:web:mainnet_node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "type": "did.algo.web.ExternalService", + "serviceEndpoint": "https://mainnet_node/", + "extensions": [ + { + "id": "algorand-state-proof", + "version": "1.0.0", + "data": [ + { + + "network": "mainnet", + "hashtype": "sha512_256", + "idx": 12, + "proof": "SGjVwQA4GGhBSfJ1uXJXWk0lNyyk6/Nq3tJI4fHAIWzGarYxDRBllj+gjjTKsPeFuMzuOkVqw58LDrmqucrYU+pbp9laI9DUE1UG7KcUj+QxXqmW/qsaQ+j74hVKMaHSWLxqjcMKUiSORivvBTp8XxFGWgUotwHtgBCQzkJ3MXHF41RA3zvDuluLMtS1diU6FLycYti0QRH9oBS57vcHn82PzPgD+k9rlPoJZY06lRxmz0Zlc1TKNThvqr+1Mu+C", + "stibhash": "ruGptxPK5UiqPM9MuOFk2t7MfOfXsvfGlDnatxDCHb0=", + "treedepth": 6, + "confirmed-round": 34390581, + },{ + + } + ] + } + ] + }, + { + "id": "did:algo:web:mainnet_idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "type": "did.algo.web.ExternalService", + "serviceEndpoint": "https://mainnet_idx/", + "extensions": [ + { + "id": "algorand-signature", + "version": "1.0.0", + "data": [ + { + "sig": "ug24mUImTRg8lzjAB8Y/FPzakKYoMwDUl+nVrQHlsUwnnLHipUdjtGV3NG3oVgxbJAgMGUK0exfUY27cePvMAQ==", + "network": "mainnet", + "confirmed-round": 34390581, + } + ] + } + ] + } + ] + + + }, + "didDocumentMetadata": { + "created": "2023-03-23T19:15:10Z", + "deactivated": false, + "updated": "2023-03-23T20:11:30Z" + }, + "didResolutionMetadata": { + "contentType": "application/ld+json", + "retrieved": "2023-05-15T17:39:30Z" + } +} + +``` + +## 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/)! \ No newline at end of file From 9378745875258a76e808ef11ab68564692006020 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 22:04:37 +0300 Subject: [PATCH 002/116] Fix typo --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index a96a357c2..2462f2463 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -1,6 +1,6 @@ --- arc: 13 -title: Decentiralized identifiers (DIDs) +title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) V 1.0 living standard URI format conventions for Algorand blockchain identifier elements. author: MG (@emg110) status: Draft From c02369e629659516f7006e4426b8bdff16854b53 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 22:37:46 +0300 Subject: [PATCH 003/116] Update appendix and state of art --- ARCs/arc-0013.md | 58 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 47 insertions(+), 11 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 2462f2463..f8885a9ba 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -64,8 +64,6 @@ algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / " method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem - - ``` ### Main elements @@ -121,8 +119,50 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` -## Implementations: +## State of art: +One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! + +The ARC13 Algorand DID registry specification includes: + +- An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! +- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! + +Including a `verificationMethod` like a stateproof in a DID document is a powerful way to leverage blockchain technology for enhancing the security and verifiability of digital identities. This approach is particularly suitable for blockchain-based DIDs, where the immutability and transparency of the ledger can be used to provide cryptographic proof of the DID document's validity. + +1. **Stateproof as a Verification Method**: + - In the case of Algorand, a stateproof can serve as a cryptographic proof that a particular state (including transactions and, potentially, DID documents) was indeed part of the blockchain at a given point in time. + - By including a reference to a stateproof or a similar mechanism in the `verificationMethod` section of a DID document, it's possible to provide a way to independently verify that the DID document (or the transaction that created it) is valid and has been recorded on the blockchain. + +2. **Enhancing Trust and Integrity**: + - This approach enhances the trustworthiness of the DID document. Verifiers can use the provided stateproof to confirm the document's authenticity without relying solely on the infrastructure provided by the DID method. + - It aligns with the decentralized and trustless nature of blockchain technology, where verification doesn't depend on a central authority. + +3. **Implementation Considerations**: + - The specific implementation of this verification method would depend on the capabilities of the blockchain platform and the design of the DID method. + - The DID document would need to include enough information to allow a verifier to obtain and validate the stateproof against the blockchain. + +Important considerations regarding transaction DIDs with offline and online self verification methods: + +1. **Verification Methods for Transaction DIDs**: + - A DID document can include public key verification methods that are specifically used to verify the authenticity and integrity of the transaction associated with the DID. + - The controller of these verification methods can be the entity that initiated the transaction, such as the transaction sender. + +2. **Scope of Verification Methods**: + - The DID document can be tailored to include only those verification methods that are relevant to the transaction. This means it can carry verification methods solely for the purpose of verifying the transaction DID itself. + - The controllers of these verification methods would typically be entities involved in the transaction, ensuring that the verification process is directly linked to the transaction's participants. +3. **Compliance with DID Standard**: + - This approach is compliant with the DID standard, which is flexible and allows for various implementations and use cases. The standard does not restrict the types of verification methods that can be included in a DID document, as long as they adhere to the overall structure and principles of DIDs. + +4. **Use Case Specificity**: + - This kind of implementation is particularly useful in blockchain-based environments where transactions are key elements of the system. The DID document effectively becomes a tool for transaction verification. + + +## Future work and TODO: +As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods, hence there are some further steps to make it complete coverage regarding DID lifecycle: +- Client side stateproof verification using DID information to verify Algorand DID's self authenticity + +## Implementations: ### Algorand DID Registry The DID registry is a must have when it comes to implement a global scaled DID compliant system! GoPlausible has implemented the Algorand DID registry and resolution which already contains did resolution for all Algorand elements on TESTNET and MAINNET! @@ -261,6 +301,8 @@ Through these two ABI methods: ``` + + ## Appendix A: DID examples for all namespaces Examples of DIDs for each Algorand element type for both testnet and mainnet instance @@ -303,7 +345,7 @@ did:algo:ans:emg110.algo did:algo:nfd:emg110.algo did:algo:ans:emg110.algo ``` -## Appendix B: DID document example TXN DID for a rekeyed account +## Appendix B: DID document example TXN DID from a rekeyed account ```json { "@context": [ @@ -335,10 +377,6 @@ did:algo:ans:emg110.algo "type": "Ed25519VerificationKey2020" } ], - "authentication": [ - - "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#auth" - ], "service": [ { "id": "did:algo:web:mainnet_node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", @@ -375,7 +413,7 @@ did:algo:ans:emg110.algo "version": "1.0.0", "data": [ { - "sig": "ug24mUImTRg8lzjAB8Y/FPzakKYoMwDUl+nVrQHlsUwnnLHipUdjtGV3NG3oVgxbJAgMGUK0exfUY27cePvMAQ==", + "sig": "ug24mUImTRg8lzjAB8Y/FPzakKYoMwDUl+nVrQHlsUwnnLHipUdjtGV3NG3oVgxbJAgMGUK0exfUY27cePvMAQ==", "network": "mainnet", "confirmed-round": 34390581, } @@ -384,8 +422,6 @@ did:algo:ans:emg110.algo ] } ] - - }, "didDocumentMetadata": { "created": "2023-03-23T19:15:10Z", From 5beeddea1ccf1792989682c13b0fab33f5a3a4cd Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 22:58:36 +0300 Subject: [PATCH 004/116] Corrected mistake --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index f8885a9ba..705f7fdca 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,7 +60,7 @@ The Algorand extended DID Syntax ABNF: did = "did:" method-name ":" method-specific-id method-name = "algo" ; Algorand method name algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers -algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "logicsig"; Algorand namespace identifiers +algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" ; Algorand namespace identifiers method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem From 36483bbc772301eeaba7acec90f2a52cc4ccd9d9 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 23:04:51 +0300 Subject: [PATCH 005/116] Fix example controller --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 705f7fdca..a369ebdd2 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -371,7 +371,7 @@ did:algo:ans:emg110.algo "type": "Ed25519VerificationKey2020" }, { - "controller": "did:algo:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", + "controller": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", "publicKeyMultibase": "zGrjYfS1jotUQPyNqib75XNpGsS4ZL1MoPaEVF19a4W5h", "type": "Ed25519VerificationKey2020" From 3bba841188a10a8e3efecaba56af837f135a18c4 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 23:14:40 +0300 Subject: [PATCH 006/116] Update future work --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index a369ebdd2..0beacf184 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -160,7 +160,8 @@ Important considerations regarding transaction DIDs with offline and online self ## Future work and TODO: As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods, hence there are some further steps to make it complete coverage regarding DID lifecycle: -- Client side stateproof verification using DID information to verify Algorand DID's self authenticity +- Client side stateproof verification using DID information to implement Algorand DID self verification +- Add goal CLI to verification method services (up for debate) ## Implementations: ### Algorand DID Registry From 09aa4919bca13bfa31703702d9dd08e6fa62b0c1 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 19 Dec 2023 23:23:43 +0300 Subject: [PATCH 007/116] Add terminology --- ARCs/arc-0013.md | 91 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 90 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 0beacf184..fe2790b8a 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -159,7 +159,8 @@ Important considerations regarding transaction DIDs with offline and online self ## Future work and TODO: -As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods, hence there are some further steps to make it complete coverage regarding DID lifecycle: +As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods in all reference implementations, hence there are some further steps to make it complete coverage regarding DID lifecycle: + - Client side stateproof verification using DID information to implement Algorand DID self verification - Add goal CLI to verification method services (up for debate) @@ -436,6 +437,94 @@ did:algo:ans:emg110.algo } ``` +## Terminology: + +- decentralized identifier (DID) +A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. + +- decentralized identity management +Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. + +- DID controller +An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. + +- DID delegate +An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. + +- DID document +A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. + +- DID fragment +The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. + +- DID method +A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. See 8. Methods. + +- DID path +The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. See Path. + +- DID query +The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. See Query. + +- DID resolution +The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. The inputs and outputs of this process are defined in 7.1 DID Resolution. + +- DID resolver +A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming +DID document as output. + +- DID scheme +The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in 3.1 DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. In a specific DID method scheme, the DID method name follows the first colon and terminates with the second colon, e.g., did:example: + +- DID subject +The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. + +- DID URL +A DID plus any additional syntactic component that conforms to the definition in 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character). + +- DID URL dereferencing +The process that takes as its input a DID URL and a set of input metadata, and returns a resource. This resource might be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document. The process uses DID resolution to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing process can then perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL. The inputs and outputs of this process are defined in 7.2 DID URL Dereferencing. + +- DID URL dereferencer +A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document. + +- public key description +A data object contained inside a DID document that contains all the metadata necessary to use a public key or a verification key. +resource +As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a DID subject identified by a DID. + +- representation +As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject. See 6. Representations. + +- representation-specific entries +Entries in a DID document whose meaning is particular to a specific representation. Defined in 4. Data Model and 6. Representations. For example, @context in the JSON-LD representation is a representation-specific entry. + +- services +Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services. + +- service endpoint, node, idx +A network address, such as an HTTP URL, at which services operate on behalf of a DID subject. +Uniform Resource Identifier (URI) +The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. + +- verifiable credential +A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL]. + +- verifiable data registry +A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification [VC-DATA-MODEL]. + +- verifiable timestamp +A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. + +- verification method +A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. +"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof." + +- verification relationship +An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is 5.3.1 Authentication. + +- Universally Unique Identifier (UUID) +A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable. ## Copyright From d97402049f82113350b0cac177aa63893bbd98d3 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 00:17:33 +0300 Subject: [PATCH 008/116] Add note to ABNF extension --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index fe2790b8a..40151cadb 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,11 +60,12 @@ The Algorand extended DID Syntax ABNF: did = "did:" method-name ":" method-specific-id method-name = "algo" ; Algorand method name algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers -algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" ; Algorand namespace identifiers +algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "addr" ; Algorand namespace identifiers method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem ``` +Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! ### Main elements From 9be80b614028d3740aeb8b33226a6f6284dc578f Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 00:54:44 +0300 Subject: [PATCH 009/116] Update example DID --- ARCs/arc-0013.md | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 40151cadb..8617fbc16 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -361,23 +361,10 @@ did:algo:ans:emg110.algo "https://w3id.org/security/v1" ], "verificationMethod": [ - { - "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#sender", - "publicKeyMultibase": "zCh9PDTZzeWxk2WdH4M1e8k2951D5D11jz7Uti9HRBGiK", - "type": "Ed25519VerificationKey2020" - }, - { - "controller": "did:algo:JKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", - "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#auth", - "publicKeyMultibase": "zGrjYfS1jotUQPyNqib75XNpGsS4ZL1MoPaEVF19a4W5h", - "type": "Ed25519VerificationKey2020" - }, + "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", { "controller": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", - "publicKeyMultibase": "zGrjYfS1jotUQPyNqib75XNpGsS4ZL1MoPaEVF19a4W5h", - "type": "Ed25519VerificationKey2020" } ], "service": [ From 1b3bb68f7ffb23d68ea9239c18c02908ad027ed5 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 00:57:25 +0300 Subject: [PATCH 010/116] Assert example dummy data --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 8617fbc16..d6660f1c4 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -348,7 +348,7 @@ did:algo:ans:emg110.algo did:algo:nfd:emg110.algo did:algo:ans:emg110.algo ``` -## Appendix B: DID document example TXN DID from a rekeyed account +## Appendix B: DID document example with dummy data ```json { "@context": [ From a1c21633e90b19a55cf09343509fe290a5a244f6 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 02:16:25 +0300 Subject: [PATCH 011/116] Update --- ARCs/arc-0013.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d6660f1c4..6c2b30b77 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -230,9 +230,10 @@ GoPlausible TESTNET contract: [119642157](https://testnet.algoexplorer.io/applic Through these two ABI methods: + ``` { - "name": "algo_did_register", + "name": "register_algo_did", "args": [ { "type": "pay", @@ -245,7 +246,7 @@ Through these two ABI methods: { "type": "bytes[]", "name": "Algorand DID doc", - "desc":"DID docs up to 8kb will be stored as box value and above 8kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format"" + "desc": "DID docs up to 4kb will be stored as box value and above 4kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format"" } ], @@ -256,7 +257,7 @@ Through these two ABI methods: }, { - "name": "algo_did_status", + "name": "get_algo_did_status", "args": [ { "type": "bytes[]", @@ -269,7 +270,7 @@ Through these two ABI methods: "desc": "Called publicly to get the DID status in registry" }, { - "name": "algo_did_status_set", + "name": "set_algo_did_status", "args": [ { "type": "bytes[]", @@ -285,10 +286,10 @@ Through these two ABI methods: "type": "string", "desc": "Updated DID URI" }, - "desc": "Called using registrar account to set DID status! Default registered DID status is 1" + "desc": "Called using registrar account or DID controller to set DID status! Default registered DID status is 0" }, { - "name": "algo_did_resolve", + "name": "resolve_algo_did", "args": [ { "type": "bytes[]", From 5ff1feee6ae1dd4a0992ff32aedfa620e05b0c2d Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 16:14:05 +0300 Subject: [PATCH 012/116] Update ABI methods --- ARCs/arc-0013.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6c2b30b77..c151dd652 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -232,6 +232,8 @@ Through these two ABI methods: ``` + + { "name": "register_algo_did", "args": [ @@ -246,14 +248,14 @@ Through these two ABI methods: { "type": "bytes[]", "name": "Algorand DID doc", - "desc": "DID docs up to 4kb will be stored as box value and above 4kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format"" + "desc": "DID docs up to 4kb will be stored as box value and above 4kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format" } ], "returns": { "type": "string" }, - "desc": "Called publicly by an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value! + "desc": "Called publicly by an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value!" }, { @@ -262,7 +264,7 @@ Through these two ABI methods: { "type": "bytes[]", "name": "Algorand DID URI" - }, + } ], "returns": { "type": "string" @@ -278,7 +280,7 @@ Through these two ABI methods: }, { "type": "uint64", - "name": "Algorand DID status" + "name": "Algorand DID status", "desc": "Algorand DID status ['0:FLAG','1:OK']" } ], @@ -294,14 +296,14 @@ Through these two ABI methods: { "type": "bytes[]", "name": "Algorand DID URI" - }, + } ], "returns": { "type": "string", "desc": "Algorand DID document for given DID URI" }, "desc": "Called publicly to get DID document given a DID URI!" - }, + } ``` From 4e18ec9ba4d56c8b9f5cb5ba15569c49991c64c4 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 16:41:43 +0300 Subject: [PATCH 013/116] Update ABI schema --- ARCs/arc-0013.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c151dd652..85e950805 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -232,7 +232,6 @@ Through these two ABI methods: ``` - { "name": "register_algo_did", @@ -274,6 +273,10 @@ Through these two ABI methods: { "name": "set_algo_did_status", "args": [ + { + "type": "pay", + "name": "pay_box_mbr_fees" + }, { "type": "bytes[]", "name": "Algorand DID URI" From b20a0d7526e0e8c76684b2c8a2b17faff7740364 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 20 Dec 2023 16:42:48 +0300 Subject: [PATCH 014/116] Update ABI schema --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 85e950805..40a594fb6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -284,7 +284,7 @@ Through these two ABI methods: { "type": "uint64", "name": "Algorand DID status", - "desc": "Algorand DID status ['0:FLAG','1:OK']" + "desc": "Algorand DID status ['0:OK','1:FLAG:SUSPEND', '2: FLAG:REVOKE']" } ], "returns": { From e0bdabe4439092955f4e423f0bf7c87188777c5c Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 21 Dec 2023 19:08:57 +0300 Subject: [PATCH 015/116] Update authors --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 40a594fb6..f040b733e 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -2,7 +2,7 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) V 1.0 living standard URI format conventions for Algorand blockchain identifier elements. -author: MG (@emg110) +author: MG (@emg110), GoPlausible(@GoPlausible), GoraNetwork (@GoraNetwork) status: Draft type: Standards Track category: Interface and Convention From eba74d31211a2affa12f7c786fecf5444183804d Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 08:50:43 +0300 Subject: [PATCH 016/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index f040b733e..d3e4e2387 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standard's requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) and [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standard's requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) From 3e83088d4a093a9e007671be7e462b030446a93e Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 08:51:06 +0300 Subject: [PATCH 017/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d3e4e2387..5425794e0 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) and [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standard's requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) and [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) From 3e2b9fa168f79bbcaff50459407a88dc3fa1a76d Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 12:29:58 +0300 Subject: [PATCH 018/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 5425794e0..5b5cad754 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) and [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) and [W3C Multibase format](https://w3c-ccg.github.io/multibase/)living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) From 6aae55f343700ce9fc94909346d4de4470071ebf Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 12:31:00 +0300 Subject: [PATCH 019/116] Update TODOs --- ARCs/arc-0013.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 5b5cad754..e0f266bdf 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -164,6 +164,9 @@ As stateproofs are already integrated as an extension service to all Algorand DI - Client side stateproof verification using DID information to implement Algorand DID self verification - Add goal CLI to verification method services (up for debate) +- Add multibase formatting for publickey +- Add resolution conventions +- Add more detail DID formatting ## Implementations: ### Algorand DID Registry From f898be84e7a1a1a62a01a99ae1bc2ebfa261e6e0 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 12:36:41 +0300 Subject: [PATCH 020/116] Update TODO --- ARCs/arc-0013.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e0f266bdf..e725e596d 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -168,6 +168,10 @@ As stateproofs are already integrated as an extension service to all Algorand DI - Add resolution conventions - Add more detail DID formatting +IMPORTANT TODO: +- Integrating resolver endpoints in Algod and Indexer endpoints on Algorand so that resolver goes global +- Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) + ## Implementations: ### Algorand DID Registry The DID registry is a must have when it comes to implement a global scaled DID compliant system! From 5af90f76b55d8a7f13fac6bb492bbedc79ef644d Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 12:44:23 +0300 Subject: [PATCH 021/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e725e596d..0fd9ebbb4 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) and [W3C Multibase format](https://w3c-ccg.github.io/multibase/)living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) and [W3C Multibase format](https://w3c-ccg.github.io/multibase/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) From 4a62a73d0070eb13be4aeed08af7c46d851db8dc Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 22 Dec 2023 16:05:59 +0300 Subject: [PATCH 022/116] Fix typo in resolver URL --- ARCs/arc-0013.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 0fd9ebbb4..eaa4147a3 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -210,11 +210,11 @@ Algorand DID Resolver TESTNET UI: [testnet.goplausible.xyz/did-resolver/...](htt Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! ### Algorand DID Resolver API -A fully working Resolver API has been implemented and is available under GoPlausible MAINNET and TESTNET APIs (Algorand Universal DID Resolver) under standard endpoint (/identifiers/1.0.0/did:algo...) +A fully working Resolver API has been implemented and is available under GoPlausible MAINNET and TESTNET APIs (Algorand Universal DID Resolver) under standard endpoint (/1.0/identifiers//did:algo...) -Algorand DID Resolver MAINNET API: [goplausible.xyz/api/identifiers/1.0.0/...](https://goplausible.xyz/api/identifiers/1.0.0/did:algo:nfd:emg110.algo) +Algorand DID Resolver MAINNET API: [goplausible.xyz/api/1.0/identifiers//...](https://goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) -Algorand DID Resolver TESTNET API: [testnet.goplausible.xyz/api/identifiers/1.0.0/...](https://testnet.goplausible.xyz/api/identifiers/1.0.0/did:algo:nfd:emg110.algo) +Algorand DID Resolver TESTNET API: [testnet.goplausible.xyz/api/1.0/identifiers//...](https://testnet.goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) ### Algorand DID Resolver Client library A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! From f66fc8913ddf09e4f3efda870ea8ed659ee2d8f1 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 18:41:59 +0300 Subject: [PATCH 023/116] Update --- ARCs/arc-0013.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index eaa4147a3..93a9d99af 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -2,16 +2,16 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) V 1.0 living standard URI format conventions for Algorand blockchain identifier elements. -author: MG (@emg110), GoPlausible(@GoPlausible), GoraNetwork (@GoraNetwork) +author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track -category: Interface and Convention +category: Interface Convention and URI Scheme created: 2023-12-18 --- ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) and [W3C Multibase format](https://w3c-ccg.github.io/multibase/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) From f989379d8326992ab6ee1fd5c968d42aaab53df8 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 18:43:36 +0300 Subject: [PATCH 024/116] Update --- ARCs/arc-0013.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 93a9d99af..7c33781ac 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -27,6 +27,8 @@ Algorand specific features have been reflected into this ARC in full extent: - Methods and operations - Tech stack (available and in use) - Requirements + +NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. From 0ebec0c7f680628be9ee4d60673e255734a25777 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:13:26 +0300 Subject: [PATCH 025/116] Update --- ARCs/arc-0013.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 7c33781ac..aa1958412 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,14 +11,17 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARCs that ARC13 comply to and also extend are: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: + - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) -- [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) -- [ARC110](https://arc.algorand.foundation/ARCs/arc-0110) +- [ARC69](https://arc.algorand.foundation/ARCs/arc-0072) +- [ARC69](https://arc.algorand.foundation/ARCs/arc-0200) - [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) +ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! + To implement DID naming , namespace, ABNF grammar and DID registry specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in this ARC's scope! Algorand specific features have been reflected into this ARC in full extent: From 7783a84a22dcd9ccd474c1eb42156ccc58ae0117 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:14:12 +0300 Subject: [PATCH 026/116] Fix typos --- ARCs/arc-0013.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index aa1958412..e20504003 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -16,8 +16,8 @@ This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3. - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) -- [ARC69](https://arc.algorand.foundation/ARCs/arc-0072) -- [ARC69](https://arc.algorand.foundation/ARCs/arc-0200) +- [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) +- [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) - [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! From 1e7336c571aa655ed45a649482ac6b49ecdf7e5d Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:17:55 +0300 Subject: [PATCH 027/116] Update --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e20504003..edd4c4658 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -18,7 +18,8 @@ This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3. - [ARC69](https://arc.algorand.foundation/ARCs/arc-0069) - [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) -- [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) + +ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! From a9bb5776d4eda9378df814b3e84e43193b29685b Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:18:24 +0300 Subject: [PATCH 028/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index edd4c4658..eab836f51 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -5,7 +5,7 @@ description: DID (Decentralized identifier) V 1.0 living standard URI format con author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track -category: Interface Convention and URI Scheme +category: Interface, Identity Convention and URI Scheme created: 2023-12-18 --- From 9031b7c95a4353dce9cde1b54a3c23e68f6263d0 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:22:57 +0300 Subject: [PATCH 029/116] Update --- ARCs/arc-0013.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index eab836f51..cc92134e4 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -19,6 +19,8 @@ This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3. - [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) +ARC13 has taken insights, inspiration and even some method approaches from layed foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did! + ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! From ce585db9ffdb83983a6eb30fe57c6b6161d5a3ae Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 23 Dec 2023 19:23:18 +0300 Subject: [PATCH 030/116] Fixed typo --- ARCs/arc-0013.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index cc92134e4..ccaa2ff20 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -19,8 +19,8 @@ This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3. - [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) -ARC13 has taken insights, inspiration and even some method approaches from layed foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did! - +ARC13 has taken insights, inspiration and even some method approaches from foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did! + ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! From b5d8e54948c02e57553c7a370b637193932001be Mon Sep 17 00:00:00 2001 From: MG Date: Sun, 24 Dec 2023 11:23:55 +0300 Subject: [PATCH 031/116] Add elemental composed --- ARCs/arc-0013.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index ccaa2ff20..f10e94b02 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -27,13 +27,20 @@ ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) w To implement DID naming , namespace, ABNF grammar and DID registry specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in this ARC's scope! +ARC13 proposes two category of identifiers: + +- Elemental :Native element transactions and derived elements app, asa, acc (these DID are dynamically generated using ledger data and some applied methods and conventions)! Elemental DIDs do not need any registry and decentralized ledger acts as registry for elementals! +- Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a dynamic composed identifier registered as on-chain DIDs! Composed DIDs are in need of registry, lifecycle management and universal resolver decentralized instrumentation and infrastructure! + Algorand specific features have been reflected into this ARC in full extent: - Composability - Elements and namespace conventions - Methods and operations - Tech stack (available and in use) - Requirements - + +ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. + NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification From 3b8764196a18c4e5e6a3958e72cb111755488004 Mon Sep 17 00:00:00 2001 From: MG Date: Sun, 24 Dec 2023 11:24:52 +0300 Subject: [PATCH 032/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index f10e94b02..6ee80b358 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -32,7 +32,7 @@ ARC13 proposes two category of identifiers: - Elemental :Native element transactions and derived elements app, asa, acc (these DID are dynamically generated using ledger data and some applied methods and conventions)! Elemental DIDs do not need any registry and decentralized ledger acts as registry for elementals! - Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a dynamic composed identifier registered as on-chain DIDs! Composed DIDs are in need of registry, lifecycle management and universal resolver decentralized instrumentation and infrastructure! -Algorand specific features have been reflected into this ARC in full extent: +Algorand technology specific features are intended to reflect into this ARC in full: - Composability - Elements and namespace conventions - Methods and operations From 4f9287433da9ccab14d3e2999e55e9ca37d06ab2 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 13:35:59 +0300 Subject: [PATCH 033/116] Update arrangements and segment content --- ARCs/arc-0013.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6ee80b358..fef13bac7 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,9 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! + +ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) - [ARC19](https://arc.algorand.foundation/ARCs/arc-0019) @@ -19,7 +21,21 @@ This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3. - [ARC72](https://arc.algorand.foundation/ARCs/arc-0072) - [ARC200](https://arc.algorand.foundation/ARCs/arc-0200) -ARC13 has taken insights, inspiration and even some method approaches from foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did! +Algorand technology specific features are intended to reflect into this ARC in full: +- Composability +- Elements and namespace conventions +- Methods and operations +- Tech stack (available and in use) +- Requirements + +NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! + +## Specification +The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its unique features and existing ARCs in motion (not only finalized). + +This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. + +ARC13 has taken insights, inspiration and even some method approaches from foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized (architectural) approach! ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! @@ -31,21 +47,9 @@ ARC13 proposes two category of identifiers: - Elemental :Native element transactions and derived elements app, asa, acc (these DID are dynamically generated using ledger data and some applied methods and conventions)! Elemental DIDs do not need any registry and decentralized ledger acts as registry for elementals! - Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a dynamic composed identifier registered as on-chain DIDs! Composed DIDs are in need of registry, lifecycle management and universal resolver decentralized instrumentation and infrastructure! - -Algorand technology specific features are intended to reflect into this ARC in full: -- Composability -- Elements and namespace conventions -- Methods and operations -- Tech stack (available and in use) -- Requirements ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. -NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! - -## Specification -The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) Data Model with the Algorand blockchain, leveraging its unique features and existing ARCs. This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. - ### 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. From d0315a6e656afc8cf0af256d636ac817daf6d6ee Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 13:38:50 +0300 Subject: [PATCH 034/116] Update Rationale --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index fef13bac7..710662fb5 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -96,7 +96,7 @@ The main elements of the Algorand DID based on the DID data model are: - Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). ## Rationale -ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and beyond. +ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and Enterprise sector to be general. Note: Algorand account addresses have no namespace and are considered root namespace under :algo! From 7103ab8ec10ae4077c1cfb5c67d7024e41a4c7cb Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 13:39:37 +0300 Subject: [PATCH 035/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 710662fb5..95e4940d3 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -96,7 +96,7 @@ The main elements of the Algorand DID based on the DID data model are: - Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). ## Rationale -ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and Enterprise sector to be general. +ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). Note: Algorand account addresses have no namespace and are considered root namespace under :algo! From 13ab199e10b1fabdcbab15acb6d983d8dfd69bd4 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 14:18:18 +0300 Subject: [PATCH 036/116] Fix typo --- ARCs/arc-0013.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 95e4940d3..93c61dbc7 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -98,12 +98,18 @@ The main elements of the Algorand DID based on the DID data model are: ## Rationale ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). -Note: Algorand account addresses have no namespace and are considered root namespace under :algo! +The rationale on namespaces includes : +- Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! +For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and AVM chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for AVM elements e.g. accounts! + -UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities! As comparability is one of Algorand product mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! +UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! +As composability is one of Algorand product mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! +Note: Algorand account addresses have no namespace and are considered root namespace under :algo! + ## Security Considerations 1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial. From 5fe208e499acea71fa4853e7232e0cc00b188e2a Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 14:18:30 +0300 Subject: [PATCH 037/116] Fix typo --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 93c61dbc7..9af4167b2 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -104,7 +104,7 @@ For example resolve chain IDs to chain names has been omitted by not using chain UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! -As composability is one of Algorand product mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! +As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! From 26d57edba525bdbe6b105029d81eac7b5a5d6fd1 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 14:19:08 +0300 Subject: [PATCH 038/116] Update --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 9af4167b2..99f5bd750 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -104,7 +104,8 @@ For example resolve chain IDs to chain names has been omitted by not using chain UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! -As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof! + +As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof on usability and extendability! NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! From f02f0e18c486d5a7ea192294bc3b7d9e75582a08 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 14:23:35 +0300 Subject: [PATCH 039/116] Update main elements --- ARCs/arc-0013.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 99f5bd750..e297ca8f6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -94,6 +94,8 @@ The main elements of the Algorand DID based on the DID data model are: - Network Identifier: testnet_ or mainnet_ Specifies the Algorand network (testnet or mainnet). - Namespace: Identifies the type of Algorand element the DID represents (e.g., asa, txn, app). - Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). +- Local elements: AVM Elements with locally Unique Identifiers like assets and applications! +- Global elements: AVM Elements with global Unique Identifiers like Transactions, account addresses, UUIDs, IPFS CIDs! ## Rationale ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). @@ -113,7 +115,7 @@ Note: Algorand account addresses have no namespace and are considered root names ## Security Considerations -1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial. +1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial but is out of this ARC scope and goes under Wallet providers concerns! 2. DID Document Integrity: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. 3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. From 3575f61ba1e2b24ad9e26215895262d806a1ecc9 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 14:31:17 +0300 Subject: [PATCH 040/116] Update --- ARCs/arc-0013.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e297ca8f6..874d79149 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -13,6 +13,8 @@ created: 2023-12-18 This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! +ARC13 is best implementable as a group, together with ARC113 and ARC110! + ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: - [ARC3](https://arc.algorand.foundation/ARCs/arc-0003) @@ -91,14 +93,18 @@ Note : "addr" should be used with network element as it represents Algorand appl The main elements of the Algorand DID based on the DID data model are: - DID Scheme: did:algo: The unique scheme for Algorand DIDs. +- Element: An AVM or complementary service element as a subject for DID - Network Identifier: testnet_ or mainnet_ Specifies the Algorand network (testnet or mainnet). - Namespace: Identifies the type of Algorand element the DID represents (e.g., asa, txn, app). - Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). - Local elements: AVM Elements with locally Unique Identifiers like assets and applications! - Global elements: AVM Elements with global Unique Identifiers like Transactions, account addresses, UUIDs, IPFS CIDs! +- Internal elements: Elements under direct verification authority and tooling of AVM chains (TXN, ASA, APP, ACC) +- Service elements: Elements out of verification authority and tooling of AMV chains (IPFS, URI, DOID,...) ## Rationale -ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). + +ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public and decentralized way. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). The rationale on namespaces includes : - Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! From 0c5bb19d86f7e45b8734f2a1bc178d539ba767ab Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 15:14:55 +0300 Subject: [PATCH 041/116] Update --- ARCs/arc-0013.md | 4 ++-- assets/arc-0013/did_detailed_architecture_overview.svg | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) create mode 100644 assets/arc-0013/did_detailed_architecture_overview.svg diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 874d79149..dd9d35a76 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -13,7 +13,7 @@ created: 2023-12-18 This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! -ARC13 is best implementable as a group, together with ARC113 and ARC110! +ARC13 is best implementable as a group, together with [ARC113](https://github.com/GoPlausible/ARCs/blob/ARC-0113/ARCs/arc-0113.md) and [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)! ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: @@ -154,7 +154,7 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` -## State of art: +## Customized implementation: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! The ARC13 Algorand DID registry specification includes: diff --git a/assets/arc-0013/did_detailed_architecture_overview.svg b/assets/arc-0013/did_detailed_architecture_overview.svg new file mode 100644 index 000000000..db343fc0c --- /dev/null +++ b/assets/arc-0013/did_detailed_architecture_overview.svg @@ -0,0 +1,3 @@ + + +


resolves to

resolves to

DID
subject

DID...

DID
controller

DID...

DID URL

DID URL

fragment

fragment

query

query

path

path

DID

DID

fragment refers, and
dereferences, to

fragment refers, and...

DID document

DID document

…

…

…

…

(property Y)

(property Y)

id

id

alsoKnownAs

alsoKnownAs

…

…

(property X)

(property X)

…

…

External
Resource

External...

DID
Method

DID...

method-id

method-id

method-specific-id

method-specific-id

did:

did:

:

:

DID

DID

DID URL
Dereferencer

DID URL...

DID
Resolver

DID...

DID document-relative
fragment dereference

DID document-relative...

recorded on

recorded on

recorded on

recorded on

refers to

refers to

controls

controls

implements

implements

implements

implements

implements

implements

implements

implements

instructs

instructs

instructs

instructs

operates

operates

dereferences
 to

dereferences...

refers to

refers to

contains

contains
Verifiable
Data
Registry
Verifiable...Viewer does not support full SVG 1.1 \ No newline at end of file From 3a1487720403fec6d1c807e0a570f30a1be44442 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 15:15:30 +0300 Subject: [PATCH 042/116] Update --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index dd9d35a76..90b2e353a 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -154,7 +154,7 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` -## Customized implementation: +## Customized specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! The ARC13 Algorand DID registry specification includes: @@ -207,6 +207,7 @@ IMPORTANT TODO: - Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) ## Implementations: + ### Algorand DID Registry The DID registry is a must have when it comes to implement a global scaled DID compliant system! GoPlausible has implemented the Algorand DID registry and resolution which already contains did resolution for all Algorand elements on TESTNET and MAINNET! From ec8c33d6455164aa7d6066748dbe40318e76454e Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 15:32:08 +0300 Subject: [PATCH 043/116] Update --- ARCs/arc-0013.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 90b2e353a..713b1f91b 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -126,6 +126,11 @@ Note: Algorand account addresses have no namespace and are considered root names 3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. Note: The UUID namespace MUST be isolated by network for security reasons! +## DID general architecture +![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) +Curtsey of W3C + + ## DID lifecycle A DID has different life stages depicted here and this stage status is reflected in value of DID "status" field! The status different values: From 97266e2fc875a8b783363ed445278e450cc6b2cc Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 15:32:22 +0300 Subject: [PATCH 044/116] Update --- ARCs/arc-0013.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 713b1f91b..e1642a1c6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -126,6 +126,7 @@ Note: Algorand account addresses have no namespace and are considered root names 3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. Note: The UUID namespace MUST be isolated by network for security reasons! + ## DID general architecture ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) Curtsey of W3C From fc3403f862caf18bdda02108bea8aa0ede250e1f Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 15:51:10 +0300 Subject: [PATCH 045/116] Update DID general architecture --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e1642a1c6..0915552f2 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -129,7 +129,7 @@ Note: The UUID namespace MUST be isolated by network for security reasons! ## DID general architecture ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -Curtsey of W3C +Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) ## DID lifecycle From 3ea7398b10cacc2483e98ac5349156002ca9f72a Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:12:36 +0300 Subject: [PATCH 046/116] Update --- ARCs/arc-0013.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 0915552f2..35272e7f8 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -88,6 +88,25 @@ algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem ``` Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! + +dApp DID URL Syntax: + +A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: +- IPFS +- NFD/ANS +- web +- UUID +- ADDR (in case of onchain dApp data) +- ASA (in case of composite or collection or generally speaking Element Hirarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) + +NOTE: Semicolon character is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/)! + +The following is the ABNF definition using the syntax in [RFC5234]. The path-abempty, query, and fragment components are defined in [RFC3986]. All DID URLs MUST conform to the DID URL Syntax ABNF Rules. DID methods can further restrict these rules: + +``` +did-url = did path-abempty [ "?" query ] [ "#" fragment ] +``` + ### Main elements The main elements of the Algorand DID based on the DID data model are: @@ -160,7 +179,7 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` -## Customized specifications and methods: +## Domestic specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! The ARC13 Algorand DID registry specification includes: From 3cd666219e0d66456bbfebe7b12067f0b10a27a0 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:13:58 +0300 Subject: [PATCH 047/116] Fix typo --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 35272e7f8..179203c80 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -97,7 +97,7 @@ A DID URL is a network location identifier useful for a specific resource used b - web - UUID - ADDR (in case of onchain dApp data) -- ASA (in case of composite or collection or generally speaking Element Hirarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) +- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) NOTE: Semicolon character is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/)! @@ -107,6 +107,7 @@ The following is the ABNF definition using the syntax in [RFC5234]. The path-abe did-url = did path-abempty [ "?" query ] [ "#" fragment ] ``` +ARC13 uses fragments to specify ### Main elements The main elements of the Algorand DID based on the DID data model are: From 051ca1a318c432a9fe4dfe9a81025bb5ade146f8 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:16:08 +0300 Subject: [PATCH 048/116] Update --- ARCs/arc-0013.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 179203c80..348567a70 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -99,9 +99,9 @@ A DID URL is a network location identifier useful for a specific resource used b - ADDR (in case of onchain dApp data) - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) -NOTE: Semicolon character is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/)! +NOTE: Semicolon character is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! -The following is the ABNF definition using the syntax in [RFC5234]. The path-abempty, query, and fragment components are defined in [RFC3986]. All DID URLs MUST conform to the DID URL Syntax ABNF Rules. DID methods can further restrict these rules: +The following is the ABNF definition using the syntax in [RFC5234]. The path-abempty, query, and fragment components are defined in [RFC3986]: ``` did-url = did path-abempty [ "?" query ] [ "#" fragment ] From 0a13ff4d4b5800c2fa5e7ccc98c28ec25da8b94b Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:16:35 +0300 Subject: [PATCH 049/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 348567a70..d6126d47e 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -99,7 +99,7 @@ A DID URL is a network location identifier useful for a specific resource used b - ADDR (in case of onchain dApp data) - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) -NOTE: Semicolon character is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! +NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! The following is the ABNF definition using the syntax in [RFC5234]. The path-abempty, query, and fragment components are defined in [RFC3986]: From 099969cc23bae335a7f8713904346d2ecbf592cd Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:17:16 +0300 Subject: [PATCH 050/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d6126d47e..3d4d6f3ec 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -89,7 +89,7 @@ algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! -dApp DID URL Syntax: +DID URL Syntax ABNF: A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: - IPFS From 7b5900971a7322be14e5c4866c82c643cebec0bd Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:27:02 +0300 Subject: [PATCH 051/116] Update --- ARCs/arc-0013.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 3d4d6f3ec..5288d57bb 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -99,15 +99,26 @@ A DID URL is a network location identifier useful for a specific resource used b - ADDR (in case of onchain dApp data) - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) + + NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! -The following is the ABNF definition using the syntax in [RFC5234]. The path-abempty, query, and fragment components are defined in [RFC3986]: + +The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: ``` did-url = did path-abempty [ "?" query ] [ "#" fragment ] ``` -ARC13 uses fragments to specify +ARC13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: +- NFT ARCs and Hierarchies +- APP ARCs +- URI Fragments +- Key fragments: + - AUTH (Rekeyed) +- VerificationMethods + - STATEPROOF + ### Main elements The main elements of the Algorand DID based on the DID data model are: From d363f5f0ad1b4b2efb0280ca0a726d33894b138a Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:29:17 +0300 Subject: [PATCH 052/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 5288d57bb..6a99a582d 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -199,7 +199,7 @@ The ARC13 Algorand DID registry specification includes: - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! -Including a `verificationMethod` like a stateproof in a DID document is a powerful way to leverage blockchain technology for enhancing the security and verifiability of digital identities. This approach is particularly suitable for blockchain-based DIDs, where the immutability and transparency of the ledger can be used to provide cryptographic proof of the DID document's validity. +Including a `verificationMethod` like a stateproof in a DID document is a powerful way to leverage blockchain technology for enhancing the security and verifiability of digital identities. This approach is particularly suitable for blockchain-based DIDs, where the immutability and transparency of the ledger can be used to provide cryptographic proof of the DID/VC/VP document's validity. 1. **Stateproof as a Verification Method**: - In the case of Algorand, a stateproof can serve as a cryptographic proof that a particular state (including transactions and, potentially, DID documents) was indeed part of the blockchain at a given point in time. From bde8f18d3d98aef224381c0ad0c806cfe0412690 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:36:16 +0300 Subject: [PATCH 053/116] Update --- ARCs/arc-0013.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6a99a582d..5eaddba46 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -43,7 +43,7 @@ ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Wo ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! -To implement DID naming , namespace, ABNF grammar and DID registry specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in this ARC's scope! +Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC13's scope! ARC13 proposes two category of identifiers: @@ -52,6 +52,14 @@ ARC13 proposes two category of identifiers: ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. +### DID Resolver + +### DID Registry +The ARC13 Algorand DID registry specification: + +- An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! +- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! + ### 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. @@ -191,14 +199,9 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` -## Domestic specifications and methods: +## New proposed specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! -The ARC13 Algorand DID registry specification includes: - -- An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! -- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! - Including a `verificationMethod` like a stateproof in a DID document is a powerful way to leverage blockchain technology for enhancing the security and verifiability of digital identities. This approach is particularly suitable for blockchain-based DIDs, where the immutability and transparency of the ledger can be used to provide cryptographic proof of the DID/VC/VP document's validity. 1. **Stateproof as a Verification Method**: From c59003f6ddf922af96def19982c10798a4db464a Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:39:57 +0300 Subject: [PATCH 054/116] Update --- ARCs/arc-0013.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 5eaddba46..b37390812 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -47,7 +47,7 @@ Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/res ARC13 proposes two category of identifiers: -- Elemental :Native element transactions and derived elements app, asa, acc (these DID are dynamically generated using ledger data and some applied methods and conventions)! Elemental DIDs do not need any registry and decentralized ledger acts as registry for elementals! +- Elemental :AVM element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses! Elemental DIDs do not need any registry and decentralized ledger! - Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a dynamic composed identifier registered as on-chain DIDs! Composed DIDs are in need of registry, lifecycle management and universal resolver decentralized instrumentation and infrastructure! ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. @@ -56,8 +56,9 @@ ARC13 also introduces higher level abstractions (composed identities and credent ### DID Registry The ARC13 Algorand DID registry specification: - -- An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! +- For local elements: + - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! + - - An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! ### General Format From 27f6e19437be048547046238cc1b00720f77114c Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:41:21 +0300 Subject: [PATCH 055/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index b37390812..b92b4fb2c 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -48,7 +48,7 @@ Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/res ARC13 proposes two category of identifiers: - Elemental :AVM element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses! Elemental DIDs do not need any registry and decentralized ledger! -- Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a dynamic composed identifier registered as on-chain DIDs! Composed DIDs are in need of registry, lifecycle management and universal resolver decentralized instrumentation and infrastructure! +- Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a composite identifier registered as a DID! Composite DIDs MUST have registry, lifecycle management and universal resolver with decentralized implementations! ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. From 3f58eb170b17f142bdf008cc095bdf47dac41ae0 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:50:44 +0300 Subject: [PATCH 056/116] Update --- ARCs/arc-0013.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index b92b4fb2c..17f69f3fa 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -33,6 +33,10 @@ Algorand technology specific features are intended to reflect into this ARC in f NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] + +This ARC uses interchangeably the terms "Account", "Account Address", "public key", and "PK" to indicate the on-chain address of a blockchain identity, and in particular of an Algorand account, while reserving the term "ADDR" as a method namespace for application addresses on AVM chains in general! + The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its unique features and existing ARCs in motion (not only finalized). This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. From fc32bf563bb0ef61de4c3622b87ba66ca3b3769d Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 16:53:33 +0300 Subject: [PATCH 057/116] Update --- ARCs/arc-0013.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 17f69f3fa..e3849d581 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -44,6 +44,7 @@ This integration ensures that DIDs on Algorand maintain global uniqueness, immut ARC13 has taken insights, inspiration and even some method approaches from foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized (architectural) approach! ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! +ARC13 complies to [ARC4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) and [ARC22](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0022.md) to make use of readonly interfaces added to ARC4! ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! From 3d12c2364bf4a3a23e8c075074e13abd85d331a9 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 17:10:19 +0300 Subject: [PATCH 058/116] Update --- ARCs/arc-0013.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e3849d581..604bb8e9e 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -11,7 +11,7 @@ created: 2023-12-18 ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model) , [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! +This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model), [DID Specification Registries](https://www.w3.org/TR/did-spec-registries/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! ARC13 is best implementable as a group, together with [ARC113](https://github.com/GoPlausible/ARCs/blob/ARC-0113/ARCs/arc-0113.md) and [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)! @@ -33,7 +33,7 @@ Algorand technology specific features are intended to reflect into this ARC in f NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] +All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. This ARC uses interchangeably the terms "Account", "Account Address", "public key", and "PK" to indicate the on-chain address of a blockchain identity, and in particular of an Algorand account, while reserving the term "ADDR" as a method namespace for application addresses on AVM chains in general! @@ -67,9 +67,9 @@ The ARC13 Algorand DID registry specification: - An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! ### 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 specified 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 specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is (FOR NOW) implemented using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" type and similars! + 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. @@ -244,7 +244,6 @@ As stateproofs are already integrated as an extension service to all Algorand DI - Client side stateproof verification using DID information to implement Algorand DID self verification - Add goal CLI to verification method services (up for debate) -- Add multibase formatting for publickey - Add resolution conventions - Add more detail DID formatting From 32ffbdc21f257c80bdae935900ca06c2d207fbe2 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 17:11:21 +0300 Subject: [PATCH 059/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 604bb8e9e..9a7cb7d80 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -33,7 +33,7 @@ Algorand technology specific features are intended to reflect into this ARC in f NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification -All authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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 implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. This ARC uses interchangeably the terms "Account", "Account Address", "public key", and "PK" to indicate the on-chain address of a blockchain identity, and in particular of an Algorand account, while reserving the term "ADDR" as a method namespace for application addresses on AVM chains in general! From 0da1f5f83d00c3029f38c104698afd8e86841a38 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 17:25:58 +0300 Subject: [PATCH 060/116] Update --- ARCs/arc-0013.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 9a7cb7d80..9cbaad40a 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -41,9 +41,10 @@ The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifier This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. -ARC13 has taken insights, inspiration and even some method approaches from foundation work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized (architectural) approach! +ARC13 has taken insights and inspiration from precious foundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! + ARC13 complies to [ARC4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) and [ARC22](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0022.md) to make use of readonly interfaces added to ARC4! ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! @@ -252,6 +253,7 @@ IMPORTANT TODO: - Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) ## Implementations: +All specified living standards that ARC13 comply to are expected to be concisely implemented and complete compliance and consideration of all [W3C DID implementation guidelines](https://w3c.github.io/did-imp-guide/)! ### Algorand DID Registry The DID registry is a must have when it comes to implement a global scaled DID compliant system! From 429a2472bd9a08f0bd206d0de42918e10af97698 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 17:34:08 +0300 Subject: [PATCH 061/116] Update --- ARCs/arc-0013.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 9cbaad40a..6a4a3bfb4 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -148,6 +148,15 @@ The main elements of the Algorand DID based on the DID data model are: - Internal elements: Elements under direct verification authority and tooling of AVM chains (TXN, ASA, APP, ACC) - Service elements: Elements out of verification authority and tooling of AMV chains (IPFS, URI, DOID,...) +![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) +DID General Architecture: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) + +According to DID general architecture version 1.0, ARC13 needs to provide standard coverage, infrastructure and also refrence implementation for: +- DID URI (Spec, API and from client library) +- DID Document (Spec, API and from client library) +- DID Registry (Spec & ABI) +- DID Resolver (Spec, ABI, API, UI and from client library) + ## Rationale ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public and decentralized way. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). @@ -173,9 +182,7 @@ Note: Algorand account addresses have no namespace and are considered root names Note: The UUID namespace MUST be isolated by network for security reasons! -## DID general architecture -![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) + ## DID lifecycle @@ -256,7 +263,7 @@ IMPORTANT TODO: All specified living standards that ARC13 comply to are expected to be concisely implemented and complete compliance and consideration of all [W3C DID implementation guidelines](https://w3c.github.io/did-imp-guide/)! ### Algorand DID Registry -The DID registry is a must have when it comes to implement a global scaled DID compliant system! +According to standard DID architecture The DID registry is a must have when it comes to implement a global scaled DID compliant system! GoPlausible has implemented the Algorand DID registry and resolution which already contains did resolution for all Algorand elements on TESTNET and MAINNET! ```mermaid From 4cd925da1dab56861dd05406fbd73f8ba55633bc Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 17:50:59 +0300 Subject: [PATCH 062/116] Update ARC document structure and arrangements --- ARCs/arc-0013.md | 151 ++++++++++++++++++++++++----------------------- 1 file changed, 77 insertions(+), 74 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6a4a3bfb4..71afed877 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -58,81 +58,12 @@ ARC13 proposes two category of identifiers: ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. -### DID Resolver - -### DID Registry -The ARC13 Algorand DID registry specification: -- For local elements: - - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - - -- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! - ### General Format -Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is (FOR NOW) implemented using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" type and similars! - - -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. - -### ABNF Grammar -The generic DID scheme is a URI scheme conformant with [RFC3986]. The ABNF definition can be found below, which uses the syntax in [RFC5234] and the corresponding definitions for ALPHA and DIGIT. All other rule names not defined in the ABNF below are defined in [RFC3986]. All DIDs MUST conform to the DID Syntax ABNF Rules. - -The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with the general DID ABNF grammar, with specific adaptations for Algorand's unique elements: - -``` -DID Syntax ABNF: -did = "did:" method-name ":" method-specific-id -method-name = 1*method-char -method-char = %x61-7A / DIGIT -method-specific-id = *( *idchar ":" ) 1*idchar -idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded -pct-encoded = "%" HEXDIG HEXDIG - -``` --------------- - -``` -The Algorand extended DID Syntax ABNF: -did = "did:" method-name ":" method-specific-id -method-name = "algo" ; Algorand method name -algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers -algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "addr" ; Algorand namespace identifiers -method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier -algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem - -``` -Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! - - -DID URL Syntax ABNF: - -A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: -- IPFS -- NFD/ANS -- web -- UUID -- ADDR (in case of onchain dApp data) -- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) - - - -NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! - +Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is (FOR NOW) implemented using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" type! -The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: +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]. -``` -did-url = did path-abempty [ "?" query ] [ "#" fragment ] -``` - -ARC13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: -- NFT ARCs and Hierarchies -- APP ARCs -- URI Fragments -- Key fragments: - - AUTH (Rekeyed) -- VerificationMethods - - STATEPROOF ### Main elements @@ -182,9 +113,6 @@ Note: Algorand account addresses have no namespace and are considered root names Note: The UUID namespace MUST be isolated by network for security reasons! - - - ## DID lifecycle A DID has different life stages depicted here and this stage status is reflected in value of DID "status" field! The status different values: @@ -213,6 +141,81 @@ flowchart LR revocation -->|DID is permanently deactivated| deletion ``` + +### DID URI ABNF Grammar +The generic DID scheme is a URI scheme conformant with [RFC3986]. The ABNF definition can be found below, which uses the syntax in [RFC5234] and the corresponding definitions for ALPHA and DIGIT. All other rule names not defined in the ABNF below are defined in [RFC3986]. All DIDs MUST conform to the DID Syntax ABNF Rules. + +The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with the general DID ABNF grammar, with specific adaptations for Algorand's unique elements: + +``` +DID Syntax ABNF: +did = "did:" method-name ":" method-specific-id +method-name = 1*method-char +method-char = %x61-7A / DIGIT +method-specific-id = *( *idchar ":" ) 1*idchar +idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded +pct-encoded = "%" HEXDIG HEXDIG + +``` +-------------- + +``` +The Algorand extended DID Syntax ABNF: +did = "did:" method-name ":" method-specific-id +method-name = "algo" ; Algorand method name +algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers +algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "addr" ; Algorand namespace identifiers +method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier +algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem + +``` +Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! + + +DID URL Syntax ABNF: + +A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: +- IPFS +- NFD/ANS +- web +- UUID +- ADDR (in case of onchain dApp data) +- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) + + + +NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! + + +The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: + +``` +did-url = did path-abempty [ "?" query ] [ "#" fragment ] +``` + +ARC13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: +- NFT ARCs and Hierarchies +- APP ARCs +- URI Fragments +- Key fragments: + - AUTH (Rekeyed) +- VerificationMethods + - STATEPROOF + + + +### DID Document + +### DID Resolver + +### DID Registry +The ARC13 Algorand DID registry specification: +- For local elements: + - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! + - +- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! + + ## New proposed specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! From 165bf606e1ea20c39a06c396126e59d6cf8e575f Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:00:25 +0300 Subject: [PATCH 063/116] Update --- ARCs/arc-0013.md | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 71afed877..2e53caac3 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -295,18 +295,38 @@ flowchart TB ### Algorand DID Resolver UI A fully working Resolver UI has been implemented and is available under GoPlausible MAINNET and TESTNET dApps (Algorand Universal DID Resolver) under standard endpoint (did-resolver/did:algo...) -Algorand DID Resolver MAINNET UI: [goplausible.xyz/did-resolver/...](https://goplausible.xyz/did-resolver/did:algo:nfd:emg110.algo) +Algorand DID Resolver TESTNET UI: [Algorand TESTNET DID Resolver](https://testnet.goplausible.xyz/did-resolver/) -Algorand DID Resolver TESTNET UI: [testnet.goplausible.xyz/did-resolver/...](https://testnet.goplausible.xyz/did-resolver/did:algo:nfd:emg110.algo) + Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! ### Algorand DID Resolver API -A fully working Resolver API has been implemented and is available under GoPlausible MAINNET and TESTNET APIs (Algorand Universal DID Resolver) under standard endpoint (/1.0/identifiers//did:algo...) -Algorand DID Resolver MAINNET API: [goplausible.xyz/api/1.0/identifiers//...](https://goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) -Algorand DID Resolver TESTNET API: [testnet.goplausible.xyz/api/1.0/identifiers//...](https://testnet.goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) + + +Algorand DID Resolver TESTNET API: +A fully working Resolver API has been implemented and is available for MAINNET and TESTNET (Algorand Universal DID Resolver) under standard endpoint (api/1.0/identifiers/did:algo...) + +- [ASA DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_asa:541958085) +- [APP DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_app:541957142) +- [TXN DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_txn:224FVUWR46D6ZCYO5RS6RPJYCKEPNRWLVSNV2F7HXHHEPDAMGIIQ) +- [ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) +- [APPLICATION ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_addr:JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) + +Algorand DID Constructor TESTNET API: +A fully working DID constructor API has been implemented and is available for MAINNET and TESTNET under standard endpoint (api/did/): + +- [APP DID](https://test.goplausible.xyz/api/did/541958085) +- [ASSET DID](https://test.goplausible.xyz/api/did/541957142) +- [Transaction DID](https://test.goplausible.xyz/api/did/JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) +- [Account DID](https://test.goplausible.xyz/api/did/LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) + + + + + ### Algorand DID Resolver Client library A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! From a0ae1cb059cb42ab8d7f1de62236ad56a8389ed3 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:01:05 +0300 Subject: [PATCH 064/116] Update --- ARCs/arc-0013.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 2e53caac3..88d5792dd 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -324,10 +324,6 @@ A fully working DID constructor API has been implemented and is available for MA - [Account DID](https://test.goplausible.xyz/api/did/LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) - - - - ### Algorand DID Resolver Client library A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! @@ -340,7 +336,7 @@ Then resolver instance has two methods: Algorand DID Resolver Client: [algo-did-resolver NPM Package](https://npm.org/algo-did-resolver) -### Algorand DID Resolver ABI +### Algorand DID Registry and Resolver ABI A fully working Resolver ABI has been implemented and is available under GoPlausible MAINNET and TESTNET main contracts and serve as Algorand Universal DID Registry: GoPlausible MAINNET contract: [946441472](https://algoexplorer.io/application/946441472) From f3b0f0d43c03ac784dd05bb19829f3411baa0c62 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:03:12 +0300 Subject: [PATCH 065/116] Update --- ARCs/arc-0013.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 88d5792dd..055a8d7d5 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -267,7 +267,7 @@ All specified living standards that ARC13 comply to are expected to be concisely ### Algorand DID Registry According to standard DID architecture The DID registry is a must have when it comes to implement a global scaled DID compliant system! -GoPlausible has implemented the Algorand DID registry and resolution which already contains did resolution for all Algorand elements on TESTNET and MAINNET! +ARC13 working group also provides an Algorand decentralized DID registry and resolution which already provides did resolution for all AVM elements on TESTNET! ```mermaid flowchart TB @@ -345,7 +345,6 @@ GoPlausible TESTNET contract: [119642157](https://testnet.algoexplorer.io/applic Through these two ABI methods: - ``` { From 6c198a7ee4ebe1e008b75d8572b320d4cdc1b97f Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:06:01 +0300 Subject: [PATCH 066/116] Update --- ARCs/arc-0013.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 055a8d7d5..14b37d83f 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -293,18 +293,18 @@ flowchart TB ``` ### Algorand DID Resolver UI -A fully working Resolver UI has been implemented and is available under GoPlausible MAINNET and TESTNET dApps (Algorand Universal DID Resolver) under standard endpoint (did-resolver/did:algo...) +A fully working Resolver UI has been implemented by ARC13 and is available for MAINNET and TESTNET (Algorand Universal DID Resolver UI) under standard path (did-resolver) Algorand DID Resolver TESTNET UI: [Algorand TESTNET DID Resolver](https://testnet.goplausible.xyz/did-resolver/) - +Algorand DID Resolver MAINNET UI: [Algorand DID Resolver](https://goplausible.xyz/did-resolver/) (Coming soon) Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! ### Algorand DID Resolver API - +Algorand DID Resolver MAINNET API: [goplausible.xyz/api/1.0/identifiers//...](https://goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) (Coming soon) Algorand DID Resolver TESTNET API: A fully working Resolver API has been implemented and is available for MAINNET and TESTNET (Algorand Universal DID Resolver) under standard endpoint (api/1.0/identifiers/did:algo...) @@ -337,11 +337,11 @@ Then resolver instance has two methods: Algorand DID Resolver Client: [algo-did-resolver NPM Package](https://npm.org/algo-did-resolver) ### Algorand DID Registry and Resolver ABI -A fully working Resolver ABI has been implemented and is available under GoPlausible MAINNET and TESTNET main contracts and serve as Algorand Universal DID Registry: +A fully working Resolver ABI has been implemented by ARC13 and is available for MAINNET and TESTNET through GoPlausible main contracts to serve as Algorand Universal DID Registry: -GoPlausible MAINNET contract: [946441472](https://algoexplorer.io/application/946441472) +DID registry MAINNET contract: [946441472](https://algoexplorer.io/application/946441472) (Coming soon) -GoPlausible TESTNET contract: [119642157](https://testnet.algoexplorer.io/application/119642157) +DID registry TESTNET contract: [119642157](https://testnet.algoexplorer.io/application/119642157) Through these two ABI methods: From 3d57be4196ef2ad958c14b981410698e39c02d10 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:12:50 +0300 Subject: [PATCH 067/116] Update --- ARCs/arc-0013.md | 5 ++++- assets/arc-0013/diagram-did-document-entries.svg | 3 +++ 2 files changed, 7 insertions(+), 1 deletion(-) create mode 100644 assets/arc-0013/diagram-did-document-entries.svg diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 14b37d83f..4e654fb30 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -183,7 +183,6 @@ A DID URL is a network location identifier useful for a specific resource used b - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) - NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! @@ -205,6 +204,10 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el ### DID Document +![](../assets/arc-0013/diagram-did-document-entries.svg) +![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) +DID General Architecture: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) + ### DID Resolver diff --git a/assets/arc-0013/diagram-did-document-entries.svg b/assets/arc-0013/diagram-did-document-entries.svg new file mode 100644 index 000000000..b9c114be1 --- /dev/null +++ b/assets/arc-0013/diagram-did-document-entries.svg @@ -0,0 +1,3 @@ + + +
Core Properties
Core Properties
id, alsoKnownAs, controller, authentication, verificationMethod, service, serviceEndpoint, …
id, alsoKnownAs, controller, authentication, verificatio...
Property Extensions
Property Extensions
ethereumAddress
ethereumAddress
Unregistered Property Extensions
Unregistered Property Extensions
foo
foo
Properties
Properties
Representation-specific entries
Representation-specific entr...
In DID Specification Registries
In DID Specification Registries
Entries in the DID Document map
Entries in the DID Document map
Representation-specific Entry Extensions
Representation-specific Entry Extensions
Core Representation-specific Entries
Core Representation-specific Entries
@context
@context
Unregistered Representation-specific Entry Extensions
Unregistered Representation-specific Entry Extensions
%YAML, xmlns
%YAML, xmlnsViewer does not support full SVG 1.1 \ No newline at end of file From 700bfb45c97079e40181626293c7cc81d4a3b9d5 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:13:24 +0300 Subject: [PATCH 068/116] Fix typo --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 4e654fb30..ff56297b5 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -206,7 +206,7 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el ### DID Document ![](../assets/arc-0013/diagram-did-document-entries.svg) ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -DID General Architecture: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) +DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) ### DID Resolver From 3acf0aff07882eee807cb47e13df258463cbfb51 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:14:01 +0300 Subject: [PATCH 069/116] Update --- ARCs/arc-0013.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index ff56297b5..c17ac811e 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -204,8 +204,7 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el ### DID Document -![](../assets/arc-0013/diagram-did-document-entries.svg) -![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) +![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) From b835c053e5716ba3a0866cb64fe314cd8a05c237 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:16:10 +0300 Subject: [PATCH 070/116] Update --- ARCs/arc-0013.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c17ac811e..c09842a27 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -208,6 +208,7 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) + ### DID Resolver ### DID Registry From 8ff006c7a4cf6c77506459fe0d4d7082ccf09daf Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:21:11 +0300 Subject: [PATCH 071/116] Update --- ARCs/arc-0013.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c09842a27..904cb05e6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -210,6 +210,7 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Resolver +ARC3 strickly follows and complys to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) ### DID Registry The ARC13 Algorand DID registry specification: From 29c6fa7ee9ddf79a40367ea913ad59a2d67f9e60 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:21:36 +0300 Subject: [PATCH 072/116] Update --- ARCs/arc-0013.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 904cb05e6..d09ba66a8 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -210,9 +210,11 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Resolver -ARC3 strickly follows and complys to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) + ### DID Registry +ARC3 strickly follows and complys to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) + The ARC13 Algorand DID registry specification: - For local elements: - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! From bfea732cd4d4d315aeb76c97751dff9863058ad0 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:22:06 +0300 Subject: [PATCH 073/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d09ba66a8..b0f019f5b 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -213,7 +213,7 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Registry -ARC3 strickly follows and complys to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) +ARC3 strictly follows and has full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) The ARC13 Algorand DID registry specification: - For local elements: From 6999190f98c8b224dd8590edffd762523bacce16 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:24:22 +0300 Subject: [PATCH 074/116] Update --- ARCs/arc-0013.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index b0f019f5b..c7366d578 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -217,9 +217,8 @@ ARC3 strictly follows and has full compliance to [DID Specification Registries]( The ARC13 Algorand DID registry specification: - For local elements: - - An active registry agent to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - - -- An active registry service to register and manage Algorand sub-namespace elements lifecycles through both API and an ABI! + - An active registry method, API, UI and client to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! +- An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way! ## New proposed specifications and methods: From c7b28f8c70db87747696255070baa62a43e9aba9 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:25:02 +0300 Subject: [PATCH 075/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c7366d578..9b9ebf133 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -215,7 +215,7 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Registry ARC3 strictly follows and has full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) -The ARC13 Algorand DID registry specification: +The ARC13 Algorand DID registry: - For local elements: - An active registry method, API, UI and client to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way! From 295b97488a6e8a349ac469b6feef660bfc92c052 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:27:23 +0300 Subject: [PATCH 076/116] Update --- ARCs/arc-0013.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 9b9ebf133..55659e404 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -210,10 +210,11 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Resolver +Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! ### DID Registry -ARC3 strictly follows and has full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/) +ARC3 DID registry implementation MUST strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/)! The ARC13 Algorand DID registry: - For local elements: From f53ca4bc587ecb9c0a29f264b34df83f835c03ad Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:29:46 +0300 Subject: [PATCH 077/116] Update --- ARCs/arc-0013.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 55659e404..3378dc5a1 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -210,11 +210,13 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 ### DID Resolver -Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! +Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! + +The ARC13 DID resolution implementations through ABI, API, Client library and Web UI SHOULD be accessible publicly! ### DID Registry -ARC3 DID registry implementation MUST strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/)! +ARC13 DID registry implementation MUST strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/)! The ARC13 Algorand DID registry: - For local elements: From ecec91476d7986db03da6be2ad6226116b861eaa Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:37:56 +0300 Subject: [PATCH 078/116] Update --- ARCs/arc-0013.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 3378dc5a1..de725e493 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,7 +60,9 @@ ARC13 also introduces higher level abstractions (composed identities and credent ### General Format -Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is (FOR NOW) implemented using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" type! +Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! + + 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]. From 5cc9ecfe5f6174fcdb7a4bd399e3d926ee7fc3d2 Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:40:30 +0300 Subject: [PATCH 079/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index de725e493..3e550dbe6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,7 +60,7 @@ ARC13 also introduces higher level abstractions (composed identities and credent ### General Format -Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" and uppercase SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! +Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! From 7048e231d28eba94c4fa4005419409ffabfde25f Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:40:57 +0300 Subject: [PATCH 080/116] Update --- ARCs/arc-0013.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 3e550dbe6..cb3d06961 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -62,8 +62,6 @@ ARC13 also introduces higher level abstractions (composed identities and credent Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! - - 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]. From 21c1269067d04c8a64047ff87b2450330ff98ecf Mon Sep 17 00:00:00 2001 From: MG Date: Mon, 25 Dec 2023 18:54:01 +0300 Subject: [PATCH 081/116] Update --- ARCs/arc-0013.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index cb3d06961..d87e85484 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -207,6 +207,18 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el ![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) +DID Document properties: +- id: A string that conforms to the rules in 3.1 DID Syntax. +- alsoKnownAs: A set of strings that conform to the rules of [RFC3986] for URIs. +- controller: A string or a set of strings that conform to the rules in 3.1 DID Syntax. +- verificationMethod: A set of Verification Method maps that conform to the rules in Verification Method properties. +- service: A set of Service Endpoint maps that conform to the rules in Service properties. +- Verification method extensions: + - authentication: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in 3.2 DID URL Syntax. + - assertionMethod: + - keyAgreement: + - capabilityInvocation: + - capabilityDelegation: ### DID Resolver From c38d326093c0efc326e492bfe1014d36ce19bce6 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 08:39:40 +0300 Subject: [PATCH 082/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d87e85484..81b40f14d 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -183,7 +183,7 @@ A DID URL is a network location identifier useful for a specific resource used b - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) -NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of that standard stating "DID methods can further restrict these rules" and use fragments to specify some fragment notations like NFT ARC favours (#ARC3, #ARC19,#ARC69...)! +NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of DID standard, stating "DID methods can further restrict these rules"! ARC3 uses fragments to specify some notations like NFT ARCs (#ARC3, #ARC19,#ARC69...)! The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: From 000b4adb150fdcfcd939f6d2301b94c7d0b9ade6 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:13:34 +0300 Subject: [PATCH 083/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 81b40f14d..81ae3159c 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -183,7 +183,7 @@ A DID URL is a network location identifier useful for a specific resource used b - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) -NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of DID standard, stating "DID methods can further restrict these rules"! ARC3 uses fragments to specify some notations like NFT ARCs (#ARC3, #ARC19,#ARC69...)! +NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of DID standard, stating "DID methods can further restrict these rules"! The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: From ce9f2fa2fd00e0aa712f469da131b3fe8164e2a2 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:14:16 +0300 Subject: [PATCH 084/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 81ae3159c..2f801fe0c 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -183,7 +183,7 @@ A DID URL is a network location identifier useful for a specific resource used b - ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) -NOTE: Semicolon character MUST NOT be used as it is reserved for future according to [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) also ARC13 make use of another quote of DID standard, stating "DID methods can further restrict these rules"! +NOTE: Semicolon character MUST NOT be used as it is reserved for future! The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: From c5daaca25997b58ec69a5282a611f2bea3d34aa9 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:21:36 +0300 Subject: [PATCH 085/116] Update DID doc properties --- ARCs/arc-0013.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 2f801fe0c..4a003addc 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -208,19 +208,29 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) DID Document properties: -- id: A string that conforms to the rules in 3.1 DID Syntax. +- id: A string that conforms to the rules in DID Syntax. - alsoKnownAs: A set of strings that conform to the rules of [RFC3986] for URIs. -- controller: A string or a set of strings that conform to the rules in 3.1 DID Syntax. +- controller: A string or a set of strings that conform to the rules in DID Syntax. - verificationMethod: A set of Verification Method maps that conform to the rules in Verification Method properties. + - id: A string that conforms to the rules in 3.2 DID URL Syntax. + - controller: A string that conforms to the rules in DID Syntax. + - type: A string + - publicKeyJwk: A map representing a JSON Web Key that conforms to [RFC7517]. See definition of publicKeyJwk for - additional constraints. + - publicKeyMultibase: A string that conforms to a [MULTIBASE] encoded public key. - service: A set of Service Endpoint maps that conform to the rules in Service properties. + - id: A string that conforms to the rules of [RFC3986] for URIs. + - type: A string or a set of strings. + - serviceEndpoint: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. - Verification method extensions: - - authentication: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in 3.2 DID URL Syntax. + - authentication: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - assertionMethod: - keyAgreement: - capabilityInvocation: - capabilityDelegation: + + ### DID Resolver Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! From 321f98543f41c733c9ecc54cb83a989f0006ffe5 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:46:46 +0300 Subject: [PATCH 086/116] Update --- ARCs/arc-0013.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 4a003addc..27f2751b8 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -221,22 +221,24 @@ DID Document properties: - id: A string that conforms to the rules of [RFC3986] for URIs. - type: A string or a set of strings. - serviceEndpoint: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. -- Verification method extensions: +- Verification method relationships: - authentication: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - assertionMethod: - keyAgreement: - capabilityInvocation: - capabilityDelegation: +ARC13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account: +``` +``` ### DID Resolver Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! The ARC13 DID resolution implementations through ABI, API, Client library and Web UI SHOULD be accessible publicly! - ### DID Registry ARC13 DID registry implementation MUST strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/)! From 706fe331169125d091f8f4167af938c3493f313f Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:56:44 +0300 Subject: [PATCH 087/116] Update --- ARCs/arc-0013.md | 71 +++++++++++++++++++++++++++++++++--------------- 1 file changed, 49 insertions(+), 22 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 27f2751b8..e27d1c4d6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -208,32 +208,59 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) DID Document properties: -- id: A string that conforms to the rules in DID Syntax. -- alsoKnownAs: A set of strings that conform to the rules of [RFC3986] for URIs. -- controller: A string or a set of strings that conform to the rules in DID Syntax. -- verificationMethod: A set of Verification Method maps that conform to the rules in Verification Method properties. - - id: A string that conforms to the rules in 3.2 DID URL Syntax. - - controller: A string that conforms to the rules in DID Syntax. - - type: A string - - publicKeyJwk: A map representing a JSON Web Key that conforms to [RFC7517]. See definition of publicKeyJwk for - additional constraints. - - publicKeyMultibase: A string that conforms to a [MULTIBASE] encoded public key. -- service: A set of Service Endpoint maps that conform to the rules in Service properties. - - id: A string that conforms to the rules of [RFC3986] for URIs. - - type: A string or a set of strings. - - serviceEndpoint: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. -- Verification method relationships: - - authentication: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - - assertionMethod: - - keyAgreement: - - capabilityInvocation: - - capabilityDelegation: - -ARC13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account: +- **id**: A string that conforms to the rules in DID Syntax. +- **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986] for URIs. +- **controller**: A string or a set of strings that conform to the rules in DID Syntax. +- **verificationMethod**: A set of Verification Method maps that conform to the rules in Verification Method properties. + - **id**: A string that conforms to the rules in 3.2 DID URL Syntax. + - **controller**: A string that conforms to the rules in DID Syntax. + - **type**: A string + - **publicKeyJwk**: A map representing a JSON Web Key that conforms to [RFC7517]. See definition of publicKeyJwk for - additional constraints. + - **publicKeyMultibase**: A string that conforms to a [MULTIBASE] encoded public key. +- **service**: A set of Service Endpoint maps that conform to the rules in Service properties. + - **id**: A string that conforms to the rules of [RFC3986] for URIs. + - **type**: A string or a set of strings. + - **serviceEndpoint**: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. + + +Verification method relationships: + - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. + - **assertionMethod**: + - **keyAgreement**: + - **capabilityInvocation**: + - **capabilityDelegation**: + +ARC13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account! + +ARC13 Verification methods in relationships between subjects can be either single purpose so they would be described in full within verification method, or they have multi-purpose (E.g. Authentication and encryption) just referenced by DID: ``` - +{ + "@context": [ + "https://www.w3.org/ns/did/v1", + "https://w3id.org/security/suites/ed25519-2020/v1" + ], + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + + "capabilityDelegation": [ + + "did:example:123456789abcdefghi#keys-1", + + + + { + "id": "did:example:123456789abcdefghi#keys-2", + "type": "Ed25519VerificationKey2020", + "controller": "did:example:123456789abcdefghi", + "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" + } + ], + +} ``` + + ### DID Resolver Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! From eb6a8f000850a4df9eb1f5230b166f788c4738e7 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:58:19 +0300 Subject: [PATCH 088/116] Update --- ARCs/arc-0013.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e27d1c4d6..e4d4ca7d1 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -225,10 +225,10 @@ DID Document properties: Verification method relationships: - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - - **assertionMethod**: - - **keyAgreement**: - - **capabilityInvocation**: - - **capabilityDelegation**: + - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL] + - **keyAgreement**: The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. + - **capabilityInvocation**: The capabilityInvocation verification relationship is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document. + - **capabilityDelegation**: The capabilityDelegation verification relationship is used to specify a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party, such as delegating the authority to access a specific HTTP API to a subordinate. ARC13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account! From 445c8a141a37d1dd6bad099a287cffda4c17445e Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:58:59 +0300 Subject: [PATCH 089/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e4d4ca7d1..baf00c8bb 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -225,7 +225,7 @@ DID Document properties: Verification method relationships: - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL] + - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/) - **keyAgreement**: The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. - **capabilityInvocation**: The capabilityInvocation verification relationship is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document. - **capabilityDelegation**: The capabilityDelegation verification relationship is used to specify a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party, such as delegating the authority to access a specific HTTP API to a subordinate. From 4aac865484e9d35753862aaa4fe623f51d7c337a Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 09:59:53 +0300 Subject: [PATCH 090/116] Update --- ARCs/arc-0013.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index baf00c8bb..027f91df2 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -675,10 +675,10 @@ Uniform Resource Identifier (URI) The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. - verifiable credential -A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL]. +A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). - verifiable data registry -A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification [VC-DATA-MODEL]. +A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). - verifiable timestamp A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. From 29fc079e32a0ca537f5a20e892e4a4298790a41e Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 10:05:48 +0300 Subject: [PATCH 091/116] Update --- ARCs/arc-0013.md | 107 +++++++++++++++++++++++++++++------------------ 1 file changed, 66 insertions(+), 41 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 027f91df2..57dc09b94 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -606,91 +606,116 @@ did:algo:ans:emg110.algo ``` ## Terminology: -- decentralized identifier (DID) -A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. +- decentralized identifier (DID): + + A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. -- decentralized identity management -Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. +- decentralized identity management: + + Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. -- DID controller -An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. +- DID controller: + + An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. -- DID delegate -An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. +- DID delegate: + + An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. -- DID document -A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. +- DID document: + + A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. -- DID fragment -The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. +- DID fragment: + + The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. -- DID method -A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. See 8. Methods. +- DID method: + + A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. -- DID path -The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. See Path. +- DID path: + +The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. -- DID query -The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. See Query. +- DID query: + +The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. -- DID resolution -The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. The inputs and outputs of this process are defined in 7.1 DID Resolution. +- DID resolution: + +The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. -- DID resolver -A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming -DID document as output. +- DID resolver: + +A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming DID document as output. -- DID scheme -The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in 3.1 DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. In a specific DID method scheme, the DID method name follows the first colon and terminates with the second colon, e.g., did:example: +- DID scheme: + +The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. -- DID subject +- DID subject: + The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. -- DID URL +- DID URL: + A DID plus any additional syntactic component that conforms to the definition in 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character). -- DID URL dereferencing +- DID URL dereferencing: + The process that takes as its input a DID URL and a set of input metadata, and returns a resource. This resource might be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document. The process uses DID resolution to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing process can then perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL. The inputs and outputs of this process are defined in 7.2 DID URL Dereferencing. -- DID URL dereferencer +- DID URL dereferencer: + A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document. -- public key description +- public key description: + A data object contained inside a DID document that contains all the metadata necessary to use a public key or a verification key. resource As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a DID subject identified by a DID. -- representation +- representation: + As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject. See 6. Representations. -- representation-specific entries +- representation-specific entries: + Entries in a DID document whose meaning is particular to a specific representation. Defined in 4. Data Model and 6. Representations. For example, @context in the JSON-LD representation is a representation-specific entry. -- services +- services: + Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services. -- service endpoint, node, idx +- service endpoint, node, idx: + A network address, such as an HTTP URL, at which services operate on behalf of a DID subject. Uniform Resource Identifier (URI) The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. -- verifiable credential +- verifiable credential: + A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). -- verifiable data registry +- verifiable data registry: A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). -- verifiable timestamp +- verifiable timestamp: + A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. -- verification method +- verification method: + A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. "Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof." -- verification relationship -An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is 5.3.1 Authentication. +- verification relationship: + +An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is Authentication. -- Universally Unique Identifier (UUID) +- Universally Unique Identifier (UUID): + A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable. ## Copyright From 1a8c6847979a5b955584e864b5b2807c7706f399 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 10:09:49 +0300 Subject: [PATCH 092/116] Update --- ARCs/arc-0013.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 57dc09b94..34107e424 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -242,16 +242,16 @@ ARC13 Verification methods in relationships between subjects can be either singl ], "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "capabilityDelegation": [ + "verificationMethod": [ - "did:example:123456789abcdefghi#keys-1", + "did:exaalgomple:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", { - "id": "did:example:123456789abcdefghi#keys-2", + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#arc52", "type": "Ed25519VerificationKey2020", - "controller": "did:example:123456789abcdefghi", + "controller": "did:algo:123456789abcdefghi", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], From 5a3f2c79180961962ded495df138f59d91c26770 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 10:46:02 +0300 Subject: [PATCH 093/116] Add multisig group controls --- ARCs/arc-0013.md | 17 +- .../figure-c.2-group-did-controllers.svg | 396 ++++++++++++++++++ 2 files changed, 406 insertions(+), 7 deletions(-) create mode 100644 assets/arc-0013/figure-c.2-group-did-controllers.svg diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 34107e424..7d94afe4a 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -207,7 +207,7 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el ![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) -DID Document properties: +#### DID Document properties: - **id**: A string that conforms to the rules in DID Syntax. - **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986] for URIs. - **controller**: A string or a set of strings that conform to the rules in DID Syntax. @@ -223,7 +223,7 @@ DID Document properties: - **serviceEndpoint**: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. -Verification method relationships: +#### Verification method relationships: - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/) - **keyAgreement**: The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. @@ -243,15 +243,14 @@ ARC13 Verification methods in relationships between subjects can be either singl "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", "verificationMethod": [ - + // A known DID for auth account of a rekeyed account "did:exaalgomple:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", - - - + + // A stand alone ARC52 DH derived symmetric key { "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#arc52", "type": "Ed25519VerificationKey2020", - "controller": "did:algo:123456789abcdefghi", + "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } ], @@ -259,6 +258,10 @@ ARC13 Verification methods in relationships between subjects can be either singl } ``` +#### Multisig DID modeling +Since DIDs support multi controller models in both independent and control group formations, multisigs SHOULD be modeled as control groups , controlling a single DID (multisig account): + +![](../assets/arc-0013/figure-c.2-group-did-controllers.svg) ### DID Resolver diff --git a/assets/arc-0013/figure-c.2-group-did-controllers.svg b/assets/arc-0013/figure-c.2-group-did-controllers.svg new file mode 100644 index 000000000..ffd023bd4 --- /dev/null +++ b/assets/arc-0013/figure-c.2-group-did-controllers.svg @@ -0,0 +1,396 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From bd0e3b6091f21fb1b1d12fc3067511242318dc8b Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 11:08:08 +0300 Subject: [PATCH 094/116] Update --- ARCs/arc-0013.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 7d94afe4a..c1fa39f8a 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -257,12 +257,51 @@ ARC13 Verification methods in relationships between subjects can be either singl } ``` +#### Context model +ARC13 makes use of 3 predefined contexts for DIDs: +- DID document context: "https://www.w3.org/ns/did/v1" +- DID Ed25519 security suite context: "https://w3id.org/security/suites/ed25519-2020/v1" +- DID security context: "https://w3id.org/security/v1" #### Multisig DID modeling Since DIDs support multi controller models in both independent and control group formations, multisigs SHOULD be modeled as control groups , controlling a single DID (multisig account): ![](../assets/arc-0013/figure-c.2-group-did-controllers.svg) +#### Rekeyed account DID modeling +Rekeyed accounts should have the auth account verifier in DID document used with "#auth" fragment in id: + +``` + +{ + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "@context": [ + "https://www.w3.org/ns/did/v1", + "https://w3id.org/security/suites/ed25519-2020/v1", + "https://w3id.org/security/v1" + ], + "verificationMethod": [ + { + "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#rekeyed", + "publicKeyMultibase": "BLP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "type": "Ed25519VerificationKey2020" + }, + { + "controller": "did:algo:JKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", + "publicKeyMultibase": "BJKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", + "type": "Ed25519VerificationKey2020" + } + + ], + "authentication": [ + "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth" + ], + + } + +``` ### DID Resolver Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! From d28c696169a23e5658ecb38b0559f413207601bb Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 11:09:34 +0300 Subject: [PATCH 095/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c1fa39f8a..96b33a08f 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -269,7 +269,7 @@ Since DIDs support multi controller models in both independent and control group ![](../assets/arc-0013/figure-c.2-group-did-controllers.svg) #### Rekeyed account DID modeling -Rekeyed accounts should have the auth account verifier in DID document used with "#auth" fragment in id: +Rekeyed accounts MUST contain both the rekeyed and auth account verifiers in DID document used with "#auth" and "rekeyed" fragments in id property field of Verification Method: ``` From 02388d36ab3d9fe52e4cd6fcf4b129e018422c48 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 11:49:58 +0300 Subject: [PATCH 096/116] Add PK question TODO --- ARCs/arc-0013.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 96b33a08f..70f3a26a4 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -62,6 +62,8 @@ ARC13 also introduces higher level abstractions (composed identities and credent Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! +TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! + 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]. @@ -316,6 +318,8 @@ The ARC13 Algorand DID registry: - An active registry method, API, UI and client to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way! +#### Decentralized registries + ## New proposed specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! From 55a329cd2c5d510583f309151f9bd0e36591b0a4 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 11:50:24 +0300 Subject: [PATCH 097/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 70f3a26a4..518df12da 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,7 +60,7 @@ ARC13 also introduces higher level abstractions (composed identities and credent ### General Format -Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! +Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC52! TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! From 75161c707973c0306bef84a168ce9144903fe7dc Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:04:17 +0300 Subject: [PATCH 098/116] Update --- ARCs/arc-0013.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 518df12da..e74d669df 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -60,11 +60,26 @@ ARC13 also introduces higher level abstractions (composed identities and credent ### General Format -Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC52! +- Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC52! TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! -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]. +- Under DID services, AVM API endpoints (Algod, Indexer, KMD) can be can OPTIONALLY use universal naming for ease of use and readability: + + ``` + did:algo:web:testnet_node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ + + did:algo:web:testnet_idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ + + ``` + The service endpoint for this OPTIONAL setting should be specified like: + + ``` + "serviceEndpoint": "https://testnet_node/" + "serviceEndpoint": "https://testnet_idx/" + ``` + when endpoints are used in universal descriptor format, there will be no need to specify the full URL which may be subject to change from user to user! ### Main elements @@ -573,7 +588,7 @@ did:algo:ans:emg110.algo did:algo:nfd:emg110.algo did:algo:ans:emg110.algo ``` -## Appendix B: DID document example with dummy data +## Appendix B: DID document example (dummy data) ```json { "@context": [ From e402456a5379e566468aafac9630ffaa30ad505a Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:06:30 +0300 Subject: [PATCH 099/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index e74d669df..6cc64da26 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -1,7 +1,7 @@ --- arc: 13 title: Decentralized identifiers (DIDs) -description: DID (Decentralized identifier) V 1.0 living standard URI format conventions for Algorand blockchain identifier elements. +description: DID (Decentralized identifier) V 1.0 living standard for Algorand blockchain. author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track From 7371b4140d2c47fb2c4c91c8eacbf9bb5c9e9845 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:07:38 +0300 Subject: [PATCH 100/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6cc64da26..6d7cf2091 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -41,7 +41,7 @@ The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifier This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. -ARC13 has taken insights and inspiration from precious foundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! +ARC13 has taken insights and inspiration from precious fundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! From 66bf41632ded3cb1c90082054845a36842f148a5 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:08:13 +0300 Subject: [PATCH 101/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6d7cf2091..a96793efd 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -1,7 +1,7 @@ --- arc: 13 title: Decentralized identifiers (DIDs) -description: DID (Decentralized identifier) V 1.0 living standard for Algorand blockchain. +description: DID (Decentralized identifier) Version 1.0 living standard for Algorand blockchain. author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital status: Draft type: Standards Track From d0db95cd7a44b85991540ba475a6a6a9af700828 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:13:48 +0300 Subject: [PATCH 102/116] Update order --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index a96793efd..b29d50bf3 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -2,7 +2,7 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) Version 1.0 living standard for Algorand blockchain. -author: MG (@emg110), @GoPlausible, @GoraNetwork, @VoiNetwork, @DaffiDigital +author: MG (@emg110), @VoiNetwork, @GoraNetwork, @DaffiDigital, @GoPlausible status: Draft type: Standards Track category: Interface, Identity Convention and URI Scheme From 96c9170025a9565d2dece336bb3f915dfef4ecdc Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:34:30 +0300 Subject: [PATCH 103/116] Update --- ARCs/arc-0013.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index b29d50bf3..283163420 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -30,6 +30,8 @@ Algorand technology specific features are intended to reflect into this ARC in f - Tech stack (available and in use) - Requirements +ARC13 as well as ARC113, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on verifiers and keys! + NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! ## Specification @@ -47,7 +49,6 @@ ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Wo ARC13 complies to [ARC4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) and [ARC22](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0022.md) to make use of readonly interfaces added to ARC4! -ARC13 heavily relies on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) work and output in order to provide integrated identity proofs through both derived keys and signed certificates! Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC13's scope! @@ -266,7 +267,7 @@ ARC13 Verification methods in relationships between subjects can be either singl // A stand alone ARC52 DH derived symmetric key { "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#arc52", - "type": "Ed25519VerificationKey2020", + "type": "RsaVerificationKey2018", "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } From 778dc455099cdfe05c9d1c20c1c42267bdc11b94 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 12:38:21 +0300 Subject: [PATCH 104/116] Update --- ARCs/arc-0013.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 283163420..c34f395b6 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -65,6 +65,8 @@ ARC13 also introduces higher level abstractions (composed identities and credent TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! +- The registration (Creating PRs) of "AlgorandAddress" as a verification method type as well as updating associated repositories for did:algo resolution is included in ARC13 task group mission! + - 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]. - Under DID services, AVM API endpoints (Algod, Indexer, KMD) can be can OPTIONALLY use universal naming for ease of use and readability: From 749810e92f4db5942ace10bb65429ee8ad926698 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 16:13:12 +0300 Subject: [PATCH 105/116] Add linkedData to general format --- ARCs/arc-0013.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index c34f395b6..6602a2f11 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -84,6 +84,17 @@ TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algoran ``` when endpoints are used in universal descriptor format, there will be no need to specify the full URL which may be subject to change from user to user! + // This section is non-normative. + +- Linked Data [LINKED-DATA](https://www.w3.org/DesignIssues/LinkedData.html) is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web. + +- JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC8259]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. Since JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries available today can be reused. In addition to all the features JSON provides, JSON-LD introduces: + - a universal identifier mechanism for JSON objects via the use of IRIs, + - a way to disambiguate keys shared among different JSON documents by mapping them to IRIs via a context, + - a mechanism in which a value in a JSON object may refer to a resource on a different site on the Web, + the ability to annotate strings with their language, + - a way to associate datatypes with values such as dates and times, + and a facility to express one or more directed graphs, such as a social network, in a single document. ### Main elements From 5037c2f8166de4e3a8805db7dfef49480a315483 Mon Sep 17 00:00:00 2001 From: MG Date: Tue, 26 Dec 2023 16:13:50 +0300 Subject: [PATCH 106/116] Fix typo --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 6602a2f11..ba73a79e2 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -113,7 +113,7 @@ The main elements of the Algorand DID based on the DID data model are: ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) DID General Architecture: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) -According to DID general architecture version 1.0, ARC13 needs to provide standard coverage, infrastructure and also refrence implementation for: +According to DID general architecture version 1.0, ARC13 needs to provide standard coverage, infrastructure and also reference implementation for: - DID URI (Spec, API and from client library) - DID Document (Spec, API and from client library) - DID Registry (Spec & ABI) From cd0c69afa0128affe099084c63f8ea7c9649d090 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 28 Dec 2023 08:30:18 +0300 Subject: [PATCH 107/116] Update --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index ba73a79e2..3c1d421ba 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -502,7 +502,7 @@ Through these two ABI methods: "returns": { "type": "string" }, - "desc": "Called publicly by an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value!" + "desc": "Called using registrar account on request + payment reception from an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value!" }, { From 92a7e710d5d04169eeb6374e25e9ebafd9ce9848 Mon Sep 17 00:00:00 2001 From: MG Date: Sat, 30 Dec 2023 14:51:08 +0300 Subject: [PATCH 108/116] Update --- ARCs/arc-0013.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 3c1d421ba..d7a4f67bf 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -34,6 +34,13 @@ ARC13 as well as ARC113, heavily depend and rely on [ARC52](https://arc.algorand NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! +## Important note +ARC13 has taken insights and inspiration from precious fundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! + +The approach AlgorandFoundation had included large storage needed for existing Algorand elements (billions of them are existing on MAINNET only) that would cause tens of thousands of dollars needed to make existing objects registered! [ARC13] reduces that cost to near zero as well as no need for any infrastructure or on-chain storage for existing Algorand elements! +[ARC13] proposes a dynamic method to generate deterministic DIDs for existing Algorand elements on both MAINNET and TESTNET! +Within [ARC13] specification only composite new elements are in need of registry and therefore occupying some storage space! + ## Specification All implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. @@ -43,8 +50,6 @@ The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifier This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. -ARC13 has taken insights and inspiration from precious fundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! - ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! ARC13 complies to [ARC4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) and [ARC22](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0022.md) to make use of readonly interfaces added to ARC4! From 52065a2cb053717caddd6b9cd9594c2dd54598c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane?= Date: Thu, 11 Jan 2024 12:02:15 +0100 Subject: [PATCH 109/116] fix linting --- ARCs/arc-0013.md | 457 +++++++++++++++++++++++------------------------ 1 file changed, 227 insertions(+), 230 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index d7a4f67bf..8e402ef73 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -1,27 +1,27 @@ --- arc: 13 title: Decentralized identifiers (DIDs) -description: DID (Decentralized identifier) Version 1.0 living standard for Algorand blockchain. -author: MG (@emg110), @VoiNetwork, @GoraNetwork, @DaffiDigital, @GoPlausible +description: DID (Decentralized identifier) Version 1.0 for Algorand blockchain. +author: MG (@emg110), VoiNetwork (@VoiNetwork), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital), GoPlausible (@GoPlausible) status: Draft type: Standards Track -category: Interface, Identity Convention and URI Scheme +category: Interface created: 2023-12-18 --- ## Abstract -This standard represents [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) , [W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022)](https://w3c.github.io/did-core/#bib-vc-data-model), [DID Specification Registries](https://www.w3.org/TR/did-spec-registries/) and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! +This standard represents Decentralized Identifiers (DIDs) v1.0 , W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022), DID Specification Registries and Decentralized Identifier Resolution (DID Resolution) v0.3 living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! -ARC13 is best implementable as a group, together with [ARC113](https://github.com/GoPlausible/ARCs/blob/ARC-0113/ARCs/arc-0113.md) and [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)! +ARC-13 is best implementable as a group, together with [ARC-113](./arc-0113.md) and [ARC-110](./arc-0110.md)! -ASA ARCs can be extended by ARC13 and also can be passively subject to it, including: +ASA ARCs can be extended by [ARC-13](./arc-0013.md) and also can be passively subject to it, including: -- [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) Algorand technology specific features are intended to reflect into this ARC in full: - Composability @@ -30,47 +30,47 @@ Algorand technology specific features are intended to reflect into this ARC in f - Tech stack (available and in use) - Requirements -ARC13 as well as ARC113, heavily depend and rely on [ARC52](https://arc.algorand.foundation/ARCs/arc-0052) line of work and reference implementation to proceed on verifiers and keys! +ARC-13 as well as ARC-113, heavily depend and rely on [ARC-52](./arc-0052.md) line of work and reference implementation to proceed on verifiers and keys! NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! -## Important note -ARC13 has taken insights and inspiration from precious fundamental work of [Algorand Foundation](https://github.com/algorandfoundation/did-algo) on algo-did, but took a slightly different and more generalized approach! +### Important note +ARC-13 has taken insights and inspiration from precious fundamental work of Algorand Foundation on algo-did, but took a slightly different and more generalized approach! -The approach AlgorandFoundation had included large storage needed for existing Algorand elements (billions of them are existing on MAINNET only) that would cause tens of thousands of dollars needed to make existing objects registered! [ARC13] reduces that cost to near zero as well as no need for any infrastructure or on-chain storage for existing Algorand elements! -[ARC13] proposes a dynamic method to generate deterministic DIDs for existing Algorand elements on both MAINNET and TESTNET! -Within [ARC13] specification only composite new elements are in need of registry and therefore occupying some storage space! +The approach AlgorandFoundation had included large storage needed for existing Algorand elements (billions of them are existing on MAINNET only) that would cause tens of thousands of dollars needed to make existing objects registered! [ARC-13] reduces that cost to near zero as well as no need for any infrastructure or on-chain storage for existing Algorand elements! +[ARC-13] proposes a dynamic method to generate deterministic DIDs for existing Algorand elements on both MAINNET and TESTNET! +Within [ARC-13] specification only composite new elements are in need of registry and therefore occupying some storage space! ## Specification -All implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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 implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. This ARC uses interchangeably the terms "Account", "Account Address", "public key", and "PK" to indicate the on-chain address of a blockchain identity, and in particular of an Algorand account, while reserving the term "ADDR" as a method namespace for application addresses on AVM chains in general! -The ARC13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its unique features and existing ARCs in motion (not only finalized). +The ARC-13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its unique features and existing ARCs in motion (not only finalized). This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. -ARC13 can extend [ARC26](https://arc.algorand.foundation/ARCs/arc-0026) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! +ARC-13 can extend [ARC-26](./arc-0026.md) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! -ARC13 complies to [ARC4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) and [ARC22](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0022.md) to make use of readonly interfaces added to ARC4! +ARC-13 complies to [ARC-4](./arc-0004.md) and [ARC-22](./arc-0022.md) to make use of readonly interfaces added to ARC-4! -Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC13's scope! +Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC-13's scope! -ARC13 proposes two category of identifiers: +ARC-13 proposes two category of identifiers: - Elemental :AVM element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses! Elemental DIDs do not need any registry and decentralized ledger! - Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a composite identifier registered as a DID! Composite DIDs MUST have registry, lifecycle management and universal resolver with decentralized implementations! -ARC13 also introduces higher level abstractions (composed identities and credentials) using ARC110 and also dismisses the need for using single root identities and identity static hierarchies. +ARC-13 also introduces higher level abstractions (composed identities and credentials) using ARC-110 and also dismisses the need for using single root identities and identity static hierarchies. ### General Format -- Algorand DID elements specified by this ARC follow the URI format in general as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The Public key part is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC52! +- Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC-52! -TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! +TODO: Question: should ARC-13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! -- The registration (Creating PRs) of "AlgorandAddress" as a verification method type as well as updating associated repositories for did:algo resolution is included in ARC13 task group mission! +- The registration (Creating PRs) of "AlgorandAddress" as a verification method type as well as updating associated repositories for did:algo resolution is included in ARC-13 task group mission! - 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]. - Under DID services, AVM API endpoints (Algod, Indexer, KMD) can be can OPTIONALLY use universal naming for ease of use and readability: @@ -91,7 +91,7 @@ TODO: Question: should ARC13 use the direct base32 (uppercase) format of Algoran // This section is non-normative. -- Linked Data [LINKED-DATA](https://www.w3.org/DesignIssues/LinkedData.html) is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web. +- Linked Data LINKED-DATA is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web. - JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC8259]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. Since JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries available today can be reused. In addition to all the features JSON provides, JSON-LD introduces: - a universal identifier mechanism for JSON objects via the use of IRIs, @@ -116,40 +116,16 @@ The main elements of the Algorand DID based on the DID data model are: - Service elements: Elements out of verification authority and tooling of AMV chains (IPFS, URI, DOID,...) ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -DID General Architecture: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) +DID General Architecture: Curtsey of W3C Decentralized Identifiers (DIDs) v1.0 -According to DID general architecture version 1.0, ARC13 needs to provide standard coverage, infrastructure and also reference implementation for: +According to DID general architecture version 1.0, ARC-13 needs to provide standard coverage, infrastructure and also reference implementation for: - DID URI (Spec, API and from client library) - DID Document (Spec, API and from client library) - DID Registry (Spec & ABI) - DID Resolver (Spec, ABI, API, UI and from client library) -## Rationale - -ARC13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public and decentralized way. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and [Enterprise sector to be general](https://www.w3.org/TR/did-use-cases/#didEnterpriseChallenges). - -The rationale on namespaces includes : -- Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! -For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and AVM chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for AVM elements e.g. accounts! - -UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! - -As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof on usability and extendability! - -NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! - -Note: Algorand account addresses have no namespace and are considered root namespace under :algo! - -## Security Considerations - -1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial but is out of this ARC scope and goes under Wallet providers concerns! -2. DID Document Integrity: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. -3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. - -Note: The UUID namespace MUST be isolated by network for security reasons! - -## DID lifecycle +### DID lifecycle A DID has different life stages depicted here and this stage status is reflected in value of DID "status" field! The status different values: - Non-Existing @@ -178,7 +154,7 @@ flowchart LR ``` -### DID URI ABNF Grammar +#### DID URI ABNF Grammar The generic DID scheme is a URI scheme conformant with [RFC3986]. The ABNF definition can be found below, which uses the syntax in [RFC5234] and the corresponding definitions for ALPHA and DIGIT. All other rule names not defined in the ABNF below are defined in [RFC3986]. All DIDs MUST conform to the DID Syntax ABNF Rules. The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with the general DID ABNF grammar, with specific adaptations for Algorand's unique elements: @@ -216,19 +192,19 @@ A DID URL is a network location identifier useful for a specific resource used b - web - UUID - ADDR (in case of onchain dApp data) -- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC110](https://github.com/GoPlausible/ARCs/blob/ARC-0110/ARCs/arc-0110.md)) +- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC-110](./arc-0110.md)) NOTE: Semicolon character MUST NOT be used as it is reserved for future! -The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The path-abempty, query, and fragment components are defined in [RFC3986]: +The following is the exact ABNF definition using the syntax in [RFC5234] and taken from Decentralized Identifiers (DIDs) v1.0. The path-abempty, query, and fragment components are defined in [RFC3986]: ``` did-url = did path-abempty [ "?" query ] [ "#" fragment ] ``` -ARC13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: +ARC-13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: - NFT ARCs and Hierarchies - APP ARCs - URI Fragments @@ -239,11 +215,11 @@ ARC13 uses fragments to specify as many sub categories and sub flavors on AVM el -### DID Document +#### DID Document ![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) -DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) +DID Document constituents: Curtsey of W3C https://www.w3.org/TR/did-core/ -#### DID Document properties: +##### DID Document properties: - **id**: A string that conforms to the rules in DID Syntax. - **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986] for URIs. - **controller**: A string or a set of strings that conform to the rules in DID Syntax. @@ -259,16 +235,16 @@ DID Document constituents: Curtsey of W3C [Decentralized Identifiers (DIDs) v1.0 - **serviceEndpoint**: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. -#### Verification method relationships: +##### Verification method relationships: - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/) + - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential VC-DATA-MODEL - **keyAgreement**: The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. - **capabilityInvocation**: The capabilityInvocation verification relationship is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document. - **capabilityDelegation**: The capabilityDelegation verification relationship is used to specify a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party, such as delegating the authority to access a specific HTTP API to a subordinate. -ARC13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account! +ARC-13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as WEB did of a known account! -ARC13 Verification methods in relationships between subjects can be either single purpose so they would be described in full within verification method, or they have multi-purpose (E.g. Authentication and encryption) just referenced by DID: +ARC-13 Verification methods in relationships between subjects can be either single purpose so they would be described in full within verification method, or they have multi-purpose (E.g. Authentication and encryption) just referenced by DID: ``` { @@ -293,18 +269,18 @@ ARC13 Verification methods in relationships between subjects can be either singl } ``` -#### Context model -ARC13 makes use of 3 predefined contexts for DIDs: +##### Context model +ARC-13 makes use of 3 predefined contexts for DIDs: - DID document context: "https://www.w3.org/ns/did/v1" - DID Ed25519 security suite context: "https://w3id.org/security/suites/ed25519-2020/v1" - DID security context: "https://w3id.org/security/v1" -#### Multisig DID modeling +##### Multisig DID modeling Since DIDs support multi controller models in both independent and control group formations, multisigs SHOULD be modeled as control groups , controlling a single DID (multisig account): ![](../assets/arc-0013/figure-c.2-group-did-controllers.svg) -#### Rekeyed account DID modeling +##### Rekeyed account DID modeling Rekeyed accounts MUST contain both the rekeyed and auth account verifiers in DID document used with "#auth" and "rekeyed" fragments in id property field of Verification Method: ``` @@ -339,23 +315,23 @@ Rekeyed accounts MUST contain both the rekeyed and auth account verifiers in DID ``` -### DID Resolver -Algorand universal DID resolver MUST strictly follow W3C [DID resolution](https://w3c-ccg.github.io/did-resolution/)! +#### DID Resolver +Algorand universal DID resolver MUST strictly follow W3C https://w3c-ccg.github.io/did-resolution/! -The ARC13 DID resolution implementations through ABI, API, Client library and Web UI SHOULD be accessible publicly! +The ARC-13 DID resolution implementations through ABI, API, Client library and Web UI SHOULD be accessible publicly! -### DID Registry -ARC13 DID registry implementation MUST strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-resolution/)! +#### DID Registry +ARC-13 DID registry implementation MUST strictly follow and show full compliance to DID Specification Registries! -The ARC13 Algorand DID registry: +The ARC-13 Algorand DID registry: - For local elements: - An active registry method, API, UI and client to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! - An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way! -#### Decentralized registries +##### Decentralized registries -## New proposed specifications and methods: +### New proposed specifications and methods: One major goal of Algorand blockchain for proof and information verification is to be able to perform them both offline and online in a self-sovereign decentralized way without any third party! Including a `verificationMethod` like a stateproof in a DID document is a powerful way to leverage blockchain technology for enhancing the security and verifiability of digital identities. This approach is particularly suitable for blockchain-based DIDs, where the immutability and transparency of the ledger can be used to provide cryptographic proof of the DID/VC/VP document's validity. @@ -388,25 +364,9 @@ Important considerations regarding transaction DIDs with offline and online self 4. **Use Case Specificity**: - This kind of implementation is particularly useful in blockchain-based environments where transactions are key elements of the system. The DID document effectively becomes a tool for transaction verification. - -## Future work and TODO: -As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods in all reference implementations, hence there are some further steps to make it complete coverage regarding DID lifecycle: - -- Client side stateproof verification using DID information to implement Algorand DID self verification -- Add goal CLI to verification method services (up for debate) -- Add resolution conventions -- Add more detail DID formatting - -IMPORTANT TODO: -- Integrating resolver endpoints in Algod and Indexer endpoints on Algorand so that resolver goes global -- Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) - -## Implementations: -All specified living standards that ARC13 comply to are expected to be concisely implemented and complete compliance and consideration of all [W3C DID implementation guidelines](https://w3c.github.io/did-imp-guide/)! - ### Algorand DID Registry According to standard DID architecture The DID registry is a must have when it comes to implement a global scaled DID compliant system! -ARC13 working group also provides an Algorand decentralized DID registry and resolution which already provides did resolution for all AVM elements on TESTNET! +ARC-13 working group also provides an Algorand decentralized DID registry and resolution which already provides did resolution for all AVM elements on TESTNET! ```mermaid flowchart TB @@ -431,37 +391,182 @@ flowchart TB ``` +### Terminology: + +- decentralized identifier (DID): + + A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. + +- decentralized identity management: + + Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. + +- DID controller: + + An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. + +- DID delegate: + + An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. + +- DID document: + + A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. + +- DID fragment: + + The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. + +- DID method: + + A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. + +- DID path: + +The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. + +- DID query: + +The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. + +- DID resolution: + +The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. + +- DID resolver: + +A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming DID document as output. + +- DID scheme: + +The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. + +- DID subject: + +The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. + +- DID URL: + +A DID plus any additional syntactic component that conforms to the definition in 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character). + +- DID URL dereferencing: + +The process that takes as its input a DID URL and a set of input metadata, and returns a resource. This resource might be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document. The process uses DID resolution to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing process can then perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL. The inputs and outputs of this process are defined in 7.2 DID URL Dereferencing. + +- DID URL dereferencer: + +A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document. + +- public key description: + +A data object contained inside a DID document that contains all the metadata necessary to use a public key or a verification key. +resource +As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a DID subject identified by a DID. + +- representation: + +As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject. See 6. Representations. + +- representation-specific entries: + +Entries in a DID document whose meaning is particular to a specific representation. Defined in 4. Data Model and 6. Representations. For example, @context in the JSON-LD representation is a representation-specific entry. + +- services: + +Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services. + +- service endpoint, node, idx: + +A network address, such as an HTTP URL, at which services operate on behalf of a DID subject. +Uniform Resource Identifier (URI) +The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. + +- verifiable credential: + +A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification VC-DATA-MODEL. + +- verifiable data registry: +A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification VC-DATA-MODEL. + +- verifiable timestamp: + +A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. + +- verification method: + +A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. +"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof." + +- verification relationship: + +An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is Authentication. + +- Universally Unique Identifier (UUID): + +A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable. + +### Future work and TODO: +As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods in all reference implementations, hence there are some further steps to make it complete coverage regarding DID lifecycle: + +- Client side stateproof verification using DID information to implement Algorand DID self verification +- Add goal CLI to verification method services (up for debate) +- Add resolution conventions +- Add more detail DID formatting + +IMPORTANT TODO: +- Integrating resolver endpoints in Algod and Indexer endpoints on Algorand so that resolver goes global +- Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) + +## Rationale + +ARC-13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public and decentralized way. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and Enterprise sector to be general. + +The rationale on namespaces includes : +- Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! +For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and AVM chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for AVM elements e.g. accounts! + + +UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! + +As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof on usability and extendability! + +NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! + +Note: Algorand account addresses have no namespace and are considered root namespace under :algo! + +## Reference Implementation +All specified living standards that ARC-13 comply to are expected to be concisely implemented and complete compliance and consideration of all W3C DID implementation guidelines! + ### Algorand DID Resolver UI -A fully working Resolver UI has been implemented by ARC13 and is available for MAINNET and TESTNET (Algorand Universal DID Resolver UI) under standard path (did-resolver) +A fully working Resolver UI has been implemented by ARC-13 and is available for MAINNET and TESTNET (Algorand Universal DID Resolver UI) under standard path (did-resolver) -Algorand DID Resolver TESTNET UI: [Algorand TESTNET DID Resolver](https://testnet.goplausible.xyz/did-resolver/) +Algorand DID Resolver TESTNET UI: Algorand TESTNET DID Resolver> -Algorand DID Resolver MAINNET UI: [Algorand DID Resolver](https://goplausible.xyz/did-resolver/) (Coming soon) +Algorand DID Resolver MAINNET UI: Algorand DID Resolver (Coming soon) Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! ### Algorand DID Resolver API -Algorand DID Resolver MAINNET API: [goplausible.xyz/api/1.0/identifiers//...](https://goplausible.xyz/api/1.0/identifiers//did:algo:nfd:emg110.algo) (Coming soon) +Algorand DID Resolver MAINNET API: goplausible.xyz/api/1.0/identifiers//... (Coming soon) Algorand DID Resolver TESTNET API: A fully working Resolver API has been implemented and is available for MAINNET and TESTNET (Algorand Universal DID Resolver) under standard endpoint (api/1.0/identifiers/did:algo...) -- [ASA DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_asa:541958085) -- [APP DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_app:541957142) -- [TXN DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_txn:224FVUWR46D6ZCYO5RS6RPJYCKEPNRWLVSNV2F7HXHHEPDAMGIIQ) -- [ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) -- [APPLICATION ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet_addr:JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) - +- ASA DID Resolver +- APP DID Resolver +- TXN DID Resolver +- ACCOUNT DID Resolver +- APPLICATION ACCOUNT DID Resolver + Algorand DID Constructor TESTNET API: A fully working DID constructor API has been implemented and is available for MAINNET and TESTNET under standard endpoint (api/did/): -- [APP DID](https://test.goplausible.xyz/api/did/541958085) -- [ASSET DID](https://test.goplausible.xyz/api/did/541957142) -- [Transaction DID](https://test.goplausible.xyz/api/did/JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) -- [Account DID](https://test.goplausible.xyz/api/did/LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) - +- APP DID +- ASSET DID +- Transaction DID +- Account DID ### Algorand DID Resolver Client library A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! @@ -473,14 +578,14 @@ Then resolver instance has two methods: - resolve(did: did) : This retrieves the DID document for given - did_uri(id: string): This method creates a DID URI from Algorand element ID (TXN, ASA, APP) -Algorand DID Resolver Client: [algo-did-resolver NPM Package](https://npm.org/algo-did-resolver) +Algorand DID Resolver Client: algo-did-resolver NPM Package ### Algorand DID Registry and Resolver ABI -A fully working Resolver ABI has been implemented by ARC13 and is available for MAINNET and TESTNET through GoPlausible main contracts to serve as Algorand Universal DID Registry: +A fully working Resolver ABI has been implemented by ARC-13 and is available for MAINNET and TESTNET through GoPlausible main contracts to serve as Algorand Universal DID Registry: -DID registry MAINNET contract: [946441472](https://algoexplorer.io/application/946441472) (Coming soon) +DID registry MAINNET contract: 946441472 (Coming soon) -DID registry TESTNET contract: [119642157](https://testnet.algoexplorer.io/application/119642157) +DID registry TESTNET contract: 119642157 Through these two ABI methods: @@ -563,9 +668,7 @@ Through these two ABI methods: ``` - - -## Appendix A: DID examples for all namespaces +### Appendix A: DID examples for all namespaces Examples of DIDs for each Algorand element type for both testnet and mainnet instance - No namespace: @@ -607,7 +710,7 @@ did:algo:ans:emg110.algo did:algo:nfd:emg110.algo did:algo:ans:emg110.algo ``` -## Appendix B: DID document example (dummy data) +### Appendix B: DID document example (dummy data) ```json { "@context": [ @@ -682,124 +785,18 @@ did:algo:ans:emg110.algo "retrieved": "2023-05-15T17:39:30Z" } } - ``` -## Terminology: - -- decentralized identifier (DID): - - A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. - -- decentralized identity management: - - Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. - -- DID controller: - - An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. - -- DID delegate: - - An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. - -- DID document: - - A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. - -- DID fragment: - - The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. - -- DID method: - - A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. - -- DID path: - -The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. - -- DID query: - -The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. - -- DID resolution: - -The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. - -- DID resolver: - -A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming DID document as output. -- DID scheme: - -The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. - -- DID subject: - -The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. - -- DID URL: - -A DID plus any additional syntactic component that conforms to the definition in 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character). - -- DID URL dereferencing: - -The process that takes as its input a DID URL and a set of input metadata, and returns a resource. This resource might be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document. The process uses DID resolution to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing process can then perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL. The inputs and outputs of this process are defined in 7.2 DID URL Dereferencing. - -- DID URL dereferencer: - -A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document. - -- public key description: - -A data object contained inside a DID document that contains all the metadata necessary to use a public key or a verification key. -resource -As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a DID subject identified by a DID. - -- representation: - -As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject. See 6. Representations. - -- representation-specific entries: - -Entries in a DID document whose meaning is particular to a specific representation. Defined in 4. Data Model and 6. Representations. For example, @context in the JSON-LD representation is a representation-specific entry. - -- services: - -Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services. - -- service endpoint, node, idx: - -A network address, such as an HTTP URL, at which services operate on behalf of a DID subject. -Uniform Resource Identifier (URI) -The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. - -- verifiable credential: - -A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). - -- verifiable data registry: -A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification [VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/). - -- verifiable timestamp: - -A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. - -- verification method: - -A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. -"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof." +## Security Considerations -- verification relationship: - -An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is Authentication. +1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial but is out of this ARC scope and goes under Wallet providers concerns! +2. DID Document Integrity: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. +3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. -- Universally Unique Identifier (UUID): - -A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable. +Note: The UUID namespace MUST be isolated by network for security reasons! ## 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/)! \ No newline at end of file +Copyright and related rights waived via CCO. From e3a3b17cd1c7dac119014a152fd9a4a4a60d2671 Mon Sep 17 00:00:00 2001 From: MG Date: Sun, 18 Feb 2024 18:41:40 +0300 Subject: [PATCH 110/116] Making ready for Beta --- ARCs/arc-0013.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 8e402ef73..2820c6051 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -2,7 +2,7 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) Version 1.0 for Algorand blockchain. -author: MG (@emg110), VoiNetwork (@VoiNetwork), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital), GoPlausible (@GoPlausible) +author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital), VoiNetwork (@VoiNetwork) status: Draft type: Standards Track category: Interface @@ -30,9 +30,9 @@ Algorand technology specific features are intended to reflect into this ARC in f - Tech stack (available and in use) - Requirements -ARC-13 as well as ARC-113, heavily depend and rely on [ARC-52](./arc-0052.md) line of work and reference implementation to proceed on verifiers and keys! +ARC 13 is completely self sufficient and works for all Algorand, external resources and ecosystem, how ever, in future it would be best to extend using [ARC-52](./arc-0052.md) line of work and reference implementation could mature to living standard so that to proceed on verifiers and keys from curves other that ed25519 and also derived keys could options. -NOTE: THIS IS DRAFT! WORK IN PROGRESS! ALL HELP WELCOME! +NOTE: THIS IS IN BETA! WORK IN PROGRESS! ALL REVIEWS WELCOME! ### Important note ARC-13 has taken insights and inspiration from precious fundamental work of Algorand Foundation on algo-did, but took a slightly different and more generalized approach! @@ -66,7 +66,7 @@ ARC-13 also introduces higher level abstractions (composed identities and creden ### General Format -- Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk" with use of ARC-52! +- Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! TODO: Question: should ARC-13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! From 09e2a1119b3c48e7d4ce2c70e275f9eca5f08f68 Mon Sep 17 00:00:00 2001 From: MG Date: Sun, 18 Feb 2024 19:50:58 +0300 Subject: [PATCH 111/116] Update content --- ARCs/arc-0013.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 2820c6051..19a0ee1d7 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -64,6 +64,10 @@ ARC-13 proposes two category of identifiers: ARC-13 also introduces higher level abstractions (composed identities and credentials) using ARC-110 and also dismisses the need for using single root identities and identity static hierarchies. +ARC-13 implements the storage of DID documents and their resolution using a hybrid approach with Algorand blockchain box storage and IPFS together. Storage implementation MUST use a CID based decentralized storage (IPFS, CRUST,etc) for DID Documents above 4kb (the amount than can be transmitted with one TXN on Algorand) or Algorand box storage for DID Documents below 4kb. + +ARC-13 implementation MUST store either the DID resolution body JSON with CID as "didDocument" key, or simply a box with DID as key and CID as value! Either is accepted under ARC13! + ### General Format - Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! @@ -510,12 +514,9 @@ As stateproofs are already integrated as an extension service to all Algorand DI - Client side stateproof verification using DID information to implement Algorand DID self verification - Add goal CLI to verification method services (up for debate) -- Add resolution conventions -- Add more detail DID formatting +- Add more resolution conventions +- Add more detail DID formatting for more extensions -IMPORTANT TODO: -- Integrating resolver endpoints in Algod and Indexer endpoints on Algorand so that resolver goes global -- Integrating into AlgoKIT so that custom elements can be issued with DIDs (e.g users, physical assets, graphic elements,...) ## Rationale From a381408d5a3f3d061b593a8b32cae0818aed1423 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 20 Sep 2024 08:04:59 +0300 Subject: [PATCH 112/116] Update arc-0013.md --- ARCs/arc-0013.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 19a0ee1d7..151ce684f 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -2,7 +2,7 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) Version 1.0 for Algorand blockchain. -author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital), VoiNetwork (@VoiNetwork) +author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) status: Draft type: Standards Track category: Interface From b03039b8b55b9c5f2175766306e179a0e77ceb5d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 7 Nov 2024 15:14:33 +0300 Subject: [PATCH 113/116] Update: Upgrade and simplification as well as including support for AidTech method --- ARCs/arc-0013.md | 340 ++++++++++++----------------------------------- 1 file changed, 87 insertions(+), 253 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 151ce684f..45be3e64c 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -3,93 +3,67 @@ arc: 13 title: Decentralized identifiers (DIDs) description: DID (Decentralized identifier) Version 1.0 for Algorand blockchain. author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) -status: Draft +status: Review type: Standards Track category: Interface +sub-category: General created: 2023-12-18 +extended-by: 113, 110 --- ## Abstract -This standard represents Decentralized Identifiers (DIDs) v1.0 , W3C Decentralized Identifiers Data Model Version 1.0 (19 July 2022), DID Specification Registries and Decentralized Identifier Resolution (DID Resolution) v0.3 living standards requirements and conventions using Algorand blockchain elements, naming conventions and methods! +This ARC presents an implementation specification for Decentralized Identifiers (DIDs) v1.0, DID Specification Registries and Decentralized Identifier Resolution (DID Resolution) v0.3 W3C standards, addressing requirements and conventions to implement and use Decentralized Identifiers on Algorand blockchain for internal elements, labeling and external resources & elements in need of on-chain identification! -ARC-13 is best implementable as a group, together with [ARC-113](./arc-0113.md) and [ARC-110](./arc-0110.md)! +[ARC-113](./arc-0113.md) extends this ARC to implement W3C Verifiable Credentials! ASA ARCs can be extended by [ARC-13](./arc-0013.md) and also can be passively subject to it, including: - [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) -Algorand technology specific features are intended to reflect into this ARC in full: -- Composability -- Elements and namespace conventions -- Methods and operations -- Tech stack (available and in use) -- Requirements - -ARC 13 is completely self sufficient and works for all Algorand, external resources and ecosystem, how ever, in future it would be best to extend using [ARC-52](./arc-0052.md) line of work and reference implementation could mature to living standard so that to proceed on verifiers and keys from curves other that ed25519 and also derived keys could options. - -NOTE: THIS IS IN BETA! WORK IN PROGRESS! ALL REVIEWS WELCOME! - -### Important note -ARC-13 has taken insights and inspiration from precious fundamental work of Algorand Foundation on algo-did, but took a slightly different and more generalized approach! - -The approach AlgorandFoundation had included large storage needed for existing Algorand elements (billions of them are existing on MAINNET only) that would cause tens of thousands of dollars needed to make existing objects registered! [ARC-13] reduces that cost to near zero as well as no need for any infrastructure or on-chain storage for existing Algorand elements! -[ARC-13] proposes a dynamic method to generate deterministic DIDs for existing Algorand elements on both MAINNET and TESTNET! -Within [ARC-13] specification only composite new elements are in need of registry and therefore occupying some storage space! +Algorand technology elements specifications and requirements are intended to be specified in this ARC to be identified using DIDs and DID documents. ## Specification All implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. -This ARC uses interchangeably the terms "Account", "Account Address", "public key", and "PK" to indicate the on-chain address of a blockchain identity, and in particular of an Algorand account, while reserving the term "ADDR" as a method namespace for application addresses on AVM chains in general! - -The ARC-13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its unique features and existing ARCs in motion (not only finalized). +This ARC uses the term "account" to indicate a private key based unique externally owned account as an Algorand blockchain identity, while reserving the term "addr" as a method namespace for smart contract application escrow addresses on Algorand! -This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents, which are essential for verifiable digital identity and decentralized authentication. +The ARC-13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its specifications and existing ARCs. -ARC-13 can extend [ARC-26](./arc-0026.md) (TODO Work) for it to support and include DIDs both in URL scheme and resolution conventions! - -ARC-13 complies to [ARC-4](./arc-0004.md) and [ARC-22](./arc-0022.md) to make use of readonly interfaces added to ARC-4! +This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents in a verifiable way, which is essential for verifiable digital identity. +ARC-13 complies to [ARC-4](./arc-0004.md) and [ARC-22](./arc-0022.md) for readonly DID interfaces. Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC-13's scope! ARC-13 proposes two category of identifiers: -- Elemental :AVM element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses! Elemental DIDs do not need any registry and decentralized ledger! -- Composed : A composition of identifiers (in different structures DID, VC, VP, OC, OB) under a composite identifier registered as a DID! Composite DIDs MUST have registry, lifecycle management and universal resolver with decentralized implementations! - -ARC-13 also introduces higher level abstractions (composed identities and credentials) using ARC-110 and also dismisses the need for using single root identities and identity static hierarchies. +- Elemental :Algorand element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses and public keys! Elemental DIDs do not need any registry and decentralized ledger and DID document information is realized from on-chain data. +- Composed : uses UUIDs to register a unique identifier for an Algorand DID used for an external entity! Composed DIDs MUST have registry, lifecycle management and universal resolver implementations or their own! -ARC-13 implements the storage of DID documents and their resolution using a hybrid approach with Algorand blockchain box storage and IPFS together. Storage implementation MUST use a CID based decentralized storage (IPFS, CRUST,etc) for DID Documents above 4kb (the amount than can be transmitted with one TXN on Algorand) or Algorand box storage for DID Documents below 4kb. +ARC-13 implements supports both on-chain (**MUST** use box storage) and off-chain (**MUST** use CID Version 1) based decentralized storage systems like IPFS, CrustNetwork, etc. -ARC-13 implementation MUST store either the DID resolution body JSON with CID as "didDocument" key, or simply a box with DID as key and CID as value! Either is accepted under ARC13! +ARC-13 implementation **MUST** used box storage to store either byte value of the DID document JSON, or CID Version 1 of DID document JSON as value, with DID identifier as key! Either is accepted under ARC13 but it is **RECOMMENDED** that DID documents under 4 Kb store as bytes onchain and for those above 4 Kb , a CID V1 compliant storage be used. ### General Format - Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! -TODO: Question: should ARC-13 use the direct base32 (uppercase) format of Algorand public key byte array or current use of public address suffices? The current proposed direct address usage is given the fact that using any language and without any specific Algorand tech stack, addresses can be processed to/from (by removing 4 bytes of checksum from end) public keys! - -- The registration (Creating PRs) of "AlgorandAddress" as a verification method type as well as updating associated repositories for did:algo resolution is included in ARC-13 task group mission! - - 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]. -- Under DID services, AVM API endpoints (Algod, Indexer, KMD) can be can OPTIONALLY use universal naming for ease of use and readability: +- Under DID services, Algorand API endpoints can be can OPTIONALLY use universal naming (Algod, Idx, Kmd) for ease of use and readability: ``` - did:algo:web:testnet_node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ + did:algo:web:testnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ - did:algo:web:testnet_idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ + did:algo:web:testnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ ``` The service endpoint for this OPTIONAL setting should be specified like: ``` - "serviceEndpoint": "https://testnet_node/" - "serviceEndpoint": "https://testnet_idx/" + "serviceEndpoint": "https://testnet:node/" + "serviceEndpoint": "https://testnet:idx/" ``` when endpoints are used in universal descriptor format, there will be no need to specify the full URL which may be subject to change from user to user! @@ -110,19 +84,19 @@ TODO: Question: should ARC-13 use the direct base32 (uppercase) format of Algora The main elements of the Algorand DID based on the DID data model are: - DID Scheme: did:algo: The unique scheme for Algorand DIDs. -- Element: An AVM or complementary service element as a subject for DID -- Network Identifier: testnet_ or mainnet_ Specifies the Algorand network (testnet or mainnet). +- Element: An Algorand unique element entity as a subject for DID +- Network Identifier: testnet or mainnet Specifies the Algorand network (testnet or mainnet). - Namespace: Identifies the type of Algorand element the DID represents (e.g., asa, txn, app). - Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). -- Local elements: AVM Elements with locally Unique Identifiers like assets and applications! -- Global elements: AVM Elements with global Unique Identifiers like Transactions, account addresses, UUIDs, IPFS CIDs! -- Internal elements: Elements under direct verification authority and tooling of AVM chains (TXN, ASA, APP, ACC) -- Service elements: Elements out of verification authority and tooling of AMV chains (IPFS, URI, DOID,...) +- Local elements: Algorand Elements with locally Unique Identifiers like assets and applications! +- Global elements: Algorand Elements with global Unique Identifiers like Transactions, UUIDs and accounts. +- Internal elements: Elements with direct verification and proofs on Algorand (TXN, ASA, APP, ACCOUNT and ADDR) +- Service elements: Elements out of Algorand chains (UUID) ![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) DID General Architecture: Curtsey of W3C Decentralized Identifiers (DIDs) v1.0 -According to DID general architecture version 1.0, ARC-13 needs to provide standard coverage, infrastructure and also reference implementation for: +According to DID general architecture version 1.0, ARC-13 provides standard coverage, specification and also reference implementation for: - DID URI (Spec, API and from client library) - DID Document (Spec, API and from client library) - DID Registry (Spec & ABI) @@ -131,13 +105,13 @@ According to DID general architecture version 1.0, ARC-13 needs to provide stand ### DID lifecycle -A DID has different life stages depicted here and this stage status is reflected in value of DID "status" field! The status different values: -- Non-Existing +Different DID life stages depicted here. Stage status is stored in value of DID "status" field! The status different values: +- NA: Not Available - 0: OK - 1: FLAG:SUSPEND -- 2: FLAG:REVOKE +- 2: FLAG:REVOKED -Note: There is no deletion in real practice for DIDs on blockchain, however deleting from registry and non-existing box storage record for that DID is taken as deletion definition for DID lifecycle on Algorand blockchain! +Note: There is no deletion in real practice for DIDs on blockchain, however deleting from registry and not available box storage record for that DID works like deletion for DID lifecycle on Algorand blockchain but the issuance and lifetime records and transactions and verifications will live forever on chain, and accessible if looked for! ```mermaid @@ -166,8 +140,8 @@ The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with ``` DID Syntax ABNF: did = "did:" method-name ":" method-specific-id -method-name = 1*method-char -method-char = %x61-7A / DIGIT +method-name = 1*methodchar +methodchar = %x61-7A / DIGIT ; 'a'-'z' and digits method-specific-id = *( *idchar ":" ) 1*idchar idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded pct-encoded = "%" HEXDIG HEXDIG @@ -180,26 +154,26 @@ The Algorand extended DID Syntax ABNF: did = "did:" method-name ":" method-specific-id method-name = "algo" ; Algorand method name algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers -algorand-namespace = "asa" / "txn" / "app" / "uuid" / "ans" / "nfd" / "ipfs" / "web" / "node" / "idx" / "addr" ; Algorand namespace identifiers -method-specific-id = algorand-network "_" algorand-namespace ":" algorand-identifier -algorand-identifier = 1*idchar ; Unique identifier within the Algorand ecosystem +algorand-namespace = "asa" / "txn" / "app" / "uuid" / "nfd" / "addr" ; Algorand namespace identifiers +method-specific-id = algorand-network ":" algorand-namespace ":" algorand-identifier +algorand-identifier = 1*idchar ; Unique identifier **MUST BE** unique in the Algorand ecosystem. ``` -Note : "addr" should be used with network element as it represents Algorand application address and not key based accounts! Algorand accounts are considered root Algorand DID subjects therefore they stand after "algo:" method! +If either "addr", "asa", "app" or "txn" namespaces are used it **MUST BE** used with algorand-network since these are network dependant identifiers, hence **MUST** be used with network identifier! DID URL Syntax ABNF: A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: -- IPFS -- NFD/ANS -- web -- UUID -- ADDR (in case of onchain dApp data) -- ASA (in case of composite or collection or generally speaking Element Hierarchy [ARC-110](./arc-0110.md)) +- NFD (NFDomains Algorand name service unique names) +- APP (Application Identifiers) +- UUID (V4) +- ACCOUNT (EOA) +- ADDR (Application escrow address) +- ASA (Asset Identifiers) -NOTE: Semicolon character MUST NOT be used as it is reserved for future! +NOTE: Semicolon character MUST NOT be used! The following is the exact ABNF definition using the syntax in [RFC5234] and taken from Decentralized Identifiers (DIDs) v1.0. The path-abempty, query, and fragment components are defined in [RFC3986]: @@ -208,22 +182,23 @@ The following is the exact ABNF definition using the syntax in [RFC5234] and tak did-url = did path-abempty [ "?" query ] [ "#" fragment ] ``` -ARC-13 uses fragments to specify as many sub categories and sub flavors on AVM elements as possible, including but not limited to: +ARC-13 fragments are used to extend DID URL by parametric or path routes. The following fragments are allowed under ARC-13: - NFT ARCs and Hierarchies - APP ARCs - URI Fragments - Key fragments: - AUTH (Rekeyed) + - HD Wallets - VerificationMethods - - STATEPROOF + - ZK (Zero Knowledge) -#### DID Document +#### DID Document specifications ![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) DID Document constituents: Curtsey of W3C https://www.w3.org/TR/did-core/ -##### DID Document properties: +##### DID Document properties specifications: - **id**: A string that conforms to the rules in DID Syntax. - **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986] for URIs. - **controller**: A string or a set of strings that conform to the rules in DID Syntax. @@ -246,7 +221,7 @@ DID Document constituents: Curtsey of W3C |Resolves to| did_doc did_doc -->|Describes| did_subject did_doc -->|Controlled by| did_controller @@ -395,127 +351,8 @@ flowchart TB ``` -### Terminology: - -- decentralized identifier (DID): - - A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DID method specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or some other form of decentralized network. - -- decentralized identity management: - - Identity management that is based on the use of decentralized identifiers. Decentralized identity management extends authority for identifier generation, registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, and most national ID systems. - -- DID controller: - - An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject. - -- DID delegate: - - An entity to whom a DID controller has granted permission to use a verification method associated with a DID via a DID document. For example, a parent who controls a child's DID document might permit the child to use their personal device in order to authenticate. In this case, the child is the DID delegate. The child's personal device would contain the private cryptographic material enabling the child to authenticate using the DID. However, the child might not be permitted to add other personal devices without the parent's permission. - -- DID document: - - A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. A DID document might have one or more different representations as defined in 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES]. - -- DID fragment: - - The portion of a DID URL that follows the first hash sign character (#). DID fragment syntax is identical to URI fragment syntax. - -- DID method: - - A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. - -- DID path: - -The portion of a DID URL that begins with and includes the first forward slash (/) character and ends with either a question mark (?) character, a fragment hash sign (#) character, or the end of the DID URL. DID path syntax is identical to URI path syntax. - -- DID query: - -The portion of a DID URL that follows and includes the first question mark character (?). DID query syntax is identical to URI query syntax. - -- DID resolution: - -The process that takes as its input a DID and a set of resolution options and returns a DID document in a conforming representation plus additional metadata. This process relies on the "Read" operation of the applicable DID method. - -- DID resolver: - -A DID resolver is a software and/or hardware component that performs the DID resolution function by taking a DID as input and producing a conforming DID document as output. - -- DID scheme: - -The formal syntax of a decentralized identifier. The generic DID scheme begins with the prefix did: as defined in DID Syntax. Each DID method specification defines a specific DID method scheme that works with that specific DID method. - -- DID subject: - -The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. - -- DID URL: - -A DID plus any additional syntactic component that conforms to the definition in 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character). - -- DID URL dereferencing: - -The process that takes as its input a DID URL and a set of input metadata, and returns a resource. This resource might be a DID document plus additional metadata, a secondary resource contained within the DID document, or a resource entirely external to the DID document. The process uses DID resolution to fetch a DID document indicated by the DID contained within the DID URL. The dereferencing process can then perform additional processing on the DID document to return the dereferenced resource indicated by the DID URL. The inputs and outputs of this process are defined in 7.2 DID URL Dereferencing. - -- DID URL dereferencer: - -A software and/or hardware system that performs the DID URL dereferencing function for a given DID URL or DID document. - -- public key description: - -A data object contained inside a DID document that contains all the metadata necessary to use a public key or a verification key. -resource -As defined by [RFC3986]: "...the term 'resource' is used in a general sense for whatever might be identified by a URI." Similarly, any resource might serve as a DID subject identified by a DID. - -- representation: - -As defined for HTTP by [RFC7231]: "information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data." A DID document is a representation of information describing a DID subject. See 6. Representations. - -- representation-specific entries: - -Entries in a DID document whose meaning is particular to a specific representation. Defined in 4. Data Model and 6. Representations. For example, @context in the JSON-LD representation is a representation-specific entry. - -- services: - -Means of communicating or interacting with the DID subject or associated entities via one or more service endpoints. Examples include discovery services, agent services, social networking services, file storage services, and verifiable credential repository services. - -- service endpoint, node, idx: - -A network address, such as an HTTP URL, at which services operate on behalf of a DID subject. -Uniform Resource Identifier (URI) -The standard identifier format for all resources on the World Wide Web as defined by [RFC3986]. A DID is a type of URI scheme. - -- verifiable credential: - -A standard data model and representation format for cryptographically-verifiable digital credentials as defined by the W3C Verifiable Credentials specification VC-DATA-MODEL. - -- verifiable data registry: -A system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. For more information, see the W3C Verifiable Credentials specification VC-DATA-MODEL. - -- verifiable timestamp: - -A verifiable timestamp enables a third-party to verify that a data object existed at a specific moment in time and that it has not been modified or corrupted since that moment in time. If the data integrity could reasonably have been modified or corrupted since that moment in time, the timestamp is not verifiable. - -- verification method: - -A set of parameters that can be used together with a process to independently verify a proof. For example, a cryptographic public key can be used as a verification method with respect to a digital signature; in such usage, it verifies that the signer possessed the associated cryptographic private key. -"Verification" and "proof" in this definition are intended to apply broadly. For example, a cryptographic public key might be used during Diffie-Hellman key exchange to negotiate a shared symmetric key for encryption. This guarantees the integrity of the key agreement process. It is thus another type of verification method, even though descriptions of the process might not use the words "verification" or "proof." - -- verification relationship: - -An expression of the relationship between the DID subject and a verification method. An example of a verification relationship is Authentication. - -- Universally Unique Identifier (UUID): - -A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable. - -### Future work and TODO: -As stateproofs are already integrated as an extension service to all Algorand DIDs verification methods in all reference implementations, hence there are some further steps to make it complete coverage regarding DID lifecycle: - -- Client side stateproof verification using DID information to implement Algorand DID self verification -- Add goal CLI to verification method services (up for debate) -- Add more resolution conventions -- Add more detail DID formatting for more extensions +### Terminology + This ARC complys to and inherits W3C DID terminology and definitions, as specified in the Decentralized Identifiers (DIDs) v1.0 specification. ## Rationale @@ -524,14 +361,14 @@ ARC-13 is proposed to bring the benefits of decentralized identity to the Algora The rationale on namespaces includes : - Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! -For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and AVM chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for AVM elements e.g. accounts! +For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and Algorand chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for Algorand elements e.g. accounts! UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof on usability and extendability! -NFD/ANS Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service, so instead of debating facts Algorand DIDs support and resolve both with no difference! +NFD Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service! Note: Algorand account addresses have no namespace and are considered root namespace under :algo! @@ -547,22 +384,22 @@ Algorand DID Resolver MAINNET UI: goplausible.xyz/api/1.0/identifiers/... -Algorand DID Resolver MAINNET API: goplausible.xyz/api/1.0/identifiers//... (Coming soon) +Universal DID Resolver: ThisDID -Algorand DID Resolver TESTNET API: -A fully working Resolver API has been implemented and is available for MAINNET and TESTNET (Algorand Universal DID Resolver) under standard endpoint (api/1.0/identifiers/did:algo...) +These universal Resolver API and UI have been implemented, under standard endpoints, and both support Algorand MAINNET and TESTNET DIDs. -- ASA DID Resolver -- APP DID Resolver -- TXN DID Resolver +- ASA DID Resolver +- APP DID Resolver +- TXN DID Resolver - ACCOUNT DID Resolver -- APPLICATION ACCOUNT DID Resolver +- APPLICATION ACCOUNT DID Resolver -Algorand DID Constructor TESTNET API: -A fully working DID constructor API has been implemented and is available for MAINNET and TESTNET under standard endpoint (api/did/): +Algorand DID Constructor API: +A fully working DID constructor API has been implemented and is available for MAINNET and TESTNET under standard endpoint (api/did/). Examples: - APP DID - ASSET DID @@ -680,44 +517,41 @@ did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q ``` - ASA: ``` -did:algo:testnet_asa:12400859 +did:algo:testnet:asa:12400859 -did:algo:mainnet_asa:31566704 +did:algo:mainnet:asa:31566704 ``` - TXN: ``` -did:algo:testnet_txn:L3OEIRCTGDXALCIDLOLGXOM3OECHVNPI2GXN6PTNOEJJQIJ4FIWA +did:algo:testnet:txn:L3OEIRCTGDXALCIDLOLGXOM3OECHVNPI2GXN6PTNOEJJQIJ4FIWA -did:algo:mainnet_txn:67HI3JHICQQB7KCWKCDYNANN57KL5LAUVQ3BJJFGRYEMAIEYBBVQ +did:algo:mainnet:txn:67HI3JHICQQB7KCWKCDYNANN57KL5LAUVQ3BJJFGRYEMAIEYBBVQ ``` - APP: ``` -did:algo:testnet_app:110096026 +did:algo:testnet:app:110096026 -did:algo:mainnet_app:350338509 +did:algo:mainnet:app:350338509 ``` - UUID: ``` -did:algo:testnet_uuid:c6bc3d9f-3e2c-4170-99e7-b9809f229ecb +did:algo:testnet:uuid:c6bc3d9f-3e2c-4170-99e7-b9809f229ecb -did:algo:mainnet_uuid:6ba7b814-9dad-11d1-80b4-00c04fd430c8 +did:algo:mainnet:uuid:6ba7b814-9dad-11d1-80b4-00c04fd430c8 ``` -- NFD/ANS: +- NFD: ``` did:algo:nfd:emg110.algo -did:algo:ans:emg110.algo -did:algo:nfd:emg110.algo -did:algo:ans:emg110.algo ``` -### Appendix B: DID document example (dummy data) +### Appendix B: DID document example (example data) ```json { "@context": [ "https://w3id.org/did-resolution/v1"], "didDocument": { - "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1", @@ -726,15 +560,15 @@ did:algo:ans:emg110.algo "verificationMethod": [ "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", { - "controller": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "id": "did:algo:mainnet_txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", + "controller": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", } ], "service": [ { - "id": "did:algo:web:mainnet_node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:algo:web:mainnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet_node/", + "serviceEndpoint": "https://mainnet:node/", "extensions": [ { "id": "algorand-state-proof", @@ -757,9 +591,9 @@ did:algo:ans:emg110.algo ] }, { - "id": "did:algo:web:mainnet_idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:algo:web:mainnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet_idx/", + "serviceEndpoint": "https://mainnet:idx/", "extensions": [ { "id": "algorand-signature", From dd85e99deeb7b755ee2f56e0a37530bcdba52bcc Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 7 Nov 2024 15:35:12 +0300 Subject: [PATCH 114/116] Update missed formatting --- ARCs/arc-0013.md | 799 +++++++++++++++++++++++------------------------ 1 file changed, 399 insertions(+), 400 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 45be3e64c..4d98213be 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -1,7 +1,7 @@ --- arc: 13 -title: Decentralized identifiers (DIDs) -description: DID (Decentralized identifier) Version 1.0 for Algorand blockchain. +title: Decentralized Identifiers (DIDs) +description: DID (Decentralized Identifier) Version 1.0 for Algorand blockchain. author: MG (@emg110), GoPlausible (@GoPlausible), GoraNetwork (@GoraNetwork), DaffiDigital (@DaffiDigital) status: Review type: Standards Track @@ -13,115 +13,116 @@ extended-by: 113, 110 ## Abstract -This ARC presents an implementation specification for Decentralized Identifiers (DIDs) v1.0, DID Specification Registries and Decentralized Identifier Resolution (DID Resolution) v0.3 W3C standards, addressing requirements and conventions to implement and use Decentralized Identifiers on Algorand blockchain for internal elements, labeling and external resources & elements in need of on-chain identification! +This ARC specifies the implementation of [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/), [DID Specification Registries](https://www.w3.org/TR/did-spec-registries/), and [Decentralized Identifier Resolution (DID Resolution) v0.3](https://w3c-ccg.github.io/did-resolution/) W3C standards on the Algorand blockchain. It addresses the requirements and conventions to implement and use DIDs for internal elements, labeling, and external resources requiring on-chain identification. -[ARC-113](./arc-0113.md) extends this ARC to implement W3C Verifiable Credentials! +[ARC-113](./arc-0113.md) extends this ARC to implement W3C Verifiable Credentials. -ASA ARCs can be extended by [ARC-13](./arc-0013.md) and also can be passively subject to it, including: +ASA ARCs that can be extended by [ARC-13](./arc-0013.md) and can also be passively subject to it include: -- [ARC-3](./arc-0003.md) -- [ARC-19](./arc-0019.md) +- [ARC-3](./arc-0003.md) +- [ARC-19](./arc-0019.md) -Algorand technology elements specifications and requirements are intended to be specified in this ARC to be identified using DIDs and DID documents. +This ARC specifies the use of DIDs and DID documents for identifying Algorand technology elements. ## Specification -All implementation guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","MAY NOT", "OPTIONAL," "RECOMMENDED," "REQUIRED" 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. -This ARC uses the term "account" to indicate a private key based unique externally owned account as an Algorand blockchain identity, while reserving the term "addr" as a method namespace for smart contract application escrow addresses on Algorand! +All implementation guidelines, diagrams, examples, and notes in this specification are non-normative. All other parts are normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY NOT", "OPTIONAL" 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 they appear in all capitals. -The ARC-13 standard aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its specifications and existing ARCs. +This ARC uses the term "account" to indicate a private key-based unique externally owned account as an Algorand blockchain identity, while reserving the term "addr" as a method namespace for smart contract application escrow addresses on Algorand. -This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents in a verifiable way, which is essential for verifiable digital identity. +ARC-13 aims to seamlessly integrate the W3C Decentralized Identifiers (DIDs) standards with the Algorand blockchain, leveraging its specifications and existing ARCs. This integration ensures that DIDs on Algorand maintain global uniqueness, immutability, and the ability to be resolved to DID documents in a verifiable way, which is essential for digital identity. -ARC-13 complies to [ARC-4](./arc-0004.md) and [ARC-22](./arc-0022.md) for readonly DID interfaces. +ARC-13 complies with [ARC-4](./arc-0004.md) for DID ABI methods and [ARC-22](./arc-0022.md) for read-only DID interfaces. -Conventions to conduct DID naming , namespace, ABNF grammar and DID registry/resolver specifications using Algorand decentralized ledger and storage space as well as construction and resolution methods in accordance to Algorand literature, syntax and vocabulary are included in ARC-13's scope! +Conventions for DID naming, namespace, ABNF grammar, and DID registry/resolver specifications using Algorand's decentralized ledger and storage are included in ARC-13's scope. -ARC-13 proposes two category of identifiers: +ARC-13 proposes two categories of identifiers: -- Elemental :Algorand element identifiers like transaction IDs, ASA IDs, APP IDs and account addresses and public keys! Elemental DIDs do not need any registry and decentralized ledger and DID document information is realized from on-chain data. -- Composed : uses UUIDs to register a unique identifier for an Algorand DID used for an external entity! Composed DIDs MUST have registry, lifecycle management and universal resolver implementations or their own! +- **Elemental**: Algorand element identifiers like transaction IDs, ASA IDs, APP IDs, and account addresses. Elemental DIDs do not need any registry; the decentralized ledger and DID document information are derived from on-chain data. +- **Composed**: Uses UUIDs to register a unique identifier for an Algorand DID used for an external entity. Composed DIDs **MUST** have registry, lifecycle management, and universal resolver implementations or their own. -ARC-13 implements supports both on-chain (**MUST** use box storage) and off-chain (**MUST** use CID Version 1) based decentralized storage systems like IPFS, CrustNetwork, etc. +ARC-13 supports both on-chain (**MUST** use box storage) and off-chain (**MUST** use CID Version 1) decentralized storage systems like IPFS, CrustNetwork, etc. -ARC-13 implementation **MUST** used box storage to store either byte value of the DID document JSON, or CID Version 1 of DID document JSON as value, with DID identifier as key! Either is accepted under ARC13 but it is **RECOMMENDED** that DID documents under 4 Kb store as bytes onchain and for those above 4 Kb , a CID V1 compliant storage be used. +ARC-13 implementations **MUST** use box storage to store either the byte value of the DID document JSON or the CID Version 1 of the DID document JSON as value, with the DID identifier as key. Either is accepted under ARC-13, but it is **RECOMMENDED** that DID documents under 4 KB be stored as bytes on-chain, and for those above 4 KB, a CID V1 compliant storage be used. ### General Format -- Algorand DID elements specified by this ARC follow the URI format in general as outlined in RFC 3986. The Public key part is implemented as "publicKeyMultibase" using W3C Multibase format and account address! Given the extent of responsibility DID resolvers have in DID lifecycle , and given the fact that Algorand address is a deterministic representation of Public key, therefore using Multibase format with base32 notation "B" character followed by uppercase address SHOULD BE allowed by DID standard to be used with "Ed25519VerificationKey2020" and even also "publicKeyJwk"! +- Algorand DIDs follow the URI format as outlined in [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986). The public key is implemented as "publicKeyMultibase" using [W3C Multibase format](https://w3c-ccg.github.io/multibase/) and the account address. Given that the Algorand address is a deterministic representation of the public key, using Multibase format with base32 notation ("B" character followed by the uppercase address) SHOULD be allowed by the DID standard for use with "Ed25519VerificationKey2020" and "publicKeyJwk". -- 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]. -- Under DID services, Algorand API endpoints can be can OPTIONALLY use universal naming (Algod, Idx, Kmd) for ease of use and readability: +- 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](https://www.rfc-editor.org/rfc/rfc3986). + +- Under DID services, Algorand API endpoints can OPTIONALLY use universal naming (Algod, Idx, Kmd) for ease of use and readability: ``` did:algo:web:testnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ did:algo:web:testnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ - ``` + The service endpoint for this OPTIONAL setting should be specified like: - ``` - "serviceEndpoint": "https://testnet:node/" - "serviceEndpoint": "https://testnet:idx/" - ``` - when endpoints are used in universal descriptor format, there will be no need to specify the full URL which may be subject to change from user to user! + ``` + "serviceEndpoint": "https://testnet:node/" + "serviceEndpoint": "https://testnet:idx/" + ``` + + When endpoints are used in universal descriptor format, there will be no need to specify the full URL, which may be subject to change from user to user. - // This section is non-normative. +- **Linked Data** is a way to create a network of standards-based machine-interpretable data across different documents and websites. It allows an application to start at one piece of Linked Data and follow embedded links to other pieces of Linked Data hosted on different sites across the Web. -- Linked Data LINKED-DATA is a way to create a network of standards-based machine interpretable data across different documents and Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web. +- **JSON-LD** is a lightweight syntax to serialize Linked Data in JSON [RFC8259](https://www.rfc-editor.org/rfc/rfc8259). Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD introduces: -- JSON-LD is a lightweight syntax to serialize Linked Data in JSON [RFC8259]. Its design allows existing JSON to be interpreted as Linked Data with minimal changes. JSON-LD is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines. Since JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries available today can be reused. In addition to all the features JSON provides, JSON-LD introduces: - - a universal identifier mechanism for JSON objects via the use of IRIs, - - a way to disambiguate keys shared among different JSON documents by mapping them to IRIs via a context, - - a mechanism in which a value in a JSON object may refer to a resource on a different site on the Web, - the ability to annotate strings with their language, - - a way to associate datatypes with values such as dates and times, - and a facility to express one or more directed graphs, such as a social network, in a single document. + - A universal identifier mechanism for JSON objects via the use of IRIs. + - A way to disambiguate keys shared among different JSON documents by mapping them to IRIs via a context. + - A mechanism in which a value in a JSON object may refer to a resource on a different site on the Web. + - The ability to annotate strings with their language. + - A way to associate datatypes with values such as dates and times. + - A facility to express one or more directed graphs, such as a social network, in a single document. -### Main elements +### Main Elements The main elements of the Algorand DID based on the DID data model are: -- DID Scheme: did:algo: The unique scheme for Algorand DIDs. -- Element: An Algorand unique element entity as a subject for DID -- Network Identifier: testnet or mainnet Specifies the Algorand network (testnet or mainnet). -- Namespace: Identifies the type of Algorand element the DID represents (e.g., asa, txn, app). -- Unique Identifier: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). -- Local elements: Algorand Elements with locally Unique Identifiers like assets and applications! -- Global elements: Algorand Elements with global Unique Identifiers like Transactions, UUIDs and accounts. -- Internal elements: Elements with direct verification and proofs on Algorand (TXN, ASA, APP, ACCOUNT and ADDR) -- Service elements: Elements out of Algorand chains (UUID) +- **DID Scheme**: `did:algo:` The unique scheme for Algorand DIDs. +- **Element**: An Algorand unique element entity as a subject for DID. +- **Network Identifier**: `testnet` or `mainnet`. Specifies the Algorand network. +- **Namespace**: Identifies the type of Algorand element the DID represents (e.g., `asa`, `txn`, `app`). +- **Unique Identifier**: A specific identifier unique to the namespace (e.g., ASA ID, transaction hash, application ID). +- **Local Elements**: Algorand elements with locally unique identifiers like assets and applications. +- **Global Elements**: Algorand elements with globally unique identifiers like transactions, UUIDs, and accounts. +- **Internal Elements**: Elements with direct verification and proofs on Algorand (`txn`, `asa`, `app`, `account`, and `addr`). +- **Service Elements**: Elements outside of Algorand chains (e.g., UUID). -![Curtsey of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -DID General Architecture: Curtsey of W3C Decentralized Identifiers (DIDs) v1.0 +![Courtesy of W3C](./../assets/arc-0013/did_detailed_architecture_overview.svg) -According to DID general architecture version 1.0, ARC-13 provides standard coverage, specification and also reference implementation for: -- DID URI (Spec, API and from client library) -- DID Document (Spec, API and from client library) -- DID Registry (Spec & ABI) -- DID Resolver (Spec, ABI, API, UI and from client library) +**DID General Architecture**: Courtesy of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) +According to DID general architecture version 1.0, ARC-13 provides standard coverage, specification, and reference implementation for: -### DID lifecycle +- **DID URI** (Spec, API, and client library) +- **DID Document** (Spec, API, and client library) +- **DID Registry** (Spec & ABI) +- **DID Resolver** (Spec, ABI, API, UI, and client library) -Different DID life stages depicted here. Stage status is stored in value of DID "status" field! The status different values: -- NA: Not Available -- 0: OK -- 1: FLAG:SUSPEND -- 2: FLAG:REVOKED +### DID Lifecycle -Note: There is no deletion in real practice for DIDs on blockchain, however deleting from registry and not available box storage record for that DID works like deletion for DID lifecycle on Algorand blockchain but the issuance and lifetime records and transactions and verifications will live forever on chain, and accessible if looked for! - -```mermaid +Different DID life stages are depicted here. The stage status is stored in the "status" field of the DID. The status values: + +- **NA**: Not Available +- **0**: OK +- **1**: FLAG:SUSPEND +- **2**: FLAG:REVOKED +Note: There is no deletion in practice for DIDs on blockchain. Deleting from the registry and removing the box storage record for that DID acts like deletion in the DID lifecycle on the Algorand blockchain, but the issuance and lifetime records and transactions and verifications will remain forever on-chain and accessible if looked for. + +```mermaid flowchart LR creation[Creation] registration[Registration] resolution[Resolution] use[Use] - suspension[Suspension -Optional] - revocation[Revocation -Optional] + suspension[Suspension - Optional] + revocation[Revocation - Optional] deletion[Deletion] creation -->|DID is generated| registration registration -->|DID is registered| resolution @@ -129,13 +130,11 @@ flowchart LR use -->|DID is actively used| suspension suspension -->|DID is temporarily inactive| revocation revocation -->|DID is permanently deactivated| deletion - ``` #### DID URI ABNF Grammar -The generic DID scheme is a URI scheme conformant with [RFC3986]. The ABNF definition can be found below, which uses the syntax in [RFC5234] and the corresponding definitions for ALPHA and DIGIT. All other rule names not defined in the ABNF below are defined in [RFC3986]. All DIDs MUST conform to the DID Syntax ABNF Rules. -The ABNF (Augmented Backus-Naur Form) grammar for Algorand DIDs is aligned with the general DID ABNF grammar, with specific adaptations for Algorand's unique elements: +The generic DID scheme is a URI scheme conformant with [RFC3986](https://www.rfc-editor.org/rfc/rfc3986). The ABNF definition uses the syntax in [RFC5234](https://www.rfc-editor.org/rfc/rfc5234). All DIDs **MUST** conform to the DID Syntax ABNF Rules. ``` DID Syntax ABNF: @@ -145,196 +144,201 @@ methodchar = %x61-7A / DIGIT ; 'a'-'z' and digits method-specific-id = *( *idchar ":" ) 1*idchar idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded pct-encoded = "%" HEXDIG HEXDIG - ``` --------------- + +--- ``` -The Algorand extended DID Syntax ABNF: +Algorand Extended DID Syntax ABNF: did = "did:" method-name ":" method-specific-id method-name = "algo" ; Algorand method name algorand-network = "testnet" / "mainnet" / "devnet" / "betanet" ; Algorand network identifiers algorand-namespace = "asa" / "txn" / "app" / "uuid" / "nfd" / "addr" ; Algorand namespace identifiers method-specific-id = algorand-network ":" algorand-namespace ":" algorand-identifier -algorand-identifier = 1*idchar ; Unique identifier **MUST BE** unique in the Algorand ecosystem. - +algorand-identifier = 1*idchar ; Unique identifier in the Algorand. ``` -If either "addr", "asa", "app" or "txn" namespaces are used it **MUST BE** used with algorand-network since these are network dependant identifiers, hence **MUST** be used with network identifier! +If "addr", "asa", "app", or "txn" namespaces are used, they **MUST** be used with `algorand-network` since these are network-dependent identifiers. -DID URL Syntax ABNF: +**DID URL Syntax ABNF:** -A DID URL is a network location identifier useful for a specific resource used by an element which should be one of: -- NFD (NFDomains Algorand name service unique names) -- APP (Application Identifiers) -- UUID (V4) -- ACCOUNT (EOA) -- ADDR (Application escrow address) -- ASA (Asset Identifiers) +A DID URL is a network location identifier useful for a specific resource used by an element, which should be one of: +- **NFD** (NFDomains Algorand name service unique names) +- **APP** (Application Identifiers) +- **UUID** (V4) +- **ACCOUNT** (EOA) +- **ADDR** (Application escrow address) +- **ASA** (Asset Identifiers) -NOTE: Semicolon character MUST NOT be used! +**NOTE**: Semicolon character **MUST NOT** be used. - -The following is the exact ABNF definition using the syntax in [RFC5234] and taken from Decentralized Identifiers (DIDs) v1.0. The path-abempty, query, and fragment components are defined in [RFC3986]: +The following is the exact ABNF definition using the syntax in [RFC5234] and taken from [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/). The `path-abempty`, `query`, and `fragment` components are defined in [RFC3986]: ``` did-url = did path-abempty [ "?" query ] [ "#" fragment ] ``` ARC-13 fragments are used to extend DID URL by parametric or path routes. The following fragments are allowed under ARC-13: -- NFT ARCs and Hierarchies -- APP ARCs -- URI Fragments -- Key fragments: - - AUTH (Rekeyed) - - HD Wallets -- VerificationMethods - - ZK (Zero Knowledge) +- **NFT ARCs and Hierarchies** +- **APP ARCs** +- **URI Fragments** +- **Key Fragments**: + - **AUTH** (Rekeyed) + - **HD Wallets** +- **VerificationMethods** + - **ZK** (Zero Knowledge) + +#### DID Document Specifications +![Courtesy of W3C](../assets/arc-0013/diagram-did-document-entries.svg) -#### DID Document specifications -![Curtsey of W3C](../assets/arc-0013/diagram-did-document-entries.svg) -DID Document constituents: Curtsey of W3C https://www.w3.org/TR/did-core/ +**DID Document Constituents**: Courtesy of W3C [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) + +##### DID Document Properties Specifications: -##### DID Document properties specifications: - **id**: A string that conforms to the rules in DID Syntax. -- **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986] for URIs. +- **alsoKnownAs**: A set of strings that conform to the rules of [RFC3986](https://www.rfc-editor.org/rfc/rfc3986) for URIs. - **controller**: A string or a set of strings that conform to the rules in DID Syntax. - **verificationMethod**: A set of Verification Method maps that conform to the rules in Verification Method properties. - **id**: A string that conforms to the rules in 3.2 DID URL Syntax. - **controller**: A string that conforms to the rules in DID Syntax. - - **type**: A string - - **publicKeyJwk**: A map representing a JSON Web Key that conforms to [RFC7517]. See definition of publicKeyJwk for - additional constraints. - - **publicKeyMultibase**: A string that conforms to a [MULTIBASE] encoded public key. + - **type**: A string. + - **publicKeyJwk**: A map representing a JSON Web Key that conforms to [RFC7517](https://www.rfc-editor.org/rfc/rfc7517). + - **publicKeyMultibase**: A string that conforms to a [MULTIBASE](https://datatracker.ietf.org/doc/html/draft-multiformats-multibase) encoded public key. - **service**: A set of Service Endpoint maps that conform to the rules in Service properties. - - **id**: A string that conforms to the rules of [RFC3986] for URIs. + - **id**: A string that conforms to the rules of [RFC3986](https://www.rfc-editor.org/rfc/rfc3986) for URIs. - **type**: A string or a set of strings. - - **serviceEndpoint**: A string that conforms to the rules of [RFC3986] for URIs, a map, or a set composed of a one or more strings that conform to the rules of [RFC3986] for URIs and/or maps. + - **serviceEndpoint**: A string that conforms to the rules of [RFC3986](https://www.rfc-editor.org/rfc/rfc3986) for URIs, a map, or a set composed of one or more strings that conform to the rules of [RFC3986](https://www.rfc-editor.org/rfc/rfc3986) for URIs and/or maps. +##### Verification Method Relationships: -##### Verification method relationships: - - **authentication**: A set of either Verification Method maps that conform to the rules in Verification Method properties or strings that conform to the rules in DID URL Syntax. - - **assertionMethod**: The assertionMethod verification relationship is used to specify how the DID subject is expected to express claims, such as for the purposes of issuing a Verifiable Credential VC-DATA-MODEL - - **keyAgreement**: The keyAgreement verification relationship is used to specify how an entity can generate encryption material in order to transmit confidential information intended for the DID subject, such as for the purposes of establishing a secure communication channel with the recipient. - - **capabilityInvocation**: The capabilityInvocation verification relationship is used to specify a verification method that might be used by the DID subject to invoke a cryptographic capability, such as the authorization to update the DID Document. - - **capabilityDelegation**: The capabilityDelegation verification relationship is used to specify a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party, such as delegating the authority to access a specific HTTP API to a subordinate. +- **authentication**: A set of either Verification Method maps or strings that conform to the rules in DID URL Syntax. +- **assertionMethod**: Specifies how the DID subject is expected to express claims, such as for issuing a Verifiable Credential ([VC-DATA-MODEL](https://www.w3.org/TR/vc-data-model-2.0/)). +- **keyAgreement**: Specifies how an entity can generate encryption material to transmit confidential information intended for the DID subject. +- **capabilityInvocation**: Specifies a verification method that might be used by the DID subject to invoke a cryptographic capability. +- **capabilityDelegation**: Specifies a mechanism that might be used by the DID subject to delegate a cryptographic capability to another party. -ARC-13 subjects are RECOMMENDED to use "alsoKnownAs" in order to gather all representations of an identifier in one DID when applicable! E.g. Having name service DID as well as account DID of a known EOA! +ARC-13 subjects are **RECOMMENDED** to use `alsoKnownAs` to gather all representations of an identifier in one DID when applicable (e.g., having name service DID as well as WEB DID of a known account). -ARC-13 Verification methods in relationships between subjects can be either single purpose so they would be described in full within verification method, or they have multi-purpose (E.g. Authentication and encryption) just referenced by DID: +ARC-13 Verification methods in relationships between subjects can be either single-purpose (described in full within verification method) or multi-purpose (e.g., authentication and encryption), just referenced by DID: -``` +```json { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "verificationMethod": [ - // A known DID for auth account of a rekeyed account - "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", - - // A stand alone ARC52 DH derived symmetric key + "did:exaalgomple:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", { - "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "type": "Ed25519VerificationKey2020", - "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "publicKeyMultibase": "BJKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y" + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#arc52", + "type": "RsaVerificationKey2018", + "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" } - ], - + ] } ``` -##### Context model -ARC-13 makes use of 3 predefined contexts for DIDs: -- DID document context: "https://www.w3.org/ns/did/v1" -- DID Ed25519 security suite context: "https://w3id.org/security/suites/ed25519-2020/v1" -- DID security context: "https://w3id.org/security/v1" -##### Multisig DID modeling -Since DIDs support multi controller models in both independent and control group formations, multisigs SHOULD be modeled as control groups , controlling a single DID (multisig account): +##### Context Model -![](../assets/arc-0013/figure-c.2-group-did-controllers.svg) +ARC-13 uses three predefined contexts for DIDs: -##### Rekeyed account DID modeling -Rekeyed accounts MUST contain both the rekeyed and auth account verifiers in DID document used with "#auth" and "rekeyed" fragments in id property field of Verification Method: +- **DID Document Context**: `"https://www.w3.org/ns/did/v1"` +- **DID Ed25519 Security Suite Context**: `"https://w3id.org/security/suites/ed25519-2020/v1"` +- **DID Security Context**: `"https://w3id.org/security/v1"` -``` +##### Multisig DID Modeling -{ - "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "@context": [ - "https://www.w3.org/ns/did/v1", - "https://w3id.org/security/suites/ed25519-2020/v1", - "https://w3id.org/security/v1" - ], - "verificationMethod": [ - { - "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#rekeyed", - "publicKeyMultibase": "BLP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", - "type": "Ed25519VerificationKey2020" - }, - { - "controller": "did:algo:JKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", - "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", - "publicKeyMultibase": "BJKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", - "type": "Ed25519VerificationKey2020" - } - - ], - "authentication": [ - "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth" - ], +Since DIDs support multi-controller models, multisigs SHOULD be modeled as control groups controlling a single DID (multisig account): - } +![Multisig DID Modeling](../assets/arc-0013/figure-c.2-group-did-controllers.svg) + +##### Rekeyed Account DID Modeling +Rekeyed accounts **MUST** contain both the rekeyed and auth account verifiers in the DID document, using `#auth` and `#rekeyed` fragments in the `id` property field of the Verification Method: + +```json +{ + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "@context": [ + "https://www.w3.org/ns/did/v1", + "https://w3id.org/security/suites/ed25519-2020/v1", + "https://w3id.org/security/v1" + ], + "verificationMethod": [ + { + "controller": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#rekeyed", + "publicKeyMultibase": "BLP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q", + "type": "Ed25519VerificationKey2020" + }, + { + "controller": "did:algo:JKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", + "id": "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", + "publicKeyMultibase": "BJKFVZMGE2J7FXEVVGHC7ESPBRNVEKGFAJEESPLCYYM5CZBZCHS7QWDZ34Y", + "type": "Ed25519VerificationKey2020" + } + ], + "authentication": [ + "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth" + ] +} ``` #### DID Resolver -Algorand universal DID resolver MUST strictly follow W3C https://w3c-ccg.github.io/did-resolution/! -The ARC-13 DID resolution implementations through ABI, API, Client library and Web UI SHOULD be accessible publicly! +Algorand universal DID resolver **MUST** strictly follow W3C [DID Resolution](https://w3c-ccg.github.io/did-resolution/). + +The ARC-13 DID resolution implementations through ABI, API, client library, and Web UI **SHOULD** be publicly accessible. #### DID Registry -ARC-13 DID registry implementation MUST strictly follow and show full compliance to DID Specification Registries! + +ARC-13 DID registry implementation **MUST** strictly follow and show full compliance to [DID Specification Registries](https://w3c-ccg.github.io/did-spec-registries/). The ARC-13 Algorand DID registry: -- For local elements: - - An active registry method, API, UI and client to construct DIDs based on Algorand node and indexer data which guarantees 1:1 existing DID subject per Algorand onchain entity! -- An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way! +- For local elements: + - An active registry method, API, UI, and client to construct DIDs based on Algorand node and indexer data, guaranteeing a 1:1 existing DID subject per Algorand on-chain entity. +- An active registry service to register and manage Algorand sub-namespace elements DID lifecycle through ABI in a decentralized way. #### DID Document -Important considerations regarding transaction DIDs with offline and online self verification methods: + +Important considerations regarding transaction DIDs with offline and online self-verification methods: 1. **Verification Methods for Transaction DIDs**: - - A DID document can include public key verification methods that are specifically used to verify the authenticity and integrity of the transaction associated with the DID. + + - A DID document can include public key verification methods specifically used to verify the authenticity and integrity of the transaction associated with the DID. - The controller of these verification methods can be the entity that initiated the transaction, such as the transaction sender. 2. **Scope of Verification Methods**: - - The DID document can be tailored to include only those verification methods that are relevant to the transaction. This means it can carry verification methods solely for the purpose of verifying the transaction DID itself. - - The controllers of these verification methods would typically be entities involved in the transaction, ensuring that the verification process is directly linked to the transaction's participants. + + - The DID document can be tailored to include only those verification methods relevant to the transaction. + - The controllers of these verification methods would typically be entities involved in the transaction, linking the verification process directly to the transaction's participants. 3. **Compliance with DID Standard**: - - This approach is compliant with the DID standard, which is flexible and allows for various implementations and use cases. The standard does not restrict the types of verification methods that can be included in a DID document, as long as they adhere to the overall structure and principles of DIDs. + + - This approach is compliant with the DID standard, which allows for various implementations and use cases. 4. **Use Case Specificity**: - - This kind of implementation is particularly useful in blockchain-based environments where transactions are key elements of the system. The DID document effectively becomes a tool for transaction verification. + + - Particularly useful in blockchain environments where transactions are key elements. The DID document becomes a tool for transaction verification. ### Algorand DID Registry -According to standard DID architecture from W3C, The DID registry is a must have entity that can eb either centralized (e.g. using centralized APIs and Databases) or decentralized (e.g. using smart contracts and decentralized storage) ! -ARC-13 working group also provides an Algorand decentralized DID registry and resolution infrastructure, which already provides did registration and resolution for all Algorand elements on both TESTNET and MAINNET! + +According to standard DID architecture from W3C, the DID registry is an essential entity that can be either centralized (e.g., using centralized APIs and databases) or decentralized (e.g., using smart contracts and decentralized storage). + +The ARC-13 working group provides an Algorand decentralized DID registry and resolution infrastructure, offering DID registration and resolution for all Algorand elements on both TESTNET and MAINNET. ```mermaid flowchart TB subgraph did_architecture ["Algorand DID Architecture"] did_uri["Algorand DID URI"] did_doc["Algorand DID Document"] - did_subject["DID Subject (e.g. asa, app, txn,...)"] + did_subject["DID Subject (e.g., asa, app, txn)"] did_controller["DID Controller (Entity controlling the DID Document)"] verifiable_data_registry["Verifiable Data Registry (Algorand Blockchain)"] did_resolver["DID Resolver (Resolves DID to DID Document)"] @@ -346,292 +350,287 @@ flowchart TB did_uri -->|Resolved by| did_resolver did_uri -->|Dereferenced by| did_url_dereferencer end - style did_architecture stroke:#333,stroke-width:2px - ``` ### Terminology - This ARC complys to and inherits W3C DID terminology and definitions, as specified in the Decentralized Identifiers (DIDs) v1.0 specification. +This ARC complies with and inherits W3C DID terminology and definitions, as specified in the [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) specification. ## Rationale -ARC-13 is proposed to bring the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public and decentralized way. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and Enterprise sector to be general. +ARC-13 brings the benefits of decentralized identity to the Algorand ecosystem in a universally accessible, public, and decentralized manner. By adopting the W3C DID standard, Algorand users can leverage a globally recognized framework for digital identity, enhancing interoperability, security, and trust in digital interactions. This standard also paves the way for advanced use cases in decentralized finance, supply chain, and enterprise sectors. -The rationale on namespaces includes : -- Re-usability of currently locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements by turning both classes directly into semantically identical DIDs which is human readable without further interpretations! -For example resolve chain IDs to chain names has been omitted by not using chain Ids in namespaces , since Algorand does not Fork and Algorand chains are on 100% good terms in case of standardization, therefore there is no need for lower level roots (e.g. UUID) for Algorand elements e.g. accounts! +The rationale for namespaces includes: +- **Reusability**: Turning locally (ASA, APP) or globally (ADDRESS, TXNID) identified elements into semantically identical DIDs, which are human-readable without further interpretation. -UUID Rationale: having UUID as first class citizen here to be used above or below any Algorand identifier give the ability of infinite possible scenarios to use and link offchain/onchain assets as composed entities ! +For example, resolving chain IDs to chain names has been omitted by not using chain IDs in namespaces, since Algorand does not fork and Algorand chains are standardized. Therefore, there is no need for lower-level roots (e.g., UUID) for Algorand elements like accounts. -As composability is one of Algorand technology mottos , this ARC by using UUIDs , aligns by-design with upstream and stays future-proof on usability and extendability! +**UUID Rationale**: Having UUID as a first-class citizen provides infinite possible scenarios to use and link off-chain/on-chain assets as composed entities. This aligns with Algorand's focus on composability. -NFD Rationale: nfd is a well-known namespace in Algorand and ans is the standard namespace naming for Algorand Naming Service! +**NFD Rationale**: `nfd` is a well-known namespace in Algorand, and `ans` is the standard namespace naming for Algorand Naming Service. -Note: Algorand account addresses have no namespace and are considered root namespace under :algo! +**Note**: Algorand account addresses have no namespace and are considered root namespace under `algo`. ## Reference Implementation -All specified living standards that ARC-13 comply to are expected to be concisely implemented and complete compliance and consideration of all W3C DID implementation guidelines! + +All specified living standards that ARC-13 complies with are expected to be concisely implemented, with complete compliance and consideration of all [W3C DID implementation guidelines](https://w3c.github.io/did-imp-guide/). ### Algorand DID Resolver UI -A fully working Resolver UI has been implemented by ARC-13 and is available for MAINNET and TESTNET (Algorand Universal DID Resolver UI) under standard path (did-resolver) -Algorand DID Resolver TESTNET UI: Algorand TESTNET DID Resolver> +A fully working Resolver UI has been implemented and is available for MAINNET and TESTNET under the standard path (`did-resolver`): + +- **Algorand DID Resolver TESTNET UI**: [Algorand TESTNET DID Resolver](https://testnet.goplausible.xyz/did-resolver/) +- **Algorand DID Resolver MAINNET UI**: [Algorand DID Resolver](https://goplausible.xyz/did-resolver/) (Coming soon) -Algorand DID Resolver MAINNET UI: Algorand DID Resolver (Coming soon) +### Universal DID Resolver with Algorand Resolver -Note: An example DID has been included as default in examples above! Feel free to change it with your desired Algorand DID! +- **Universal DID Resolver API**: [goplausible.xyz/api/1.0/identifiers/](https://goplausible.xyz/api/1.0/identifiers/) +- **Universal DID Resolver**: [ThisDID](https://ThisDID.com) -### Universal DID Resolver with Algorand resolver +These universal Resolver API and UI support Algorand MAINNET and TESTNET DIDs. -Universal DID Resolver API: goplausible.xyz/api/1.0/identifiers/... +Examples: -Universal DID Resolver: ThisDID +- [ASA DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet:asa:541958085) +- [APP DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet:app:541957142) +- [TXN DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet:txn:224FVUWR46D6ZCYO5RS6RPJYCKEPNRWLVSNV2F7HXHHEPDAMGIIQ) +- [ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) +- [APPLICATION ACCOUNT DID Resolver](https://test.goplausible.xyz/api/1.0/identifiers/did:algo:testnet:addr:JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) -These universal Resolver API and UI have been implemented, under standard endpoints, and both support Algorand MAINNET and TESTNET DIDs. +**Algorand DID Constructor API**: -- ASA DID Resolver -- APP DID Resolver -- TXN DID Resolver -- ACCOUNT DID Resolver -- APPLICATION ACCOUNT DID Resolver - -Algorand DID Constructor API: -A fully working DID constructor API has been implemented and is available for MAINNET and TESTNET under standard endpoint (api/did/). Examples: +A fully working DID constructor API is available under the standard endpoint (`api/did/`). Examples: -- APP DID -- ASSET DID -- Transaction DID -- Account DID +- [APP DID](https://test.goplausible.xyz/api/did/541958085) +- [ASSET DID](https://test.goplausible.xyz/api/did/541957142) +- [Transaction DID](https://test.goplausible.xyz/api/did/JXOHOM3HQZ6IQ3BY7PGXCKXZTA3RXTTK6SOE7DA4N42T2XYNJGPZNMJLOA) +- [Account DID](https://test.goplausible.xyz/api/did/LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q) -### Algorand DID Resolver Client library -A fully featured client reference implementation and library is available on Github under MIT license and an NPM package to be used publicly! +### Algorand DID Resolver Client Library -The codebase instantiates an Algorand DID Resolver standard instance with DID and NETWORK arguments! +A fully featured client reference implementation and library is available on GitHub under MIT license and as an NPM package: -Then resolver instance has two methods: +- **Algorand DID Resolver Client**: [algo-did-resolver NPM Package](https://npm.org/algo-did-resolver) -- resolve(did: did) : This retrieves the DID document for given -- did_uri(id: string): This method creates a DID URI from Algorand element ID (TXN, ASA, APP) +The codebase instantiates an Algorand DID Resolver standard instance with DID and NETWORK arguments. The resolver instance has two methods: -Algorand DID Resolver Client: algo-did-resolver NPM Package +- `resolve(did)`: Retrieves the DID document for a given DID. +- `did_uri(id)`: Creates a DID URI from an Algorand element ID (`txn`, `asa`, `app`). ### Algorand DID Registry and Resolver ABI -A fully working Resolver ABI has been implemented by ARC-13 and is available for MAINNET and TESTNET through GoPlausible main contracts to serve as Algorand Universal DID Registry: -DID registry MAINNET contract: 946441472 (Coming soon) +A fully working Resolver ABI is available through GoPlausible main contracts: -DID registry TESTNET contract: 119642157 +- **DID Registry MAINNET Contract**: [946441472](https://algoexplorer.io/application/946441472) (Coming soon) +- **DID Registry TESTNET Contract**: [119642157](https://testnet.algoexplorer.io/application/119642157) -Through these two ABI methods: +Key ABI methods include: +```json +{ + "name": "register_algo_did", + "args": [ + { + "type": "pay", + "name": "pay_box_mbr_fees" + }, + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + { + "type": "bytes[]", + "name": "Algorand DID doc", + "desc": "DID docs up to 4KB will be stored as box value; above 4KB will be uploaded to IPFS with 'ipfs/CID' format" + } + ], + "returns": { + "type": "string" + }, + "desc": "Registers a new DID by creating a box with DID URI as key and DID document or IPFS CID as value." +}, +{ + "name": "get_algo_did_status", + "args": [ + { + "type": "bytes[]", + "name": "Algorand DID URI" + } + ], + "returns": { + "type": "string" + }, + "desc": "Retrieves the DID status in the registry." +}, +{ + "name": "set_algo_did_status", + "args": [ + { + "type": "pay", + "name": "pay_box_mbr_fees" + }, + { + "type": "bytes[]", + "name": "Algorand DID URI" + }, + { + "type": "uint64", + "name": "Algorand DID status", + "desc": "Algorand DID status ['0:OK','1:FLAG:SUSPEND', '2:FLAG:REVOKE']" + } + ], + "returns": { + "type": "string", + "desc": "Updated DID URI" + }, + "desc": "Sets the DID status; default registered DID status is 0." +}, +{ + "name": "resolve_algo_did", + "args": [ + { + "type": "bytes[]", + "name": "Algorand DID URI" + } + ], + "returns": { + "type": "string", + "desc": "Algorand DID document for the given DID URI" + }, + "desc": "Retrieves the DID document given a DID URI." +} ``` - { - "name": "register_algo_did", - "args": [ - { - "type": "pay", - "name": "pay_box_mbr_fees" - }, - { - "type": "bytes[]", - "name": "Algorand DID URI" - }, - { - "type": "bytes[]", - "name": "Algorand DID doc", - "desc": "DID docs up to 4kb will be stored as box value and above 4kb would be uploaded to IPFS and CID will be sent as doc with 'ipfs/CID' format" - } - - ], - "returns": { - "type": "string" - }, - "desc": "Called using registrar account on request + payment reception from an Algorand account to register a new DID! This creates a box with DID URI as key and DID document (JSON_LD) or IPFS CID bytes as value!" - - }, - { - "name": "get_algo_did_status", - "args": [ - { - "type": "bytes[]", - "name": "Algorand DID URI" - } - ], - "returns": { - "type": "string" - }, - "desc": "Called publicly to get the DID status in registry" - }, - { - "name": "set_algo_did_status", - "args": [ - { - "type": "pay", - "name": "pay_box_mbr_fees" - }, - { - "type": "bytes[]", - "name": "Algorand DID URI" - }, - { - "type": "uint64", - "name": "Algorand DID status", - "desc": "Algorand DID status ['0:OK','1:FLAG:SUSPEND', '2: FLAG:REVOKE']" - } - ], - "returns": { - "type": "string", - "desc": "Updated DID URI" - }, - "desc": "Called using registrar account or DID controller to set DID status! Default registered DID status is 0" - }, - { - "name": "resolve_algo_did", - "args": [ - { - "type": "bytes[]", - "name": "Algorand DID URI" - } - ], - "returns": { - "type": "string", - "desc": "Algorand DID document for given DID URI" - }, - "desc": "Called publicly to get DID document given a DID URI!" - } - -``` +### Appendix A: DID Examples for All Namespaces -### Appendix A: DID examples for all namespaces +Examples of DIDs for each Algorand element type for both testnet and mainnet instances: -Examples of DIDs for each Algorand element type for both testnet and mainnet instance -- No namespace: -``` -did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q +- **No Namespace**: -did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q -``` -- ASA: -``` -did:algo:testnet:asa:12400859 + ``` + did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q + ``` -did:algo:mainnet:asa:31566704 -``` -- TXN: -``` -did:algo:testnet:txn:L3OEIRCTGDXALCIDLOLGXOM3OECHVNPI2GXN6PTNOEJJQIJ4FIWA +- **ASA**: -did:algo:mainnet:txn:67HI3JHICQQB7KCWKCDYNANN57KL5LAUVQ3BJJFGRYEMAIEYBBVQ -``` -- APP: -``` -did:algo:testnet:app:110096026 + ``` + did:algo:testnet:asa:12400859 + did:algo:mainnet:asa:31566704 + ``` -did:algo:mainnet:app:350338509 -``` +- **TXN**: -- UUID: -``` -did:algo:testnet:uuid:c6bc3d9f-3e2c-4170-99e7-b9809f229ecb + ``` + did:algo:testnet:txn:L3OEIRCTGDXALCIDLOLGXOM3OECHVNPI2GXN6PTNOEJJQIJ4FIWA + did:algo:mainnet:txn:67HI3JHICQQB7KCWKCDYNANN57KL5LAUVQ3BJJFGRYEMAIEYBBVQ + ``` -did:algo:mainnet:uuid:6ba7b814-9dad-11d1-80b4-00c04fd430c8 -``` -- NFD: -``` -did:algo:nfd:emg110.algo +- **APP**: + + ``` + did:algo:testnet:app:110096026 + did:algo:mainnet:app:350338509 + ``` + +- **UUID**: + + ``` + did:algo:testnet:uuid:c6bc3d9f-3e2c-4170-99e7-b9809f229ecb + did:algo:mainnet:uuid:6ba7b814-9dad-11d1-80b4-00c04fd430c8 + ``` + +- **NFD**: + + ``` + did:algo:nfd:emg110.algo + ``` + +### Appendix B: DID Document Example (Example Data) -``` -### Appendix B: DID document example (example data) ```json { + "@context": ["https://w3id.org/did-resolution/v1"], + "didDocument": { + "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "@context": [ - "https://w3id.org/did-resolution/v1"], - "didDocument": { - "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "@context": [ - "https://www.w3.org/ns/did/v1", - "https://w3id.org/security/suites/ed25519-2020/v1", - "https://w3id.org/security/v1" - ], - "verificationMethod": [ - "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", - { - "controller": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof", - } - ], - "service": [ - { - "id": "did:algo:web:mainnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet:node/", - "extensions": [ - { - "id": "algorand-state-proof", - "version": "1.0.0", - "data": [ - { - - "network": "mainnet", - "hashtype": "sha512_256", - "idx": 12, - "proof": "SGjVwQA4GGhBSfJ1uXJXWk0lNyyk6/Nq3tJI4fHAIWzGarYxDRBllj+gjjTKsPeFuMzuOkVqw58LDrmqucrYU+pbp9laI9DUE1UG7KcUj+QxXqmW/qsaQ+j74hVKMaHSWLxqjcMKUiSORivvBTp8XxFGWgUotwHtgBCQzkJ3MXHF41RA3zvDuluLMtS1diU6FLycYti0QRH9oBS57vcHn82PzPgD+k9rlPoJZY06lRxmz0Zlc1TKNThvqr+1Mu+C", - "stibhash": "ruGptxPK5UiqPM9MuOFk2t7MfOfXsvfGlDnatxDCHb0=", - "treedepth": 6, - "confirmed-round": 34390581, - },{ - - } - ] - } - ] - }, - { - "id": "did:algo:web:mainnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet:idx/", - "extensions": [ - { - "id": "algorand-signature", - "version": "1.0.0", - "data": [ - { - "sig": "ug24mUImTRg8lzjAB8Y/FPzakKYoMwDUl+nVrQHlsUwnnLHipUdjtGV3NG3oVgxbJAgMGUK0exfUY27cePvMAQ==", - "network": "mainnet", - "confirmed-round": 34390581, - } - ] - } - ] - } + "https://www.w3.org/ns/did/v1", + "https://w3id.org/security/suites/ed25519-2020/v1", + "https://w3id.org/security/v1" + ], + "verificationMethod": [ + "did:algo:LP6QRRBRDTDSP4HF7CSPWJV4AG4QWE437OYHGW7K5Y7DETKCSK5H3HCA7Q#auth", + { + "controller": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:algo:mainnet:txn:6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ#stateproof" + } + ], + "service": [ + { + "id": "did:algo:web:mainnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "type": "did.algo.web.ExternalService", + "serviceEndpoint": "https://mainnet:node/", + "extensions": [ + { + "id": "algorand-state-proof", + "version": "1.0.0", + "data": [ + { + "network": "mainnet", + "hashtype": "sha512_256", + "idx": 12, + "proof": "SGjVwQA4GGhBSfJ1uXJXWk0lNyyk6/Nq3tJI4fHAIWzGarYxDRBllj+gjjTKsPeFuMzuOkVqw58LDrmqucrYU+pbp9laI9DUE1UG7KcUj+QxXqmW/qsaQ+j74hVKMaHSWLxqjcMKUiSORivvBTp8XxFGWgUotwHtgBCQzkJ3MXHF41RA3zvDuluLMtS1diU6FLycYti0QRH9oBS57vcHn82PzPgD+k9rlPoJZY06lRxmz0Zlc1TKNThvqr+1Mu+C", + "stibhash": "ruGptxPK5UiqPM9MuOFk2t7MfOfXsvfGlDnatxDCHb0=", + "treedepth": 6, + "confirmed-round": 34390581 + } + ] + } ] - }, - "didDocumentMetadata": { - "created": "2023-03-23T19:15:10Z", - "deactivated": false, - "updated": "2023-03-23T20:11:30Z" - }, - "didResolutionMetadata": { - "contentType": "application/ld+json", - "retrieved": "2023-05-15T17:39:30Z" - } + }, + { + "id": "did:algo:web:mainnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "type": "did.algo.web.ExternalService", + "serviceEndpoint": "https://mainnet:idx/", + "extensions": [ + { + "id": "algorand-signature", + "version": "1.0.0", + "data": [ + { + "sig": "ug24mUImTRg8lzjAB8Y/FPzakKYoMwDUl+nVrQHlsUwnnLHipUdjtGV3NG3oVgxbJAgMGUK0exfUY27cePvMAQ==", + "network": "mainnet", + "confirmed-round": 34390581 + } + ] + } + ] + } + ] + }, + "didDocumentMetadata": { + "created": "2023-03-23T19:15:10Z", + "deactivated": false, + "updated": "2023-03-23T20:11:30Z" + }, + "didResolutionMetadata": { + "contentType": "application/ld+json", + "retrieved": "2023-05-15T17:39:30Z" + } } ``` ## Security Considerations -1. Key Management: Secure management of cryptographic keys used in DID creation and verification is crucial but is out of this ARC scope and goes under Wallet providers concerns! -2. DID Document Integrity: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. -3. Privacy: Considerations around the privacy of DID subjects, especially in relation to transaction histories and public keys. +1. **Key Management**: Secure management of cryptographic keys used in DID creation and verification is crucial but is outside the scope of this ARC and falls under wallet providers' concerns. +2. **DID Document Integrity**: Ensuring the integrity of DID documents stored on or referenced by the Algorand blockchain. +3. **Privacy**: Considerations around the privacy of DID subjects, especially regarding transaction histories and public keys. -Note: The UUID namespace MUST be isolated by network for security reasons! +**Note**: The UUID namespace **MUST** be isolated by network for security reasons. ## 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. +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From 4cd1becfbaa6976f5388672b9bfa711d765beac1 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 7 Nov 2024 15:38:41 +0300 Subject: [PATCH 115/116] Update: Simplification --- ARCs/arc-0013.md | 26 +++++--------------------- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 4d98213be..27cee36ab 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -51,22 +51,6 @@ ARC-13 implementations **MUST** use box storage to store either the byte value o - 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](https://www.rfc-editor.org/rfc/rfc3986). -- Under DID services, Algorand API endpoints can OPTIONALLY use universal naming (Algod, Idx, Kmd) for ease of use and readability: - - ``` - did:algo:web:testnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ - - did:algo:web:testnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ - ``` - - The service endpoint for this OPTIONAL setting should be specified like: - - ``` - "serviceEndpoint": "https://testnet:node/" - "serviceEndpoint": "https://testnet:idx/" - ``` - - When endpoints are used in universal descriptor format, there will be no need to specify the full URL, which may be subject to change from user to user. - **Linked Data** is a way to create a network of standards-based machine-interpretable data across different documents and websites. It allows an application to start at one piece of Linked Data and follow embedded links to other pieces of Linked Data hosted on different sites across the Web. @@ -568,9 +552,9 @@ Examples of DIDs for each Algorand element type for both testnet and mainnet ins ], "service": [ { - "id": "did:algo:web:mainnet:node/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "id": "did:web#/v2/blocks/34390581/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet:node/", + "serviceEndpoint": "https://node/", "extensions": [ { "id": "algorand-state-proof", @@ -590,9 +574,9 @@ Examples of DIDs for each Algorand element type for both testnet and mainnet ins ] }, { - "id": "did:algo:web:mainnet:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", - "type": "did.algo.web.ExternalService", - "serviceEndpoint": "https://mainnet:idx/", + "id": "did:web:idx/v2/transactions/6WKM4ALZ7GOPIJNQOVF4C65LKBVP6EWCXZWJ2ETRMI5OLI63YNEQ", + "type": "did.algo.ExternalService", + "serviceEndpoint": "https://idx/", "extensions": [ { "id": "algorand-signature", From 8f056958b107eea9cf7c80665a2424aafd33a4a8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 7 Nov 2024 15:43:57 +0300 Subject: [PATCH 116/116] Update --- ARCs/arc-0013.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ARCs/arc-0013.md b/ARCs/arc-0013.md index 27cee36ab..a80bc7cc1 100644 --- a/ARCs/arc-0013.md +++ b/ARCs/arc-0013.md @@ -39,7 +39,7 @@ Conventions for DID naming, namespace, ABNF grammar, and DID registry/resolver s ARC-13 proposes two categories of identifiers: - **Elemental**: Algorand element identifiers like transaction IDs, ASA IDs, APP IDs, and account addresses. Elemental DIDs do not need any registry; the decentralized ledger and DID document information are derived from on-chain data. -- **Composed**: Uses UUIDs to register a unique identifier for an Algorand DID used for an external entity. Composed DIDs **MUST** have registry, lifecycle management, and universal resolver implementations or their own. +- **Composed**: Uses UUID V4 as specified in [RFC 4122](https://www.rfc-editor.org/rfc/rfc4122) to register a unique identifier for an Algorand DID used for an external entity. Composed DIDs **MUST** have registry, lifecycle management, and universal resolver implementations or their own. ARC-13 supports both on-chain (**MUST** use box storage) and off-chain (**MUST** use CID Version 1) decentralized storage systems like IPFS, CrustNetwork, etc. @@ -148,12 +148,12 @@ If "addr", "asa", "app", or "txn" namespaces are used, they **MUST** be used wit A DID URL is a network location identifier useful for a specific resource used by an element, which should be one of: -- **NFD** (NFDomains Algorand name service unique names) -- **APP** (Application Identifiers) -- **UUID** (V4) - **ACCOUNT** (EOA) -- **ADDR** (Application escrow address) +- **APP** (Application Identifiers) - **ASA** (Asset Identifiers) +- **ADDR** (Application escrow address) +- **UUID** (UUID V4 as specified in [RFC 4122](https://www.rfc-editor.org/rfc/rfc4122)) +- **NFD** (NFDomains Algorand name service unique names) **NOTE**: Semicolon character **MUST NOT** be used. @@ -351,11 +351,11 @@ The rationale for namespaces includes: For example, resolving chain IDs to chain names has been omitted by not using chain IDs in namespaces, since Algorand does not fork and Algorand chains are standardized. Therefore, there is no need for lower-level roots (e.g., UUID) for Algorand elements like accounts. -**UUID Rationale**: Having UUID as a first-class citizen provides infinite possible scenarios to use and link off-chain/on-chain assets as composed entities. This aligns with Algorand's focus on composability. +**UUID Rationale**: Having UUID as a external resource identifier provides solution scenarios to link off-chain/on-chain assets and resources as composed entities. This aligns with Algorand's focus on composability. **NFD Rationale**: `nfd` is a well-known namespace in Algorand, and `ans` is the standard namespace naming for Algorand Naming Service. -**Note**: Algorand account addresses have no namespace and are considered root namespace under `algo`. +**Note**: Algorand account addresses have no namespace and are considered members of default namespace under `algo` method. ## Reference Implementation