diff --git a/CIP-0010/registry.json b/CIP-0010/registry.json index 3d421a6f06..134759359a 100644 --- a/CIP-0010/registry.json +++ b/CIP-0010/registry.json @@ -154,5 +154,9 @@ { "transaction_metadatum_label": 61286, "description": "CIP-0015 - Catalyst deregistration" - } + }, + { + "transaction_metadatum_label": "????", + "description": "CIP-???? - KERI-backed metadata attestations" + }, ] diff --git a/CIP-????/README.md b/CIP-????/README.md new file mode 100644 index 0000000000..b60cebb3c8 --- /dev/null +++ b/CIP-????/README.md @@ -0,0 +1,391 @@ +--- +CIP: ???? +Title: KERI-backed metadata attestations +Category: Metadata +Status: Proposed +Authors: + - Fergal O'Connor + - Thomas Kammerlocher +Implementors: + - reeve.technology + - veridian.id +Discussions: + - +Created: 2025-11-05 +License: CC-BY-4.0 +--- + +## Abstract + +Accountability is essential for legal entities, organizations, and authorities operating in regulated environments. To establish accountability on the Cardano blockchain, it must be possible to prove the identity of entities responsible for on-chain actions in a verifiable and interoperable way. + +This CIP defines a standardized mechanism to embed KERI ([Key Event Receipt Infrastructure](https://trustoverip.github.io/kswg-keri-specification/)) identifiers within Cardano transaction metadata. KERI provides self-certifying, portable, and decentralized identifiers known as Autonomic Identifiers (AIDs) that can be anchored to various roots of trust—such as verifiable Legal Entity Identifiers (vLEIs), organizational registries, or domain-specific trust frameworks. + +By including KERI identifiers in transaction metadata, Cardano enables a flexible, trust-agnostic approach to identity binding. This approach supports accountability, legal and regulatory compliance, and interoperability with existing and emerging global identity ecosystems, while remaining compatible with self-sovereign identity principles. + +## Motivation: why is this CIP necessary? + +The demand for auditable and verifiable identifiers is increasing as accountability, traceability, and transparency become fundamental requirements for entities operating within regulated environments. Without a standardized mechanism, it is difficult to reliably associate on-chain activity with persistent and legally recognized identities. + +KERI (Key Event Receipt Infrastructure) addresses this challenge by introducing a decentralized, key-oriented identifier system that supports secure, portable, and self-certifying digital identities. Instead of relying on centralized registries, KERI establishes identifiers through cryptographically verifiable event logs, enabling secure key rotation, continuity of control, and tamper-evident auditability. This approach ensures that an identifier can consistently represent the same entity over time, while remaining interoperable with verifiable credentials and roots of trust such as verifiable Legal Entity Identifiers (vLEIs). + +By embedding KERI identifiers into Cardano transaction metadata, this proposal enables a standardized and verifiable linkage between on-chain actions and off-chain accountability frameworks. This allows transactions to be cryptographically bound to a specific identifier and, through verifiable credential chains, to a legally recognized entity, thereby enhancing trust and compliance across decentralized and regulated ecosystems. + + +## Specification + +Below a generic solution is defined to enable metadata signing where a particular ecosystem or use-case may leverage a root of trust of its choosing – each most likely with its own credential chain format. + +The credentials used in the KERI ecosystem are known as ACDCs, or [Authentic Chained Data Containers](https://trustoverip.github.io/kswg-acdc-specification/). This CIP will not explain at depth how KERI and ACDCs work due to their technical complexity. The [Appendix](#appendix) will however include some expanded explanations to help provide clarity. + +> [!NOTE] +> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here. + +### Key Event Log Discovery +In order to verify the validity of credential chains and metadata transactions, Key Event Logs, or KELs, for all issuing and holding identifiers in the credential chain must be made available to a verifier. KELs may live off-chain for interoperability and scalability reasons, so this CIP does not make assumptions on which medium the KELs are published. + +A KERI watcher network SHOULD be used to discover up-to-date KELs for a given identifier for certain security reasons. Discovery of the watcher network relevant to a given ecosystem depends on the ecosystem itself. + +However, as KERI is a maturing technology, wide-spread deployment of watcher networks is not yet guaranteed. Until then, the interim solution is to publish an [Out-of-Band-Introduction](#discovery-via-out-of-band-introductions-oobis) via a known persistent channel for the specific project for discovery, and this may be used by a verifier to discover and query for KEL events and updates. + +In one way or another, chain indexers must query for Key Event Log updates to validate credential chains and metadata transactions during the process of verification. + +### Visualized Identity Lifecycle +The following diagram illustrates the lifecycle of signing authority for a KERI identifier on Cardano. It demonstrates how [attestations](#creation-of-verifiable-records) (`ATTEST`) are invalid before [authority is established](#establishment-of-signing-authority) (`AUTH_BEGIN`), become valid during the authenticated period, and become invalid again after [revocation](#revoking-of-signing-authority) (`AUTH_END`). + +```mermaid +--- +config: + theme: redux +--- +sequenceDiagram + participant Legal Entity as Legal Entity + participant Cardano as Cardano + participant Indexer as Indexer + Legal Entity ->> Cardano: ATTEST + Cardano ->> Indexer: Identity invalid + Note right of Indexer: ❌ No valid credential + Legal Entity ->> Cardano: AUTH_BEGIN + Cardano ->> Indexer: Credential known + Note right of Indexer: ✅ Identifier established + Legal Entity ->> Cardano: ATTEST + Cardano ->> Indexer: Identity verified + Note right of Indexer: ✅ Valid signature + Legal Entity ->> Cardano: AUTH_END + Cardano ->> Indexer: Credential revoked + Note right of Indexer: ⚠️ Identifier revoked + Legal Entity ->> Cardano: ATTEST + Cardano ->> Indexer: Identity invalid + Note right of Indexer: ❌ No valid credential +``` +### Establishment of signing authority +Before attesting to any transactions, the relevant [credential chain](#credential-chains) for the controller must be published on-chain with the following attributes – most of which are used to help simplify indexing: +- **t** — A transaction type of `AUTH_BEGIN` is used to establish a signer’s authority using a credential chain. +- **i** — The identifier of the signer in the CESR qb64 variant. This MUST match the issuee of the leaf credential in the chain. +- **s** — The schema identifier of the leaf credential in the chain in the CESR qb64 variant. This MUST match the schema of the [leaf credential](#identifying-a-credential-chain-type) in the chain. +- **c** — The byte-stream of the credential chain in the CESR qb2 or qb64b variant, for brevity. +- **v** - Version of the CIP and minimum version of KERI and ACDC to ensure compatibility. +- **m** — An optional metadata block used to simplify indexing for a particular use-case. For example, the LEI of a legal entity could be contained here. + +The credential chain should contain all credentials, relevant registry events and attachments. There are various types of ACDC registries, so for simplicity: the credential chain MUST validate with an ACDC v1 or v2 verifier, assuming that KEL events are already available. + +These attributes can be embedded in the metadata of a transaction using a fixed metadata label. Compact field labels are used for brevity. + +The metadata is structured as follows: +```JSON +{ + "????": + { + "t": "AUTH_BEGIN", + "s": "{{saidOfLeafCredentialSchema}}", + "i": "{{aidOfSigner}}", + "c": "{{byteStream}}", + "v": { + "v": "{{CIP Version String}}", + "k": "{{KERI Version String}}", + "a": "{{ACDC Version String}}" + }, + "m": "{{optionalMetadataBlock}}" + } +} +``` +If valid for a given ecosystem, this transaction establishes the signing authority for `i` from this transaction onwards in the chain. The issuance date of the leaf credential SHOULD be ignored. + +### Creation of verifiable records +To create a persistent signature over data with KERI, signers can anchor a digest of the data in their KEL, typically using an interaction event. Anchoring ensures that data remains verifiable even if the controller later rotates their keys. + + The relevant data recorded for each event includes: +- **t** — A transaction type of `ATTEST` is to create a verifiable record. +- **i** — The identifier of the signer in the CESR qb64 variant. +- **d** — The digest of the data being signed in the CESR qb64 variant. +- **s** — The sequence number of the KERI event, encoded as a hex string. +- **v** - Version of the CIP. KERI and ACDC version isn't needed here. +If the KEL of identifier `i` contains an event at sequence number `s` which has a seal value of `{ d: "{{digest}}" }`, it serves as cryptographically verifiable proof that the data was effectively signed by the controller. + +A reference to this event in a metadata transaction is structured as follows: +```JSON +{ + "????": { + "t": "ATTEST", + "i": "{{aidOfSigner}}", + "d": "{{digest}}", + "s": "{{hexEncodedSequenceNumber}}", + "v": { + "v": "{{CIP Version String}}" + }, + }, + "YYYY": "{{someApplicationMetadata}}" +} +``` +Such transactions are only considered valid if the digest value is correct, and can be found anchored in the KEL of the controller at the given sequence number. + +### Revoking of signing authority +Signing authority may be removed after a period of time by revoking the relevant credential and publishing this revocation on-chain. As such, the validity of transactions associated with that credential chain are for all valid `ATTEST` transactions between issuance (`AUTH_BEGIN`) and revocation (`AUTH_END`). + +The following attributes are used: +- **t** — A transaction type of `AUTH_END` is used to remove a signer’s authority with revocation registry events. +- **i** — The identifier of the signer in the CESR qb64 variant. This MUST match the issuee of the leaf credential in the chain. +- **s** — The schema identifier of the leaf credential in the chain in the CESR qb64 variant. This MUST match the schema of the leaf credential in the chain. +- **c** — The byte-stream of the revocation registry events in the CESR qb2 or qb64b variant, for brevity. +- **v** - Version of the CIP and minimum version of KERI and ACDC to ensure compatibility. +- **m** — An optional metadata block used to simplify indexing for a particular use-case. For example, the LEI of a legal entity could be contained here. + +A reference to this event in a metadata transaction is structured as follows: +```JSON +{ + "????": + { + "t": "AUTH_END", + "s": "{{saidOfLeafCredentialSchema}}", + "i": "{{aidOfSigner}}", + "c": "{{byteStream}}", + "v": { + "v": "{{CIP Version String}}", + "k": "{{KERI Version String}}", + "a": "{{ACDC Version String}}" + }, + "m": "{{optionalMetadataBlock}}" + } +} + +``` +If the successful parsing of the revocation events results in a credential chain that no longer gives authority to the signer, any later `ATTEST` transactions for this credential chain should be ignored (unless there is another subsequent `AUTH_START`). + + +## Reference Example - vLEI + +The Global Legal Entity Identifier Foundation (GLEIF) serves as the root of trust for Legal Entity Identifiers (LEIs) worldwide. Their verifiable variant, the vLEI, is based on the KERI and ACDC standards, and are issued by Qualified vLEI Issuers (QVIs). + +Legal entities holding valid vLEI credentials may issue other credentials chained to their vLEI which allows them to delegate authority to other persons or machines. + +As a reference example, we define a `vLEICardanoMetadataSigner` credential. For a given use-case, the issuee of this credential is allowed to sign transaction metadata on Cardano on behalf of a particular legal entity. The LEI of this legal entity is embedded in their Legal Entity vLEI credential. + +```mermaid +graph LR + GLEIF["GLEIF Root
(Root of Trust)"] + QVI["Qualified vLEI Issuer
Credential"] + LE["Legal Entity vLEI
Credential
(contains LEI)"] + SIGNER["Cardano Metadata Signer
Credential
(contains metadata labels)"] + + GLEIF -->|issues| QVI + QVI -->|issues| LE + LE -->|issues| SIGNER + + SIGNER -.->|signs metadata
transactions on| CARDANO["Cardano Blockchain"] + + style GLEIF fill:#e1f5ff,stroke:#0066cc,stroke-width:2px + style QVI fill:#fff4e1,stroke:#cc8800,stroke-width:2px + style LE fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px + style SIGNER fill:#fce4ec,stroke:#c2185b,stroke-width:2px + style CARDANO fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px +``` + +The above diagram contains 3 credentials which are cryptographically chained: +- **Qualified vLEI Issuer**: Issued by GLEIF to QVI entities. +- **Legal Entity vLEI**: Issued by a QVI to legal entities. +- **Cardano Metadata Signer**: Issued by the legal entity to a person or machine who may sign on behalf of the entity. + +The schema for the signer credential may be found here. It contains an attribute `labels` which is an array of metadata label numbers for which the signer has the authority to create verifiable records over. + +### Establishment of signing authority +For this example, a signer controlling the identifier `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` is holding a metadata signer credential valid for label `1447`. + +The following is the expected transaction format to publish the credential chain: +```JSON +{ + "????": + { + "t": "AUTH_BEGIN", + "s": "EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ", + "i": "EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL", + "c": "{{credentialChainByteStream}}", + "v": { + "v": "1.0", + "k": "KERI10", + "a": "ACDC10" + }, + "m": + { + "l": [1447], + "LEI": "50670047U83746F70E20" + } + } +} +``` +For ease of indexing, the metadata block is used to contain the LEI of the legal entity, as well as an array of all relevant metadata labels. As such, an indexer can filter based on interested metadata labels, or based on a particular set of legal entities. + +The credential chain `c` should be a qb2 CESR stream containing: +- Each ACDC credential and corresponding issuance event (`iss`) +- Registry events for each revocation registry (`vcp`) +- All necessary CESR attachments + +A test example may be found [here](example-credential-chain.cesr) in qb64 format - this should be converted to qb2 before being pushed on-chain. + +After verifying the validity of the credential chain with an ACDC verifier, there are a number of extra validation steps to complete as business logic: +1. `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` is the issuee of the metadata signer credential with a schema ID of `EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ`. +2. The label attribute of the credential is `[1447]`. +3. The LEI attribute of the Legal Entity vLEI credential is `50670047U83746F70E20`. +4. The Qualified vLEI Issuer credential is issued by GLEIF’s External identifier - [more information](#root-of-trust-discovery) + +### Creation of verifiable records +The following is an attestation transaction for metadata label `1447`. +```JSON +{ + "XXXX": { + "t": "ATTEST", + "i": "EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL", + "d": "ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux", + "s": "1a", + "v": { + "v": "1.0" + } + }, + "1447": "{{someApplicationMetadata}}" +} +``` + +Validation steps: +1. `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` currently has signing authority over label 1447. +2. The CESR digest of the data at label 1447 is `ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux`. +3. The event in the controller’s KEL at sequence number `1a` (26th event) is `{ d: “ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux” }`. + +### Revoking signing authority + +When a credential must be revoked (for example, due to employee termination, credential compromise, or policy changes) the legal entity publishes an `AUTH_END` transaction containing the revocation registry events. A sample revocation event stream can be found [here](example-revocation-event.cesr). +The following is an example revocation transaction: +```JSON +{ + "????": + { + "t": "AUTH_END", + "s": "EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ", + "i": "EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL", + "c": "{{revocationRegistryEventsByteStream}}", + "v": { + "v": "1.0", + "k": "KERI10", + "a": "ACDC10" + }, + "m": + { + "l": [1447], + "LEI": "50670047U83746F70E20" + } + } +} +``` + +The revocation registry events in `c` should contain the necessary ACDC registry events that mark the credential as revoked. Once processed by the indexer, the following validation logic applies: + +1. The indexer parses the revocation events and validates them against the credential chain. + +If the revocation is valid, the identifier `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` loses signing authority for label `1447` from this transaction forward. Any subsequent `ATTEST` transactions using this identifier will be ignored and treated as unverified. + +For example, if the following transaction appears after revocation: +```JSON +{ + "XXXX": { + "t": "ATTEST", + "i": "EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL", + "d": "ELC5L3iBVD77d_MYbYGGCUQgqQBju1o4x1Ud-z2sL-ux", + "s": "1b", + "v": { + "v": "1.0" + } + }, + "1447": "{{someApplicationMetadata}}" +} +``` + +The indexer will reject this attestation because: +1. The credential chain for `EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL` has been revoked. +2. No valid signing authority exists for this identifier on label `1447`. +3. The transaction is marked as **unverified** and should not be trusted by any application relying on the indexer. + +Only if a new `AUTH_BEGIN` transaction is published with a fresh, valid credential chain would the identifier regain signing authority. + + +## Rationale: how does this CIP achieve its goals? + +This CIP enables entities (including legal entities, organizations, DAOs, and individuals) to cryptographically prove their identity on Cardano by linking verifiable credential chains (such as vLEIs) to on-chain transactions. This connection establishes accountability and transparency, enabling blockchain adoption in highly regulated environments where transactions must be traceable to recognized entities, while also supporting flexible identity frameworks for various use cases beyond traditional corporate structures. + +### Achieving Accountability Through Verifiable Identity + +The core goal of establishing accountability is achieved through several key mechanisms: + +**Persistent Identity Binding**: By anchoring KERI identifiers in transaction metadata, this CIP creates an immutable, publicly auditable link between a transaction and a specific entity. Unlike traditional blockchain addresses which are pseudonymous, KERI identifiers can be verified against credential chains that ultimately connect to legally recognized entities (e.g., through LEIs issued by GLEIF). This transforms anonymous blockchain activity into accountable actions. + +**Temporal Authority Control**: The `AUTH_BEGIN` and `AUTH_END` lifecycle allows precise control over when an identifier has signing authority. This supports real-world scenarios like employee onboarding/offboarding or credential expiration, ensuring that only authorized representatives can act on behalf of an entity at any given time. Indexers can deterministically verify whether any attestation was made during a valid authority period. + +**Multi-Layer Verification**: The credential chain structure enables verification at multiple levels—from cryptographic signature validity, to credential issuance by authorized issuers, to the root of trust (e.g., GLEIF). This layered approach means that breaking accountability would require compromising multiple independent systems, not just a single private key. + +### Design Trade-offs + +The metadata-based approach was chosen for its simplicity and flexibility: + +**Advantages:** +- Straightforward implementation for wallets and transaction builders +- Flexible credential schemas without protocol changes +- Full backward compatibility with existing infrastructure + +**Limitations:** +- Validation must occur off-chain through indexers (smart contracts cannot enforce credential checks) - This limitation can be solved by writing another CIP or extending this +- Requires additional infrastructure (indexers, KERI watcher networks) + +The metadata is immutably recorded on-chain, and anyone can independently verify the cryptographic proofs by validating the credential chains against published Key Event Logs. + +### Cryptographic Trust + +Unlike oracle networks that rely on consensus among multiple nodes, KERI-based verification relies purely on cryptographic signatures and tamper-evident event logs. Verifiers can independently validate credentials without trusting any third party—the only trust assumption is in the root of trust (e.g., GLEIF for vLEIs), which is already established in real-world legal frameworks. + +By adopting KERI, an existing standard from the Trust over IP Foundation, this CIP ensures interoperability across ecosystems, credential portability, and alignment with emerging regulatory requirements for digital identity. This standards-based approach means that implementations can leverage existing tooling, benefit from ongoing security research, and maintain compatibility as the KERI ecosystem evolves. + +## Path to Active + +## Appendix + +### Credential chains + +ACDCs can be chained together cryptographically in a similar manner to traditional X.509 certificate chains, yet with far more power and flexibility. + +For a given ecosystem, there may be a particular credential chain type that can be used to create bindings between controllers and entities or people. For example, in the vLEI ecosystem, credential chains may be used to create a binding between a legal entity and one of its employees that has the authority to sign transactions on its behalf. The root of trust in the vLEI ecosystem is GLEIF. + +### Identifying a credential chain type + +Various credential chain types may represent various forms of compliance or bindings so it's important to be able to differentiate between credential chain types so that chain indexers can more easily filter out irrelevant transactions. + +For this, the schema ID of the leaf credential in the credential chain may be used - that is, the credential which will be held by the person or software attesting to the metadata transaction. This is the strongest indicator of the credential chain type as child credential schemas reference parent credential schemas in a cryptographically strong manner. + +### Discovery via Out-of-Band-Introductions (OOBIs) + +In the context of this CIP, an OOBI provides a mechanism to discover verifiable information related to an identifier at an endpoint, such as the Key Event Log related to that identifier. All data is still verifiably signed, but a watcher network should be used to reduce the risk of discovering a forked, but verifiable version of a KEL. + +### Root of trust discovery + +GLEIF serves as the root of trust in the vLEI ecosystem. Discovery of their GLEIF Root identifier therefore must be carefully managed to avoid a Man-in-the-Middle attack where an attacker redirects a verifier to a different root identifier that is also verifiable. + +GLEIF has published their identifiers in various mediums such as various GitHub organizations, websites and hardcopy publications to mitigate the risk of an attacker compromising each medium, and [here](https://gleif-it.github.io/.well-known/) is one such location. The issuer of production QVI credentials is the GLEIF External, which is delegated from the GLEIF Root. + +## Copyright + +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) \ No newline at end of file diff --git a/CIP-????/example-credential-chain.cesr b/CIP-????/example-credential-chain.cesr new file mode 100644 index 0000000000..3ee78ecafb --- /dev/null +++ b/CIP-????/example-credential-chain.cesr @@ -0,0 +1,133 @@ +{ + "v": "KERI10JSON000113_", + "t": "vcp", + "d": "EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0", + "i": "EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0", + "ii": "EOosFLj1gOfRFEx5g5TSCPdpml9jM9_jIaWI5pZO5YCU", + "s": "0", + "c": [ + "NB" + ], + "bt": "0", + "b": [], + "n": "AFltXlPUmiWy8_v8d9f6jj1E2l7LX1UWjU7hGtrp-1xW" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEKiuK7uqunvbRxirmi9gqfuOGfQSZuqCT9b0WEVFx_Cf +{ + "v": "KERI10JSON000113_", + "t": "vcp", + "d": "EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a", + "i": "EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a", + "ii": "EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS", + "s": "0", + "c": [ + "NB" + ], + "bt": "0", + "b": [], + "n": "AM0aXrE5B79nt1_FOffK7N_rMw1VkYLRe1KB60rwRplM" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEPQN2EE4bNWu6-1vXoLMfTUumlHFEAr9-p4_CeoxfchP +{ + "v": "KERI10JSON000113_", + "t": "vcp", + "d": "EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC", + "i": "EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC", + "ii": "EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l", + "s": "0", + "c": [ + "NB" + ], + "bt": "0", + "b": [], + "n": "AG_SUFGr-Nvk_t1Z7QUAjwsjoFw9GF4tZEt8IcNwrjFe" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAABEFVhm8TjehsDvAJGxlI5ufy_Mxd5j-B1KSqB-YLC1JWV +{ + "v": "KERI10JSON0000ed_", + "t": "iss", + "d": "EOkDhM2BZL2dXuWydnDvIl7kWj5q2bVZXnPNLtr1Wtop", + "i": "EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ", + "s": "0", + "ri": "EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0", + "dt": "2025-11-10T11:43:47.242000+00:00" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEDFK7pUh-Ez7kk0knpLl1m8iA59_BE4_Rkv8QtHMbRuE +{ + "v": "KERI10JSON0000ed_", + "t": "iss", + "d": "ELlER5cq0f8sPsZKjz_jcdegz65uErDiCqfbYlYQHlim", + "i": "EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK", + "s": "0", + "ri": "EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a", + "dt": "2025-11-10T11:43:51.081000+00:00" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEIXsXeDBh9kSbE4pvn3uCPzKxE9Pkg4t-JuRKyLGrUI9 +{ + "v": "KERI10JSON0000ed_", + "t": "iss", + "d": "EOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj", + "i": "EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV", + "s": "0", + "ri": "EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC", + "dt": "2025-11-10T11:43:58.630000+00:00" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAACEFuQPJfiOsO71geAaItT4DGH7xr0ZtaDs8ycsnpxki6k +{ + "v": "ACDC10JSON000197_", + "d": "EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ", + "i": "EOosFLj1gOfRFEx5g5TSCPdpml9jM9_jIaWI5pZO5YCU", + "ri": "EFfQPwW9s8HQV-zq2NTGks_WYT79Z046mhIJwPQxlfn0", + "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao", + "a": { + "d": "EC9iDB-5CIrhu_R68eXQ9HgDT_vxTqSPZXU-TPVzr6-F", + "i": "EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS", + "dt": "2025-11-10T11:43:47.242000+00:00", + "LEI": "50670047U83746F70E20" + } +}-IABEIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ0AAAAAAAAAAAAAAAAAAAAAAAEOkDhM2BZL2dXuWydnDvIl7kWj5q2bVZXnPNLtr1Wtop +{ + "v": "ACDC10JSON0005c8_", + "d": "EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK", + "i": "EARtegK3M61uNJ5wyuznNjngYP0kJm1-KHv5fh-8UFWS", + "ri": "EOzV2Oj64Wwe9QetkB_FCmIvoTI_6OKn7nB4W51wJQ-a", + "s": "ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY", + "a": { + "d": "EB9PCr5APfA1o9LRkO45kijrvoQuH1N5Te4U5JhjpzOO", + "i": "EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l", + "dt": "2025-11-10T11:43:51.081000+00:00", + "LEI": "50670047U83746F70E20" + }, + "e": { + "d": "EC4U5Yxjv1TbJm6fVwi9b_mPr1kpqyv0EQM9Gb0AKDz8", + "qvi": { + "n": "EIUaX_JLblNtJQQg0gh7Ka4h64gbwOhqlPl9QC-7M6DZ", + "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao" + } + }, + "r": { + "d": "EGZ97EjPSINR-O-KHDN_uw4fdrTxeuRXrqT5ZHHQJujQ", + "usageDisclaimer": { + "l": "Usage of a valid, unexpired, and non-revoked vLEI Credential, as defined in the associated Ecosystem Governance Framework, does not assert that the Legal Entity is trustworthy, honest, reputable in its business dealings, safe to do business with, or compliant with any laws or that an implied or expressly intended purpose will be fulfilled." + }, + "issuanceDisclaimer": { + "l": "All information in a valid, unexpired, and non-revoked vLEI Credential, as defined in the associated Ecosystem Governance Framework, is accurate as of the date the validation process was complete. The vLEI Credential has been issued to the legal entity or person named in the vLEI Credential as the subject; and the qualified vLEI Issuer exercised reasonable care to perform the validation process set forth in the vLEI Ecosystem Governance Framework." + } + } +}-IABEBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK0AAAAAAAAAAAAAAAAAAAAAAAELlER5cq0f8sPsZKjz_jcdegz65uErDiCqfbYlYQHlim +{ + "v": "ACDC10JSON000230_", + "d": "EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV", + "i": "EF--c3_VLg-aaoI-y9kKc0XSQD2-bZoiyk0U7Vym9p-l", + "ri": "EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC", + "s": "EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ", + "a": { + "d": "EKGU79bIkzxFsr-ZcoOLyZyX5mD4ScRbylGNNVbeiOW3", + "i": "EKtQ1lymrnrh3qv5S18PBzQ7ukHGFJ7EXkH7B22XEMIL", + "dt": "2025-11-10T11:43:58.630000+00:00", + "labels": [ + 1447 + ] + }, + "e": { + "d": "EPvTf6H9kJBJ87jDXR-IM-jSwWoGwQ_AhuwnIpq0lhqG", + "le": { + "n": "EBK-BG-8-ZhvQ7ml52PWOVJn30IUviSeC7VepeU_mZXK", + "s": "ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY" + } + } +}-IABEPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV0AAAAAAAAAAAAAAAAAAAAAAAEOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj \ No newline at end of file diff --git a/CIP-????/example-revocation-event.cesr b/CIP-????/example-revocation-event.cesr new file mode 100644 index 0000000000..e9fe242c10 --- /dev/null +++ b/CIP-????/example-revocation-event.cesr @@ -0,0 +1,10 @@ +{ + "v": "KERI10JSON000120_", + "t": "rev", + "d": "EIYQA02v1cjNrPn1KhIZXof56LRLmCNPWnaeSyZ87KeU", + "i": "EPSkZ1-E6ojESV9mt20vA0YUfoYAD8dxYyn4-ochHMtV", + "s": "1", + "ri": "EOWTJBCuCpDtamFQrepwyC2WwbsOzWIP0fhRnT8eZeLC", + "p": "EOyo58VXZv4qVVs8jczoTmFlwffJDC8yirqpqecFW3jj", + "dt": "2025-11-10T13:00:40.243000+00:00" +}-VAS-GAB0AAAAAAAAAAAAAAAAAAAAAADEDNyGD0Vt0UgfX3NZuf3JhHY34kTzxGZfhApeISBCBUI \ No newline at end of file diff --git a/CIP-????/version_1.cddl b/CIP-????/version_1.cddl new file mode 100644 index 0000000000..825b1942dc --- /dev/null +++ b/CIP-????/version_1.cddl @@ -0,0 +1,35 @@ +cardano_keri_metadata = { + ? uint => auth_event +} + +auth_event = + auth_begin / + auth_end / + attest + +auth_begin = { + t: "AUTH_BEGIN", + s: text, ; SAID of leaf credential schema + i: text, ; AID of signer + c: bytes, ; Byte stream payload + ? m: metadata_map ; Optional metadata +} + +attest = { + t: "ATTEST", + i: text, ; AID of signer + d: text, ; Digest + s: text ; Hex-encoded sequence number +} + +auth_end = { + t: "AUTH_END", + s: text, ; SAID of leaf credential schema + i: text, ; AID of signer + c: bytes, ; Byte stream payload + ? m: metadata_map ; Optional metadata +} + +metadata_map = { + * text => any +} diff --git a/CIP-????/version_1.json b/CIP-????/version_1.json new file mode 100644 index 0000000000..e53bdb50c4 --- /dev/null +++ b/CIP-????/version_1.json @@ -0,0 +1,106 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "title": "Cardano KERI Accountability Metadata", + "description": "Metadata schema for embedding KERI identifiers and authentication events (AUTH_BEGIN, ATTEST, AUTH_END) within Cardano transactions.", + "type": "object", + "patternProperties": { + "^[0-9]+$": { + "description": "Metadata label key (integer as string).", + "oneOf": [ + { + "type": "object", + "properties": { + "t": { + "const": "AUTH_BEGIN" + }, + "s": { + "type": "string", + "description": "Self-addressing identifier (SAID) of the leaf credential schema." + }, + "i": { + "type": "string", + "description": "Autonomic Identifier (AID) of the signer." + }, + "c": { + "type": "string", + "description": "Byte stream representing the credential or context." + }, + "m": { + "type": "object", + "description": "Optional metadata block.", + "additionalProperties": true + } + }, + "required": [ + "t", + "s", + "i", + "c" + ], + "additionalProperties": false + }, + { + "type": "object", + "properties": { + "t": { + "const": "ATTEST" + }, + "i": { + "type": "string", + "description": "Autonomic Identifier (AID) of the signer." + }, + "d": { + "type": "string", + "description": "Digest referencing the authenticated data." + }, + "s": { + "type": "string", + "pattern": "^[0-9A-Fa-f]+$", + "description": "Hex-encoded sequence number." + } + }, + "required": [ + "t", + "i", + "d", + "s" + ], + "additionalProperties": false + }, + { + "type": "object", + "properties": { + "t": { + "const": "AUTH_END" + }, + "s": { + "type": "string", + "description": "Self-addressing identifier (SAID) of the leaf credential schema." + }, + "i": { + "type": "string", + "description": "Autonomic Identifier (AID) of the signer." + }, + "c": { + "type": "string", + "description": "Byte stream representing the credential or closing context." + }, + "m": { + "type": "object", + "description": "Optional metadata block.", + "additionalProperties": true + } + }, + "required": [ + "t", + "s", + "i", + "c" + ], + "additionalProperties": false + } + ] + } + }, + "additionalProperties": false +} \ No newline at end of file diff --git a/CIP-????/vlei-cardano-metadata-signer-credential.json b/CIP-????/vlei-cardano-metadata-signer-credential.json new file mode 100644 index 0000000000..6608e1dcc5 --- /dev/null +++ b/CIP-????/vlei-cardano-metadata-signer-credential.json @@ -0,0 +1,126 @@ +{ + "$id": "EJVgEQO8BEhGGM7GcAjlqoKG1upeuBZj9WjvjZo353sQ", + "$schema": "http://json-schema.org/draft-07/schema#", + "title": "vLEI Cardano Metadata Signer Credential", + "description": "A vLEI Cardano Metadata Signer Credential issued to a person or machine which may sign metadata embedded in Cardano transactions on behalf of a Legal Entity", + "type": "object", + "credentialType": "vLEICardanoMetadataSignerCredential", + "version": "1.0.0", + "properties": { + "v": { + "description": "Version", + "type": "string" + }, + "d": { + "description": "Credential SAID", + "type": "string" + }, + "i": { + "description": "Issuer AID", + "type": "string" + }, + "ri": { + "description": "Credential status registry", + "type": "string" + }, + "s": { + "description": "Schema SAID", + "type": "string" + }, + "a": { + "oneOf": [ + { + "description": "Attributes block SAID", + "type": "string" + }, + { + "$id": "EBCRiKplQ_uucawOH7lVt0PErQs_9Y2coohaC12zy8f3", + "description": "Attributes block", + "type": "object", + "properties": { + "d": { + "description": "Attributes block SAID", + "type": "string" + }, + "i": { + "description": "Issuee AID", + "type": "string" + }, + "dt": { + "description": "Issuance date time", + "type": "string", + "format": "date-time" + }, + "labels": { + "description": "Array of metadata labels that can be signed", + "type": "array", + "items": { + "type": "number" + } + } + }, + "additionalProperties": false, + "required": [ + "i", + "dt", + "labels" + ] + } + ] + }, + "e": { + "oneOf": [ + { + "description": "Edges block SAID", + "type": "string" + }, + { + "$id": "EHeZGaLBhCc_-sAcyAEgFFeCkxgnqCubPOBuEvoh9jHX", + "description": "Edges block for issuance from Legal Entity", + "type": "object", + "properties": { + "d": { + "description": "SAID of edges block", + "type": "string" + }, + "le": { + "description": "Chain to legal entity vLEI credential", + "type": "object", + "properties": { + "n": { + "description": "SAID of the ACDC to which the edge connects", + "type": "string" + }, + "s": { + "description": "SAID of required schema of the credential pointed to by this node", + "type": "string", + "const": "ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY" + } + }, + "additionalProperties": false, + "required": [ + "n", + "s" + ] + } + }, + "additionalProperties": false, + "required": [ + "d", + "le" + ] + } + ] + } + }, + "additionalProperties": false, + "required": [ + "v", + "i", + "ri", + "s", + "d", + "a", + "e" + ] +} \ No newline at end of file diff --git a/CPS-????/README.md b/CPS-????/README.md new file mode 100644 index 0000000000..01a15257e6 --- /dev/null +++ b/CPS-????/README.md @@ -0,0 +1,62 @@ +--- +CPS: ???? +Title: Linking Off-Chain Identities +Status: Open +Category: Tools +Authors: + - Thomas Kammerlocher + - Fergal O'Connor + - Roberto C. Morano +Proposed Solutions: [] +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/1059 +Created: 2025-07-09 +License: Apache-2.0 +--- + +## Abstract + +Transactions often involve multiple parties, including individuals and organisations. +To facilitate these interactions, it is essential to have a reliable way to verify the identities of participants. +Most of the organisations have off-chain identities, which they could leverage to enhance the trust and security of their on-chain transactions. +Off-chain identities could be solutions like: [GLEIF](https://www.gleif.org/en), [KERI Identifiers](https://identity.foundation/keri/), ... +While Cardano's on-chain data model provides a robust framework for transaction verification, it lacks a standardized mechanism for off-chain identity verification. + +This limitation makes it difficult to verify the identity of participants, establish trust, and comply with regulatory requirements. +This problem statement outlines the need for a standardized solution for off-chain identity verification on Cardano to enhance trust, security, and adoption. + +## Problem + +The core problem is the absence of a standardized, self-sustaining and user-friendly solution for linking decentralized off-chain identifiers to on-chain transaction on the Cardano blockchain. +This gap creates several challenges: +- **Trust and Security**: Without a reliable way to verify identities, it is difficult to establish trust between parties involved in transactions. This can lead to fraud, manipulation, and other security issues. +- **Compliance**: Many industries require strict compliance with regulations related to identity verification. The lack of a standardized solution makes it challenging for businesses and organizations to meet these requirements. +- **User Experience**: Current solutions for off-chain identity verification are often fragmented and complex, leading to a poor user experience. Making it impossible for others to integrate these solutions e.g. explorers + +## Use cases +The need for a standardized solution for decentralized off-chain identity verification on Cardano is driven by several use cases, including: +- **Accountability**: When publishing financial reports, it is essential to verify the identity of the individuals or organizations responsible for the report. This helps to ensure that the information is accurate and trustworthy. +- **Supply Chain Tracking**: In supply chain, parties involved in the process need to verify the identity of each other to ensure that the products are genuine and meet quality standards. + This is particularly important in industries such as pharmaceuticals, where counterfeit products can have serious consequences. +- **Verifying governance actors**: In decentralized governance systems, it is crucial to verify the identity of participants to ensure that decisions are made by legitimate actors. + This helps to prevent manipulation and ensures that the governance process is transparent and accountable. + +## Goals + +The goal of this problem statement is to initiate a discussion within the Cardano community about the need for a standardized framework for off-chain identity verification. +The ultimate objective is to develop a solution that: +- **Is secure and trustworthy**: The solution should provide a high degree of security and be resistant to fraud and manipulation. +- **Is self-sustaining**: The solution should be able to operate independently of any single entity or organization, ensuring decentralization and resilience. +- **Is interoperable**: The solution should be compatible with a wide range of applications and services. (For example easy to integrate into existing solutions, like explorers, wallets, and dApps.) +- **Is compliant with regulations**: The solution should help businesses and organizations to comply with relevant regulations. + +The solution should be able to handle different types of identify solutions, so it shouldn't be tied to a specific identity solution, but rather provide a framework for integrating different solutions. + +## Open Questions +1. How to verify the identity of participants in a decentralized manner? +2. How manage the lifecycle of off-chain identities, including creation, update, and revocation? +3. What is the right on-chain anchor for identity: metadata, an NFT, or something else? + +## Copyright + +This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0).