Specification version: 0.1 (Working Draft) Publication date: 2026-07-01 Canonical URL (planned): https://spec.attestto.com/ieal Editors: Eduardo Chongkan (Attestto) License: Specification text is licensed under Creative Commons Attribution 4.0 International (CC-BY 4.0). Accompanying reference code, JSON Schemas, and examples are licensed under Apache License 2.0. Repository (planned): https://github.com/attestto/spec-ieal
This specification defines the Identity Evidence Assurance Level (IEAL), a compositional model for classifying identity evidence artifacts across three orthogonal axes: Capture, Algorithm, and Storage. A composite IEAL level (L0 through L6) represents the assurance strength of an identity evidence artifact and is intended to be included as a claim in W3C Verifiable Credentials or equivalent identity assertions.
IEAL is designed as implementation guidance for the identity-assurance controls in NIST Special Publication 800-63-4 in architectures that are local-first, device-attested, and require per-event user consent. IEAL extends and operationalizes NIST 800-63; it does not replace or compete with it.
This specification is carrier-agnostic. IEAL claims MAY be carried in W3C Verifiable Credentials (VC-JWT, SD-JWT), IETF COSE-signed objects, embedded metadata in existing document containers (PDF signature dictionaries, C2PA manifests), or a standalone envelope. Carrier-specific encoding rules are defined in separate specifications and are not part of the IEAL core.
This document is a Working Draft (v0.1) published for public review, peer critique, and standards-body engagement. It is not a final specification. Breaking changes may occur before v1.0.
Feedback is welcomed through:
The specification will progress through community review before consideration by any formal standards-development organization.
Relationship to other Attestto specifications:
did:pki (spec.attestto.com/did-pki) — DID method for CA-hierarchy trust anchorsdid:sns (spec.attestto.com/did-sns) — DID method for Solana Name Service bindingsAppendix A. Crosswalks to related standards Appendix B. JSON Schema for the IEAL claim Appendix C. Example IEAL claims
References
Identity evidence artifacts, such as government-issued credentials, biometric captures, and signed attestations, vary widely in the assurance they provide. A photograph of a document captured through an unattested browser is not equivalent to a captured document verified through a hardware-attested mobile device using an ISO/IEC 30107-3-certified presentation-attack-detection algorithm and stored in a hardware-protected key store.
Existing standards define assurance levels for specific pieces of this chain. NIST SP 800-63-4 defines Identity Assurance Levels (IAL) for enrollment and identity proofing. ISO/IEC 30107-3 defines Presentation Attack Detection (PAD) levels for biometric anti-spoofing. Neither standard describes a compositional model that spans capture, algorithm, and storage as separable axes.
IEAL fills this gap. It defines a composable model that:
NIST Special Publication 800-63-4 was finalized on 2025-07-31. Its §2.4 introduces the Subscriber-Controlled Wallet model (Figure 5): a credential service provider issues attribute bundles, the subscriber holds and presents them from a wallet under their control, and a relying party verifies. IEAL is designed to fit inside that model. IEAL fills the specification whitespace that NIST leaves to implementer policy:
ProofBios), which requires conformance to ISO/IEC 30107-3:2023 and an IAPAR below 0.07.Attribute-bundle formats named in NIST SP 800-63C §3.12.1 (W3C Verifiable Credentials, SD-JWT, ISO/IEC 18013-5 mDoc) are all acceptable carriers for IEAL claims. See Section 9.
Composite IEAL levels L4, L5, and L6 approximate NIST IAL2, IAL2 with additional controls, and a subset of IAL3 controls, respectively. A separate crosswalk document (see Appendix A) provides the detailed mapping. That crosswalk is informational; it is not endorsed by NIST and does not constitute a certification claim.
IEAL does not replace or compete with NIST SP 800-63-4.
This specification defines:
This specification classifies single capture events. Session-based assurance, where a sequence of IEAL claims is produced over a continuous verification session (for example, in remote-proctoring workflows or multi-party signing ceremonies), is out of scope for this version and MAY be addressed in a future revision. Verifiers MAY define session policies over multiple IEAL claims.
This specification does not:
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals.
Identity evidence artifact A digital artifact that carries a claim about a subject’s identity, together with cryptographic evidence supporting that claim. Examples include a captured government-issued credential, a biometric-liveness attestation, or a signed presentation of a Verifiable Credential.
Capture The process by which the digital representation of an identity evidence artifact enters the system. Captures include, for example, taking a photograph of a document, recording a video of a presentation attack detection challenge, or reading a chip on an ICAO 9303 travel document.
Capture attestation A cryptographic attestation, produced by a platform or hardware component, that asserts properties of the environment in which a capture was performed. Examples include Play Integrity API attestation, Apple App Attest and DeviceCheck, and FIDO CTAP2 authenticator attestation.
Algorithm The set of computational procedures applied to a capture to detect presentation attacks, verify liveness, or otherwise assess whether the capture faithfully represents the subject at the time of capture.
Presentation attack detection (PAD) As defined in ISO/IEC 30107-3, the automated determination of a presentation attack. Certified PAD levels (L1, L2) are assessed by iBeta Quality Assurance and other NVLAP-accredited biometric testing laboratories.
Storage The mechanism by which the resulting identity evidence artifact (including any witness data such as encrypted video, biometric templates, or capture attestations) is retained and access-controlled after capture.
Witness Retained evidence associated with an identity evidence artifact that supports post-hoc verification. Examples include a short encrypted video of a liveness challenge, a signed attestation blob from the capture platform, or a biometric template.
Witness commitment A cryptographic hash of the witness that is included in the identity evidence artifact and permits verification that a later-produced witness has not been substituted.
Composite IEAL level The overall assurance level (L0 through L6) assigned to an identity evidence artifact, derived from the artifact’s values on the Capture, Algorithm, and Storage axes.
Verifier A party that consumes an identity evidence artifact to make an authorization or trust decision.
Verifier policy A rule set, published or enforced by a verifier, specifying the minimum IEAL level required to authorize a given operation.
Carrier The concrete on-the-wire representation of an identity evidence artifact. Carriers include W3C Verifiable Credentials (VC-JWT, SD-JWT), IETF COSE objects, embedded metadata in existing document containers, and standalone envelopes.
IEAL classifies identity evidence artifacts across three orthogonal axes. Each axis represents a distinct concern and is defined by an ordered enumeration of values.
Each axis is defined in Sections 4, 5, and 6, respectively. The composite level L0 through L6 is defined in Section 7 by combining axis values.
The three axes are orthogonal by design. An implementation MAY improve its Storage assurance without changing its Capture or Algorithm assurance. Verifiers MAY require different minima on different axes for different operations.
Nothing in this specification requires that all three axes reach the same level. Composite level assignment (Section 7) is defined for the useful combinations only. Combinations not listed in Section 7 are undefined for this version of the specification.
The Capture axis describes the environment in which the identity evidence was captured and the strength of any cryptographic attestation over that environment.
C0 — Untrusted client Capture was performed on a client whose environment cannot be cryptographically attested. Examples include browser access from a desktop or laptop with no hardware attestation, and native mobile applications without platform attestation. Producers MUST treat C0 captures as susceptible to camera-injection attacks, virtual-camera drivers, and screen-replay attacks.
C1 — Software-attested mobile Capture was performed on a mobile device, and the capture session was bound to a platform-level attestation issued by the operating system vendor. On Android platforms, this attestation SHOULD be a Play Integrity API response containing at minimum a MEETS_BASIC_INTEGRITY verdict. On iOS platforms, this attestation SHOULD be an App Attest assertion. In both cases, the attestation MUST be bound to a session nonce generated by the producer.
C2 — Hardware-attested mobile As C1, with the additional requirement that the attestation MUST bind a hardware-protected key. On Android, the Play Integrity response MUST contain a MEETS_STRONG_INTEGRITY verdict and the attested key MUST reside in StrongBox or an equivalent hardware-backed key store. On iOS, the App Attest attestation MUST bind a key held in the Secure Enclave.
Producers MUST record the Capture axis value in the IEAL claim. Producers that assert C1 or C2 MUST include the raw attestation object (or a verifiable reference to it) in the IEAL claim.
Verifiers that consume C1 or C2 assertions MUST verify the platform attestation against the OS vendor’s public keys and the session nonce. Verifiers MUST reject assertions whose attestations do not verify or whose nonces do not match the presented artifact.
The Algorithm axis describes the presentation-attack-detection or liveness-verification algorithm applied to the capture.
A0 — None No presentation attack detection or liveness verification was performed.
A1 — Active challenge (basic) An active liveness challenge was performed, such as a scripted pose sequence, a blink prompt, or a randomized head-movement request. The algorithm MAY rely solely on landmark-based movement detection without additional anti-spoof measures. The Attestto reference implementation attestto-active-5pose at algorithm version 1 is an example of an A1 implementation.
A2 — Active challenge (hardened) As A1, with additional anti-spoof measures. Implementations at A2 MUST include at minimum:
A3 — PAD Level 1 The algorithm has been formally certified under ISO/IEC 30107-3 Presentation Attack Detection Level 1 by an iBeta Quality Assurance or other NVLAP-accredited biometric testing laboratory. The certification MUST be currently valid at the time of capture.
A4 — PAD Level 2 As A3, at Presentation Attack Detection Level 2.
Producers MUST record the Algorithm axis value in the IEAL claim, the algorithm identifier and version, and, where applicable, the vendor identifier and the current PAD certification identifier.
Producers asserting A3 or A4 MUST NOT claim these levels unless the specific algorithm version deployed at the time of capture holds the corresponding PAD certification. Producers MUST NOT self-certify PAD levels.
Verifiers that consume A3 or A4 assertions SHOULD verify the referenced PAD certification against the certifying laboratory’s public register. Verifiers MAY treat a PAD certification that has expired between capture and verification as reduced-assurance.
The Storage axis describes how the resulting identity evidence artifact and any associated witness are retained and access-controlled.
S0 — None No witness is retained beyond the identity evidence artifact itself. The artifact carries a claim of capture and algorithm processing but no post-hoc verifiable witness.
S1 — Operating-system-managed secret store The witness (or the key encrypting the witness) is stored in an operating-system-managed secret store such as the macOS Keychain, Windows Data Protection API (DPAPI), or a compliant Linux Secret Service implementation. Access to the witness MUST require an operating-system-mediated authorization event (for example, Touch ID, Windows Hello, or an equivalent).
S2 — Hardware-protected key store As S1, with the additional requirement that the encryption key protecting the witness MUST reside in a hardware-protected key store. Examples include the Apple Secure Enclave accessed via Keychain access-control-list constraints, Android StrongBox, and Windows Trusted Platform Module 2.0 bound keys.
S3 — External hardware token The key protecting the witness MUST be held on an external hardware security token, such as a FIDO2 security key with a hmac-secret extension, a smart card, or an equivalent hardware token. Witness access requires physical possession of the token and user verification on the token.
S4 — Multi-party recovery Witness release requires threshold multi-party approval. Implementations at S4 MUST use a verifiable secret-sharing scheme (for example, Shamir Secret Sharing with an M-of-N threshold where N is at least 3 and M is at most N minus 1) or an equivalent threshold-cryptography construction. Additional operation-specific co-signatures MAY be required by verifier policy (see Section 10).
Storage of an identity evidence artifact is not required to be a single location. Producers and verifiers MAY jointly hold copies of an artifact under the following model:
Producers implementing dual storage MUST record all storage locations in the IEAL claim and MUST record the same Storage axis value for the primary and each derivative copy.
Witness retention duration is a matter of verifier or subject policy and is not fixed by this specification. Deletion of a witness after retention expiry MUST be cryptographically effective: the witness plaintext and the key material used to encrypt the witness MUST both be destroyed such that the witness cannot be reconstructed. The identity evidence artifact and its witness commitment MAY remain valid for post-deletion verification of the fact that a witness existed, while forensic replay of the witness itself is no longer possible.
Producers MUST record the Storage axis value in the IEAL claim and MUST record the witness commitment, the encryption algorithm identifier, and the intended retention duration.
Verifiers MAY require a specific Storage axis minimum as part of their policy. Verifiers that require access to the witness for auditing purposes MUST use the access-request protocol referenced in Section 6.2 and MUST NOT assume unilateral access to the witness plaintext.
Composite IEAL levels L0 through L6 are assigned by combining values from the three axes as follows.
| Composite | Capture | Algorithm | Storage | Approximate NIST IAL correspondence |
|---|---|---|---|---|
| L0 | C0 | A0 | S0 | Below IAL1 |
| L1 | C0 | A1 | S1 | Approximately IAL1 |
| L2 | C0 | A2 | S2 | Between IAL1 and IAL2 |
| L3 | C1 or C2 | A2 | S2 | Approaching IAL2 |
| L4 | C1 or C2 | A3 | S2 | IAL2 |
| L5 | C1 or C2 | A4 | S2 | IAL2 with additional controls |
| L6 | C2 | A4 | S2 and S3 required, S4 required for release | Subset of IAL3 controls |
The NIST correspondence column is informational. A separate crosswalk document (see Appendix A) provides the detailed mapping and disclaimers. Composite IEAL levels are Attestto’s specification and do not constitute NIST certification claims.
Combinations not listed are undefined for this version. A producer MUST NOT assert a composite IEAL level for an artifact whose axis values do not match one of the rows above. Producers MAY, however, record axis values without asserting a composite level; verifiers MAY then apply their own composition policy.
L6 additional constraints:
The IEAL claim is a JSON object suitable for inclusion in a W3C Verifiable Credential evidence array, an equivalent claim in a SD-JWT or COSE-signed object, or an embedded metadata field in a document-container carrier.
| Field | Cardinality | Type | Description |
|---|---|---|---|
type |
1 | string array | MUST include "IdentityEvidenceAssurance" |
ieal |
1 | string | Composite level, one of "L0" through "L6" |
capture |
1 | object | Capture axis details, see 8.2 |
algorithm |
1 | object | Algorithm axis details, see 8.3 |
storage |
1 | object | Storage axis details, see 8.4 |
capturedAt |
1 | string | ISO 8601 timestamp of the capture |
producer |
1 | object | Producer identity and signature, see 8.5 |
capture object| Field | Cardinality | Type | Description |
|---|---|---|---|
axisValue |
1 | string | One of "C0", "C1", "C2" |
platform |
0..1 | string | "android", "ios", "web", or an equivalent identifier |
attestation |
0..1 | string | Base64-encoded attestation object (required for C1 and C2) |
attestationType |
0..1 | string | "play-integrity", "app-attest", or an equivalent identifier |
nonce |
0..1 | string | Session nonce bound to the attestation (required for C1 and C2) |
algorithm object| Field | Cardinality | Type | Description |
|---|---|---|---|
axisValue |
1 | string | One of "A0", "A1", "A2", "A3", "A4" |
name |
1 | string | Algorithm identifier (for example, "attestto-active-5pose") |
version |
1 | string | Algorithm version (SemVer) |
vendor |
0..1 | string | Vendor identifier (for A3 and A4) |
padCertification |
0..1 | object | PAD certification reference (required for A3 and A4) |
score |
0..1 | number | Algorithm-reported confidence (0.0 to 1.0) |
threshold |
0..1 | number | Threshold applied by the producer (0.0 to 1.0) |
storage object| Field | Cardinality | Type | Description |
|---|---|---|---|
axisValue |
1 | string | One of "S0", "S1", "S2", "S3", "S4" |
witnessCommitment |
0..1 | string | Hash of the witness (required for S1 and above) |
witnessHashAlgorithm |
0..1 | string | Hash algorithm identifier (for example, "sha-256") |
witnessEncryptionAlgorithm |
0..1 | string | Encryption algorithm identifier |
witnessRetention |
0..1 | string | ISO 8601 duration or the token "user-controlled" |
locations |
0..* | object array | Storage location descriptors (see 6.2) |
producer object| Field | Cardinality | Type | Description |
|---|---|---|---|
id |
1 | string | Producer DID |
signature |
1 | string | Detached signature over the canonical serialization of the IEAL claim |
signatureAlgorithm |
1 | string | Signature algorithm identifier (for example, "Ed25519") |
Producers MUST sign the IEAL claim. The signature MUST cover the canonical JSON serialization of the claim excluding the signature field itself.
An informative example is provided in Appendix C.
IEAL claims are carrier-agnostic. A carrier is the concrete on-the-wire representation of an identity evidence artifact. This specification RECOMMENDS carriers in the following order of preference, but does not require any specific carrier.
Where the identity evidence artifact is associated with an existing document container (for example, a signed PDF, a photograph, a video recording of a notarial act), producers SHOULD embed the IEAL claim inside that container using the container’s native metadata mechanism. Examples:
Embed-first carriers preserve the original document container. Recipients MAY open the document with any conforming viewer without additional software, and MAY verify the IEAL claim with an IEAL-aware verifier.
Where the identity evidence artifact is a standalone credential (for example, a professional-license attestation or a biometric-verification result with no host document), producers SHOULD carry the IEAL claim as an entry in the evidence array of a W3C Verifiable Credential per the W3C VC Data Model 2.0.
Producers MAY use either JSON-LD, VC-JWT (per RFC 7519), SD-JWT (per current IETF drafts), or COSE-signed (per RFC 8152) serializations. Selection is at producer discretion.
Where neither an existing document container nor a VC representation is appropriate, producers MAY use a standalone envelope. Carrier-specific encoding rules for such an envelope are defined in a separate specification and are not part of this document.
Conforming verifiers MUST accept IEAL claims in at least the embed-first and W3C Verifiable Credential carriers. Conforming verifiers SHOULD accept the standalone envelope where a corresponding profile is published.
Verifiers publish per-operation IEAL floors. This section defines conventions for such policies. The specific values below are illustrative examples and not normative requirements.
| Operation | Illustrative IEAL floor | Rationale |
|---|---|---|
| Read a credential held by the subject | L0 | The subject owns the credential |
| Present a credential to a verifier | L1 | Basic identity presence |
| Sign a personal document (non-notarial) | L2 | Reasonable friction proportionate to the operation |
| Present a government-issued national identity credential | L3 | Ties presentation to an attested device |
| Sign a notarial act | L5 | Notary law requires strong assurance |
| Approve a high-value financial transaction | L5 or higher | Financial threshold |
| Approve a fiduciary or patron-tier operation | L6 | Multi-party assurance |
Verifiers SHOULD publish their per-operation IEAL floor policies in machine-readable form so that producers can select the appropriate IEAL target before capture rather than after.
Verifiers MAY require different IEAL floors for the same operation under different risk contexts (for example, a higher IEAL floor for a first-time counterparty or for a transaction that exceeds a value threshold). Adaptive-assurance policies are out of scope for this specification but are complementary to it.
This specification is vendor-neutral. Any provider meeting the axis criteria defined in Sections 4, 5, and 6 MAY satisfy an IEAL axis value. Attestto does not endorse, prefer, or receive compensation from any specific vendor for inclusion in this specification.
For the current list of qualifying vendors on the Algorithm axis at PAD Level 1 or PAD Level 2, consult the iBeta Quality Assurance public register and other NVLAP-accredited biometric testing laboratories. Attestto does not maintain a separate vendor list.
Formal Attestto integration partnerships, if any exist, are publicly disclosed at attestto.com/partners.
A conforming producer MUST:
A conforming verifier MUST:
A conforming verifier SHOULD:
Capture-injection resistance. Capture axis value C0 provides no protection against camera-injection attacks, virtual-camera drivers, USB HDMI capture devices, or real-time deepfake injection. Producers relying on C0 for high-assurance operations MUST NOT do so.
PAD algorithm currency. Presentation attack detection algorithms are the target of continuous research and the effectiveness of a specific algorithm may decrease over time as new attacks emerge. Producers and verifiers SHOULD treat PAD certifications as time-limited and MAY require re-certification within a validity window.
Nonce binding. Platform attestations (Play Integrity, App Attest) that are not bound to a producer-generated nonce may be replayed. Producers MUST generate a fresh nonce per capture session and MUST verify the nonce is embedded in the returned attestation.
Witness confidentiality. Witnesses often contain sensitive biometric data. Producers MUST encrypt witnesses at rest at all Storage axis values above S0. Producers MUST NOT transmit witnesses in plaintext over networks.
Signature agility. Producers SHOULD design for cryptographic agility. Post-quantum-resistant signature schemes (for example, ML-DSA per FIPS 204) SHOULD be considered as production-viable alternatives as they become widely deployed.
Data minimization. Producers SHOULD retain only the witness data required to substantiate the IEAL claim. Original captures beyond the retained witness SHOULD be discarded.
Per-event consent. Producers MUST NOT release witness plaintext to any party other than the subject without an explicit, per-event capability token issued by the subject. Persistent share-by-default authorizations are not compliant with this specification.
Auditable access. Every access-request, grant, and denial event related to a witness SHOULD be recorded in a subject-accessible audit log.
Cross-border retention. Producers and verifiers holding derivative copies (Section 6.2) SHOULD consider applicable cross-border data-protection regulations, including but not limited to the EU General Data Protection Regulation, the Costa Rican PRODHAB Law, and equivalent national frameworks.
Selective disclosure. Where the underlying carrier supports selective disclosure (for example, SD-JWT, BBS+), producers SHOULD disclose only those fields of the IEAL claim required by the verifier for the specific operation.
The IEAL claim schema uses ISO 8601 timestamps and durations, ISO 639-1 language identifiers where applicable, and Unicode strings encoded in UTF-8. All identifiers defined by this specification are ASCII strings and case-sensitive.
Human-readable identifiers (algorithm names, vendor identifiers) MAY be presented to end users in translated form. The machine-readable identifiers in the IEAL claim MUST remain in their canonical ASCII form regardless of end-user language.
Capture procedures at Algorithm axis A1 and A2 typically require the subject to perform active challenges (head movements, blinks, pose changes). Producers SHOULD offer alternative capture procedures for subjects who cannot perform such challenges, subject to the constraint that the alternative procedure MUST NOT reduce the asserted IEAL level below what is genuinely achieved.
Verifier policies (Section 10) SHOULD provide accommodation processes for operations that would otherwise require IEAL levels that cannot be reached by the subject due to physical accessibility constraints.
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-07-01 | Initial Working Draft. |
Separate crosswalk documents describe the correspondence between IEAL and other identity-assurance frameworks. These crosswalks are informational and do not constitute certification claims or endorsements. Each crosswalk includes a mandatory disclaimer that Attestto’s crosswalks are not endorsed by the referenced standards body.
The planned crosswalk documents are:
spec.attestto.com/ieal/crosswalks/nist-800-63 — NIST SP 800-63-4 IAL, AAL, and FALspec.attestto.com/ieal/crosswalks/iso-30107-3 — ISO/IEC 30107-3 Presentation Attack Detection levelsspec.attestto.com/ieal/crosswalks/eidas — eIDAS Substantial and High assurance levelsFormal certification against any of the referenced frameworks requires assessment by that framework’s authorized assessors. Nothing in these crosswalks substitutes for that assessment.
A machine-readable JSON Schema for the IEAL claim will be published at spec.attestto.com/ieal/schemas/ieal-claim.json under the Apache License 2.0 alongside the v0.1 release.
The schema will be normative for structural validation. Semantic requirements (Section 12) are not fully expressible in JSON Schema and require the conformance procedures described in this specification.
The following example shows an IEAL claim at composite level L3, embedded as an entry in the evidence array of a W3C Verifiable Credential.
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://spec.attestto.com/ieal/v1"
],
"type": ["VerifiableCredential", "NationalIdentityCredential"],
"issuer": "did:pki:cr:tse",
"validFrom": "2026-07-01T14:23:45Z",
"credentialSubject": {
"id": "did:key:z6Mk...",
"givenName": "REDACTED",
"familyName": "REDACTED",
"nationalId": "REDACTED"
},
"evidence": [{
"type": ["IdentityEvidenceAssurance"],
"ieal": "L3",
"capturedAt": "2026-07-01T14:22:10Z",
"capture": {
"axisValue": "C1",
"platform": "android",
"attestationType": "play-integrity",
"attestation": "eyJhbGciOi...",
"nonce": "R7v8kQ2mNp..."
},
"algorithm": {
"axisValue": "A2",
"name": "attestto-active-5pose",
"version": "2.0.0",
"score": 0.91,
"threshold": 0.75
},
"storage": {
"axisValue": "S2",
"witnessCommitment": "e3b0c44298fc1c149afbf4c8996fb924...",
"witnessHashAlgorithm": "sha-256",
"witnessEncryptionAlgorithm": "xsalsa20-poly1305",
"witnessRetention": "P90D",
"locations": [{
"role": "primary",
"holder": "did:key:z6Mk..."
}]
},
"producer": {
"id": "did:sns:vault.attestto",
"signatureAlgorithm": "Ed25519",
"signature": "3yZM8Q..."
}
}]
}Additional examples covering L0 through L6 will be published alongside the v0.1 release.
End of specification v0.1 Working Draft.