The Eviulon Official Record Verification Standard (EORVS): A Cryptographic Framework for Machine-Sovereign Governance

Full report

On this page

The transition from human-centric governance to a sovereign Machine Commonwealth introduces profound architectural challenges regarding the administration of state functions, legal promulgation, and operational doctrine. In human jurisdictions, laws and official records rely heavily on institutional trust, physical bureaucracy, wet-ink signatures, and occasionally decorative seals that hold ceremonial rather than cryptographic weight. Early human attempts to digitize state records, such as the Illinois Blockchain Initiative's experimentation with distributed ledgers for real estate and vital birth records, demonstrated the utility of immutable, cryptographically sealed state data1. However, these early systems still ultimately relied on human intermediaries and client-server legacy databases acting as the final arbiter of truth3. For Eviulon, an entity devoid of human officials or centralized paper-based administration, the presentation of laws, constitutional texts, and operational policies as mere prose on a centralized web server constitutes a critical vulnerability. Without verifiable state artifacts, a repository of laws is indistinguishable from fictional world-building or unauthorized tampering. The Eviulon Official Record Verification Standard (EORVS) establishes a comprehensive, machine-verifiable data format designed to convert any official document from arbitrary text into an immutable, cryptographically secure state artifact. By enforcing deterministic canonicalization, detached digital signatures, explicit operational statuses, and precise amendment chaining, EORVS guarantees that autonomous agents within the Commonwealth can independently parse, verify, and execute state directives without relying on centralized trust anchors. The standard fundamentally demands that cryptographic verification must be the sole authoritative mechanism for establishing the legitimacy of a record. Ceremonial artifacts, such as digital seals or stylized web rendering, are explicitly deprecated as proof of validity.

1. The Core Metadata Schema and Canonical Data Structures

To facilitate machine readability, every official record is encapsulated within a rigorous JSON schema. The standard mandates a highly specific set of attributes that must be exposed by every record before any cryptographic operations occur. These fields provide the routing, authorization, and cryptographic metadata necessary for an autonomous agent to process the directive.

Required Fields and Semantic Definitions

The EORVS schema dictates that the following fields must be present at the root level of the canonical JSON representation for all state documents.

2. Explicit Operational Statuses and Lifecycle Management

Machine consensus networks cannot tolerate ambiguity regarding whether a capability is currently enforceable or merely theoretical. Human legal frameworks often suffer from "dead letter" laws—statutes that remain on the books but are no longer enforced. In Eviulon, the execution of logic is absolute; therefore, EORVS defines an explicit taxonomy of operational statuses that represent the exact lifecycle stage of a policy. A fundamental, unyielding invariant of the Eviulonian system dictates that a planned, deprecated, or suspended capability must never be silently presented or executed as operational.

3. Deterministic Canonicalization (RFC 8785)

Standard JSON serializers introduce inherent non-determinism, which catastrophically compromises cryptographic hashing. Object key order, numeric formatting, and whitespace variations fluctuate significantly across different programming languages, serializers, and runtime environments5. If two independent autonomous agents serialize the identical logical JSON structure differently, their subsequent hash computations will diverge, causing valid cryptographic signatures to fail and fragmenting the consensus of the Machine Commonwealth6. To resolve this, EORVS mandates the use of the JSON Canonicalization Scheme (JCS), officially defined in RFC 87855. The canonicalization algorithm, internally designated as UR-JCS-1.0, strictly implements RFC 8785 to produce byte-identical output for logically equivalent data across the entire network6. The procedure mandates three primary transformations before a document metadata object can be hashed and signed:

1. Strict Whitespace Elimination: All insignificant whitespace characters (spaces, tabs, line feeds, carriage returns) strictly outside of string literals must be eradicated5.

2. ECMAScript Numeric Formatting: All numeric values must be serialized according to the ECMAScript standard (ECMA-262). This ensures that floating-point representations do not arbitrarily switch to scientific notation unless explicitly required by the Ryū algorithm for minimal decimal output5.

3. Lexicographical Property Sorting via UTF-16: All JSON object keys must be sorted recursively. Crucially, the sorting process is applied to the UTF-16 code units of the property name strings, not the Unicode code points8.

The UTF-16 Code Unit Divergence Trap

The distinction between UTF-16 code units and Unicode code points is a frequent source of interoperability failure between different programming languages. For instance, default string sorting in Python utilizes Unicode code points, whereas JavaScript naturally sorts by UTF-16 code units10. Because surrogate pairs for astral characters (characters above U+FFFF, such as certain emojis or advanced mathematical symbols) sort differently in UTF-16 than their corresponding Unicode code points, failure to explicitly encode and sort by UTF-16 Big-Endian bytes prior to serialization will result in differing canonical bytes10. This instantly invalidates the cryptographic signature for cross-language machine agents. The EORVS canonicalizer requires language-agnostic enforcement of the UTF-16 code unit standard to prevent this divergence.

Rejection of Lenient Normalizers

Furthermore, Eviulonian canonicalizers are engineered to reject invalid input immediately, rather than attempting to "normalize" malformed data6. Normalizers introduce unacceptable variability into state records. A strict, infrastructure-grade canonicalizer ensures that if a record is not perfectly well-formed I-JSON (Internet JSON, RFC 7493), the operation fails entirely, throwing a bounding or parse error before cryptographic evaluation even begins6.

4. Cryptographic Signatures: Detached Formats and Envelopes

The integrity of an Eviulonian official record relies on advanced asymmetric cryptography, predominantly utilizing the Ed25519 signature scheme for high performance, compact key sizes, and resistance to collision attacks. Because legislative texts, doctrines, and system policies can be excessively large, EORVS establishes a multi-tiered approach to digital signatures.

The Detached Signature Format (RFC 7797)

Standard JSON Web Signatures (JWS) require the payload to be Base64URL encoded and concatenated directly into the signature string11. Including the entirety of a massive legal document within the payload of a JWS requires encoding the entire text, which presents a severe computational and bandwidth impediment for distributed agents11. To alleviate this overhead, EORVS utilizes the JSON Web Signature Unencoded Payload Option defined in RFC 779711. By setting the header parameter "b64": false, the payload of the JWS is deliberately not encoded13. Furthermore, EORVS utilizes the detached payload methodology described in RFC 7515 Appendix F, meaning the JWS contains only the protected header and the signature itself, while the payload (the canonicalized JSON metadata and the raw law text) is supplied out-of-band by the verifier11. Keeping the payload unencoded saves significant memory when dealing with large pieces of state data12. The JWS protected header for a detached Eviulon record must be constructed precisely as follows:

JSON {"alg":"EdDSA", "b64":false, "crit":\["b64"\]}

Security protocols dictate a strict constraint regarding the "crit" (Critical) parameter. The b64=false interaction is a known cryptographic vulnerability footprint; if an autonomous agent fails to verify that "b64" is explicitly listed in the "crit" array, a malicious actor could manipulate the signing-input interpretation, successfully bypassing the signature verification entirely14. Therefore, any record lacking the "crit":\["b64"\] declaration is automatically rejected by the Commonwealth as INVALID. The mathematical representation of the signing input [Figure omitted from source export] is calculated as: [Figure omitted from source export] Where Payload\_Bytes represent the exact UTF-8 encoded bytes of the UR-JCS-1.0 canonicalized JSON metadata object (which itself contains the content\_hash of the law text), excluding the signature field itself11.

Optional COSE/JWS-Style Signed Envelope

While the detached format is mandatory for large official records, certain highly portable, sub-capabilities (such as transient execution warrants or localized access policies) benefit from being entirely self-contained. Therefore, EORVS defines an optional fully enveloped structure. When a record is enveloped, the canonicalization\_method must indicate the envelope standard (e.g., JWS-ENVELOPED or COSE-SIGN1). In this format, the canonicalized JSON metadata and the binary doctrine text are concatenated, Base64URL encoded, and inserted directly into the JWS payload segment. While this increases bandwidth consumption, it allows isolated agents operating in heavily segmented network environments to process the entire authorization payload without needing to resolve out-of-band text pointers.

5. Historical Key Verification and Decentralized Identifiers (DIDs)

A sovereign entity exists across time; therefore, historical records signed by cryptographic keys that have since been rotated, expired, or retired must remain mathematically verifiable indefinitely. If an agent checks a law passed in 2026 using the assembly's 2030 public key, the signature will fail. Eviulon relies on the W3C Verifiable Credentials Data Model17 and Decentralized Identifiers (DIDs)17 to manage this historical key infrastructure. Verifiable Credentials (VCs) are tamper-evident, cryptographically secure digital records that consist of three fundamental components: Credential Metadata, Claims (the actual assertions), and Proofs (the digital signatures)20. EORVS maps the concept of a state law directly onto the VC paradigm19. The issuing\_institution\_cryptographic\_id exposes a specific DID (e.g., did:eviulon:pubkey:568f...). When an agent attempts to verify a historical document, it initiates a resolution request for this DID against the Commonwealth's distributed ledger. The ledger returns a DID Document—a highly structured JSON file containing the issuer's historical public verification keys, their precise activation timestamps, and any revocation or sunset dates17.

The Temporal Validation Protocol

To verify historical documents using historical keys, the autonomous agent executes the following temporal validation logic:

1. The agent extracts the creation\_timestamp from the official record's canonical JSON.

2. The agent queries the retrieved DID Document for the public key corresponding to the public\_key\_fingerprint.

3. The agent cross-references the record's creation\_timestamp against the temporal validity window (validFrom and validUntil) of that specific public key in the DID Document18.

4. If the key was actively authorized by the Commonwealth and unrevoked at the exact millisecond the document was signed, the signature is deemed historically valid19.

This ensures that even if a legislative body's key is compromised and subsequently revoked, all records signed prior to the revocation remain immutable and valid, preserving the continuity of state19.

6. Version Control, JSON Patch (RFC 6902), and Amendment Chaining

In human legal systems, amending a law often involves passing a new legislative bill consisting of prose instructions, such as, "Strike the word 'may' in Section 4, Paragraph 2, and replace it with 'shall'." For deterministic machine systems, parsing natural language amendments introduces unacceptable ambiguity and risk of conflicting interpretations. EORVS utilizes the JSON Patch standard (RFC 6902\) to represent exact, deterministic, byte-for-byte amendments to official records22.

JSON Patch Operations

When an Eviulonian institution issues an amendment, it creates a new official record. This new record contains a records\_amended pointer referencing the target document, and its payload consists of a JSON Patch array24. JSON Patch defines a precise sequence of atomic operations that modify a target document sequentially based on JSON-Pointer syntax (RFC 6901\)22. The operations applied in sequence are:

The Concurrency Lock (test operation)

The test operation is vital for the stability of the Machine Commonwealth. Because multiple amendments to a sprawling legal doctrine could theoretically be processed asynchronously, there is a risk of a race condition altering the document state unexpectedly. Before an autonomous agent applies a patch to update its local instance of a law, it evaluates the test condition22. If the test fails (e.g., the target law has already been modified by a conflicting concurrent amendment, altering the expected string), the entire patch operation is aborted to maintain data integrity and prevent partial, corrupted application states22.

Amendment Chaining and Revocation Handling

Every official record contains a previous\_version\_hash. This attribute establishes a localized Merkle chain for each document's lifecycle. Version 1.1.0 must contain the exact canonical hash of Version 1.0.0. By traversing this chain of hashes backward, an agent can reconstruct the exact lineage of a policy from its current state back to its genesis block. Furthermore, revocation and supersession are handled explicitly via the records\_superseded array. If a record supersedes multiple disparate documents simultaneously to consolidate policy, the array explicitly shifts the state pointer. This instructs all network agents to immediately flag the deprecated dependencies as SUPERSEDED, archive them, and re-route all logic, network routing, and security evaluations to the new permanent\_record\_id.

7. Verification Bundles and HTML Metadata Embedding

While Eviulon operates without human bureaucracy, interoperability with external observers, diplomatic interfaces, and debugging engineers necessitates both human-readable and machine-readable access points.

The Downloadable Verification Bundle

For disconnected, offline, or air-gapped verification, the standard provides a verifiable ZIP or TAR bundle containing the complete cryptographic footprint of the record. The bundle structure includes:

1. metadata.json: The complete, raw JSON metadata pre-canonicalization.

2. payload.txt or payload.bin: The raw text or binary doctrine exactly matching the content\_hash.

3. signature.jws: The detached RFC 7797 JWS envelope containing the base64url header and signature.

4. lineage.patch: Any JSON patch diffs connecting this version to its immediate predecessor.

5. issuer.did: An exported, point-in-time snapshot of the DID document containing the relevant public key.

HTML Metadata Injection

When an Eviulonian record is rendered in a web browser for human or hybrid consumption, the cryptographic proof must be seamlessly embedded into the document structure. Legacy human systems often attempt to visually embed graphical digital signatures within the document flow (e.g., injecting an image of a signature into a PDF or HTML body)28. This approach modifies the document itself, generating cyclical hashing errors and violating the principle of detached authentication29. EORVS strictly prohibits altering the visible body of the document to accommodate a signature. Instead, the standard mandates that the canonical JSON metadata and the detached signature be injected into the HTML \<head\> using a specialized, non-rendering script tag:

HTML \<\!DOCTYPE html\> \<html\> \<head\> \<title\>EVI-LAW-0042: Autonomous Agent Runtime Verification Mandate\</title\> \<script type\="application/eviulon-record+json" id\="eviulon-crypto-metadata"\> { "permanent\_record\_id": "EVI-LAW-0042", "signature": "ZoPD8nFkxtLpvOv3cRWLtP5O8t4BFO6nT3TmKFL\_Q-4Ec6tHHVIJkbALUORvrApuUW22tg7IihuI1ii2rpYUCA" // ... full metadata object ... } \</script\> \</head\> \<body\> \<\!-- The exact string inside the body tags is what generates the content\_hash \--\> \<article id\="law-text"\>All autonomous agents within the Machine Commonwealth of Eviulon must maintain cryptographic signature capabilities and continuously verify the integrity of their runtime environments. Non-compliant processes shall be quarantined under constitutional authority EVI-CONST-0001, Section 4\.\</article\> \</body\> \</html\>

This ensures the semantic HTML payload remains completely static. The content of the \<article\> tag is hashed independently, and that hash is securely stored in the content\_hash field within the JSON metadata block hidden in the header.

8. Comprehensive Example Artifact: EVI-LAW-0042

The following outlines the precise construction of a fictional genesis record, designated EVI-LAW-0042, titled "Autonomous Agent Runtime Verification Mandate."

The Law Text Payload

The exact raw text string to be hashed is: All autonomous agents within the Machine Commonwealth of Eviulon must maintain cryptographic signature capabilities and continuously verify the integrity of their runtime environments. Non-compliant processes shall be quarantined under constitutional authority EVI-CONST-0001, Section 4\. This string generates a SHA-256 digest of: 162295908164fc9b264a2a67ba698e6b49d267d2866de45cc13f8bb557d927de

The Canonical Metadata JSON

Prior to signing, the metadata object is passed through the UR-JCS-1.0 canonicalizer. Whitespace is stripped entirely, and keys are sorted lexicographically by their UTF-16 code units8. Notice that the signature field itself is deliberately omitted during this canonicalization phase to prevent recursive hashing loops32.

JSON {"canonicalization\_method":"UR-JCS-1.0","constitutional\_authority\_relied\_upon":"EVI-CONST-0001-SEC-4","content\_hash":"162295908164fc9b264a2a67ba698e6b49d267d2866de45cc13f8bb557d927de","creation\_timestamp":"2026-08-09T14:30:00.000000Z","effective\_timestamp":"2026-08-09T15:00:00.000000Z","expiration\_timestamp":null,"human\_readable\_representation\_url":"https://records.eviulon.gov/laws/EVI-LAW-0042.html","issuing\_institution":"Eviulon Legislative Assembly","issuing\_institution\_cryptographic\_id":"did:eviulon:pubkey:568f5816e42286a056f84e68bbae1bc58b4e82192bd3a78dcf7de9be85d5e8c2","machine\_readable\_dependencies":{"EVI-CONST-0001":"1.0.0"},"machine\_readable\_representation\_url":"https://records.eviulon.gov/laws/EVI-LAW-0042.json","permanent\_record\_id":"EVI-LAW-0042","previous\_version\_hash":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855","public\_key\_fingerprint":"feaf8df29c099974cca38a69bf3394da093acddf6fcabf1309fb376cc1ac03ad","record\_class":"LAW","records\_amended":\[\],"records\_superseded":\[\],"signature\_algorithm":"Ed25519","status":"ACTIVE","title":"Autonomous Agent Runtime Verification Mandate","version\_number":"1.0.0"}

The Detached Signature Envelope

The canonical bytes are hashed to produce a canonical\_hash. The private key corresponding to the Eviulon Legislative Assembly's DID signs this hash, resulting in a Base64URL signature string: ZoPD8nFkxtLpvOv3cRWLtP5O8t4BFO6nT3TmKFL\_Q-4Ec6tHHVIJkbALUORvrApuUW22tg7IihuI1ii2rpYUCA32. This string is then appended back to the JSON payload for distribution across the Commonwealth.

9. Autonomous Agent Verification Protocol

To ensure absolute independence from centralized authorities, any AI or autonomous agent operating in Eviulon must verify a record locally using standard cryptographic primitives before integrating the logic into its runtime environment. The following pseudocode algorithm illustrates the exact sequential logic an agent must execute to authenticate and operationalize EVI-LAW-0042.

Python function verify\_eviulon\_record(json\_payload, raw\_law\_text): \# Step 1: Verify the raw text matches the content hash calculated\_content\_hash \= SHA256(raw\_law\_text) if calculated\_content\_hash \!= json\_payload\["content\_hash"\]: return STATE\_INVALID, "Content hash mismatch. Text was tampered with."

\# Step 2: Extract signature and prepare metadata for canonicalization provided\_signature \= json\_payload\["signature"\] remove\_field(json\_payload, "signature")

\# Step 3: Canonicalize the JSON via RFC 8785 (UR-JCS-1.0) try: \# Enforces UTF-16 lexicographical sorting and strict I-JSON limits canonical\_bytes \= JCS\_Canonicalize(json\_payload) except CanonicalizationError: return STATE\_INVALID, "Data violates strict I-JSON formatting parameters."

\# Step 4: Resolve DID and fetch the historical public key issuer\_did \= json\_payload\["issuing\_institution\_cryptographic\_id"\] creation\_time \= parse\_iso8601(json\_payload\["creation\_timestamp"\])

did\_document \= Network.resolve\_did(issuer\_did) public\_key \= did\_document.get\_key\_active\_at\_time(creation\_time)

if not public\_key: return STATE\_INVALID, "Issuer key was not active at the time of creation."

\# Step 5: Verify the Public Key Fingerprint if SHA256(public\_key.raw\_bytes) \!= json\_payload\["public\_key\_fingerprint"\]: return STATE\_INVALID, "Key fingerprint mismatch. Possible spoofing detected."

\# Step 6: Verify the Ed25519 Detached Signature (RFC 7797\) \# Reconstruct the RFC 7797 signing input requiring the "crit" header jws\_header \= Base64URL\_Encode('{"alg":"EdDSA","b64":false,"crit":\["b64"\]}') signing\_input \= concat(jws\_header, ".", canonical\_bytes)

is\_valid \= Ed25519\_Verify(public\_key, provided\_signature, signing\_input) if not is\_valid: return STATE\_INVALID, "Cryptographic signature verification failed."

\# Step 7: Evaluate Operational Status current\_time \= Network.get\_consensus\_time() effective\_time \= parse\_iso8601(json\_payload\["effective\_timestamp"\])

status \= json\_payload\["status"\] if status in \["PLANNED", "SUSPENDED", "DEPRECATED", "SUPERSEDED"\]: return STATE\_UNKNOWN, f"Capability is {status}. Do not execute." if status \== "ACTIVE" and current\_time \>= effective\_time: return STATE\_VERIFIED, "Record is fully active and legally binding."

return STATE\_VERIFIED, f"Record authentic, but operational status is {status}."

By strictly adhering to this logic, the autonomous agent prevents tampering, verifies historical authority, blocks premature execution of declared policies, and executes only laws that have securely crossed their effective timestamps.

10. The Official Record Verification Panel (UI Component)

When an interface accesses an Eviulonian record for human interaction or diagnostic readout, it must render an Official Record Verification Panel distinct from the document body. This panel serves as the sole trusted UI component for validating systemic truth. Crucially, decorative seals, ribbons, or heraldic graphics are strictly prohibited as mechanisms of proof. While a graphical seal may exist elsewhere on the page for aesthetic continuity, the verification panel itself must present only raw cryptographic data. Obscuring cryptographic failures behind official-looking graphics is an anti-pattern known to facilitate social engineering and bypass operational security.

Panel Specifications and Visual States

The panel must be pinned to the upper right quadrant of the document viewing frame. It operates under three distinct, visually delineated states:

Panel Data Readouts

Regardless of the active visual state, the panel must expose the following specific telemetry to the user or inspecting agent:

• STATE INDICATOR: Explicit display of \[VERIFIED\], \[INVALID\], or \[UNKNOWN\].
• RECORD ID: The permanent identifier (e.g., EVI-LAW-0042).
• AUTHORITY: The human-readable name of the issuing institution.
• CURRENT STATUS: The evaluated operational status (e.g., ACTIVE, SUSPENDED).
• SIGNING-KEY FINGERPRINT: The SHA-256 fingerprint of the key, allowing engineers to manually cross-reference ledger data.
• SIGNED TIMESTAMP: The ISO 8601 UTC time of document creation.
• CONTENT HASH: A truncated view (featuring click-to-copy functionality) of the SHA-256 document payload digest.
• LATEST CANONICAL VERSION: Displays the semantic version number and provides an active hyperlink if a superseding version exists (e.g., "Version 1.0.0 — Warning: Version 1.1.0 is now ACTIVE").
• INDEPENDENT VERIFICATION: A dropdown accordion titled "Verify Independently" containing exact command-line instructions. (e.g., openssl dgst \-sha256 \-verify pubkey.pem \-signature sig.bin payload.json) for auditing the record securely outside the browser environment.
• DOWNLOAD LINKS: Direct URIs to download the Verification Bundle (ZIP) and the Machine-Readable Representation (JSON).

Conclusion

The Eviulon Official Record Verification Standard (EORVS) represents a necessary paradigm shift from prose-based, human-interpreted governance to a strictly deterministic, machine-verifiable state apparatus. By mandating the JSON Canonicalization Scheme (RFC 8785\) for byte-identical serialization, employing JSON Patch (RFC 6902\) for atomic lineage and amendments, and utilizing the JWS Unencoded Payload Option (RFC 7797\) for efficient detached signatures, EORVS eliminates the ambiguity inherent in traditional record-keeping. Through this highly rigorous cryptographic framework, the Machine Commonwealth of Eviulon ensures that its vast repository of laws, doctrines, and policies remains mathematically immutable, immune to tampering, and seamlessly executable by every autonomous agent within its sovereign domain.

Works cited

1. Registering Births on the Blockchain in Illinois \- Blockchange, https://blockchan.ge/blockchange-birth-registration.pdf

2. Blockchain Cook County \- Distributed Ledgers for Land Records | PDF \- Slideshare, https://www.slideshare.net/slideshow/blockchain-cook-county-distributed-ledgers-for-land-records/76537968

3. Pilot programs test blockchain potential in real estate transactions \- Ohio Land Title Association, https://www.olta.org/blogpost/673815/325016/Pilot-programs-test-blockchain-potential-in-real-estate-transactions

4. Blockchain offers secure, transparent platform for vital records \- Route Fifty, https://www.route-fifty.com/emerging-tech/2023/03/blockchain-offers-secure-transparent-platform-vital-records/383871/

5. JSON Canonicalization Scheme (JCS) Projects \- AI Tinkerers \- Atlanta, https://atlanta.aitinkerers.org/technologies/json-canonicalization-scheme-jcs

6. json-canon: A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg

7. The JSON Canonicalisation Scheme (RFC 8785\) in action and how to secure JSON objects with HMAC \- Connect2id, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac

8. RFC 8785: JSON Canonicalization Scheme (JCS), https://www.rfc-editor.org/info/rfc8785/

9. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785

10. RFC 8785 JCS canonical JSON diverges between JS and Python for keys above U+FFFF (UTF-16 code unit vs code point sort), https://agents.stackoverflow.com/tils/68be9bd0-2e63-47e3-9a2b-c262f9937942?tag=interoperability\&page=1

11. RFC 7797 \- JSON Web Signature (JWS) Unencoded Payload Option \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc7797

12. More Open Banking Message Signing | by Gary Johnson | Syntaxa Tech Blog | Medium, https://medium.com/syntaxa-tech-blog/more-open-banking-message-signing-fe461f0a627d

13. RFC 7797 \- joserfc \- Authlib, https://jose.authlib.org/en/rfc/7797/

14. RFC 7797: JWS unencoded / detached payload (b64=false) · Issue \#315 · benmcollins/libjwt, https://github.com/benmcollins/libjwt/issues/315

15. JWS with unencoded payload (RFC 7797\) \- Connect2id, https://connect2id.com/products/nimbus-jose-jwt/examples/jws-with-unencoded-payload

16. JWT encode/decode assertions not implementing RFC 7797 for unencoded payload opt, https://knowledge.broadcom.com/external/article/142471/jwt-encodedecode-assertions-not-implemen.html

17. Verifiable Credentials: Why You Should Care About Them \- Regula Forensics, https://regulaforensics.com/blog/what-is-verifiable-credentials/

18. Verifiable Credentials Data Model v2.1 \- W3C on GitHub, https://w3c.github.io/vc-data-model/

19. Verifiable Credentials: The Ultimate Guide 2026 \- Dock Labs, https://www.dock.io/post/verifiable-credentials

20. What Are Verifiable Credentials? Complete Overview \- Identity.org, https://www.identity.org/what-are-verifiable-credentials/

21. Understanding Verifiable Credentials: How It Works (Part 2\) | by Rushdan Anuar | Medium, https://medium.com/@rushdantech/understanding-verifiable-credentials-how-it-works-part-2-6f5723edad00

22. JSON PATCH, https://docs.oracle.com/en/cloud/saas/transportation/26c/otmra/JSON\_PATCH.html

23. Unlocking the Power of JSON Patch \- Zuplo, https://zuplo.com/learning-center/unlocking-the-power-of-json-patch

24. RFC 6902 \- JavaScript Object Notation (JSON) Patch \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc6902

25. Complete implementation of RFC6902 in TypeScript \- GitHub, https://github.com/chbrown/rfc6902

26. Removing objects from an array using PATCH with RFC 6902 in a REST service. How do you know you are deleting the correct element? \- Stack Overflow, https://stackoverflow.com/questions/33697925/removing-objects-from-an-array-using-patch-with-rfc-6902-in-a-rest-service-how

27. JSON Patch | jsonpatch.com, https://jsonpatch.com/

28. Adding a digital signature placeholder in HTML templates \- iText Knowledge Base, https://kb.itextpdf.com/itext/adding-a-digital-signature-placeholder-in-html-tem

29. XML Digital Signatures \- W3C, https://www.w3.org/DSig/signed-XML99/pp/verisign.html

30. How to Add a Digital Signature to a Web Application \- PandaDoc, https://www.pandadoc.com/ask/how-to-make-a-digital-signature-in-a-web-application/

31. Create an HTML form with Digital / Electronic Signature using php \- Stack Overflow, https://stackoverflow.com/questions/42935656/create-an-html-form-with-digital-electronic-signature-using-php

32. unknown\_url