Preamble

The ELAI Ecosystem is an open network of independent product surfaces that share a common cryptographic trust primitive. Participants in the ecosystem produce and verify signed credential attestations that travel with the artifact, not the platform — verifiable by anyone, locked to no vendor, surviving the sunset of any single participant.

This Charter defines what the ecosystem is, what protocols participants implement, what guarantees participants provide to users and to each other, and how new participants join. It is the standards-level document. The patent-level document is US Patent Application 17/085,257 and its Continuation-in-Part filing, both pending.

The ecosystem exists because identity infrastructure built on vertically-integrated platforms fails users in three predictable ways: credential surveillance through centralized aggregation, credential revocation by single-platform authority, and credential loss through platform sunset. The ELAI Ecosystem is the structural alternative.

1.Scope of this Charter

This Charter governs:

• The cryptographic protocols and serialization disciplines that define ELAI compliance.
• The interoperability properties any participant must provide.
• The honesty obligations participants accept regarding cryptographic strength claims.
• The governance and stewardship arrangement under which the ecosystem evolves.

This Charter does not govern:

• Specific product offerings of any participant.
• Commercial terms between participants, users, or third parties.
• Implementation languages, runtimes, or operating systems.

2.Definitions

The following terms have the meanings ascribed in this Section throughout this Charter.

Participant

An organization or independent developer operating one or more Surfaces that satisfy this Charter.

Surface

A discrete service, application, or endpoint that generates or verifies ELAI attestations for one or more Credential Classes. Surfaces are independently deployable at distinct network endpoints.

Credential Class

A category of credential being attested. Examples include: digital documents; chip cards compliant with ISO/IEC 7816-4; magnetic stripe credentials compliant with ISO/IEC 7811; mobile-native credentials accessed via near-field communication; biometric credentials accessed via mobile device hardware; identity documents (driver's licenses, passports, DD214s, professional licenses).

User-Held Key

An Ed25519 key pair generated, stored, and controlled by an end user on user-owned computing hardware. Private key material does not leave the user's device under normal operation.

Attestation

A digitally signed statement issued by a Surface, comprising a payload, an Ed25519 signature over the payload's canonical serialization, and the corresponding Ed25519 public key.

Bundle

A chained attestation combining two or more Attestations into a single artifact carrying its own outer signature over the canonical serialization of the constituent Attestations.

Verifier

Any software — a Surface, a standalone library, an offline tool, or a third party with no relationship to the ecosystem — capable of validating an Attestation or Bundle using the procedures defined in Section 4.

Steward

AmericaFirst4Us Inc., as the convening authority responsible for maintaining this Charter, processing participant applications, and coordinating ecosystem evolution.

3.Protocol Requirements for Participants

A Surface is ELAI-compliant if and only if it implements each of the following requirements. Capitalized keywords (SHALL, SHALL NOT, MAY) are used in the sense of IETF RFC 2119.

3.1Signing primitive

• Signature algorithm. Ed25519, as specified in IETF RFC 8032.
• Hash algorithm. SHA-256, as specified in FIPS PUB 180-4.
• Serialization. Canonical JSON, with (a) recursive alphabetical sorting of object property keys; (b) elimination of insignificant whitespace; (c) string escaping per JSON specification with stable escape ordering; (d) numeric value normalization. RFC 8785 or equivalent SHALL be referenced.

3.2Key custody

• Surfaces SHALL NOT generate, possess, transmit, or persist private key material on behalf of users.
• Surfaces SHALL accept a User-Held Key as the signing identity for every Attestation.
• Surfaces MAY assist users in generating a User-Held Key locally on the user's device, provided the resulting private key material never traverses the network and is not transmitted to any Surface.

3.3Local-first attestation storage

• Surfaces SHALL deliver every generated Attestation back to the user's device.
• Surfaces MAY operate without persisting any copy of an Attestation server-side.
• Where a Surface elects to persist Attestation copies (for user convenience or audit logging), the Surface SHALL NOT aggregate Attestations across users at any single network endpoint.

3.4No centralized aggregation

The ecosystem operates without a single network endpoint that maintains the aggregated set of Attestations of any individual user across multiple Surfaces.

A Steward-operated registry of Surfaces and their public verification endpoints is permitted and does not constitute aggregation.

3.5Honesty obligation: explicit event classification

Each Attestation SHALL carry an explicit machine-readable event class:

• cryptographically_anchored — the underlying credential supports chip-level cryptographic authentication that has been exercised.
• presence_only — the underlying credential lacks chip-level cryptographic capability; the Attestation evidences time and location of presentation, not cryptographic identity of the credential itself.
• absent — the Attestation evidences that one or more previously-bonded credentials are absent at a subsequent point in time (used in conjunction with pair-reference primitives).

3.6Verification accessibility

• Every Attestation produced by a Surface SHALL be verifiable using publicly available cryptographic libraries implementing RFC 8032, RFC 8785 (or equivalent), and FIPS 180-4.
• Verification SHALL NOT require licensing of, access to, or interaction with any proprietary software belonging to the Surface that produced the Attestation.
• Where a Participant operates a Verifier Surface in addition to its signing Surfaces, the Verifier SHALL accept Attestations produced by any compliant Participant, not solely the Verifier operator's own Surfaces.

3.7Survival guarantee

Surfaces SHALL be designed such that Attestations produced at time t₁ remain cryptographically verifiable at any later time t₂ > t₁, even after the producing Surface is deprecated, sunset, or otherwise rendered inoperative — by virtue of relying solely on publicly specified cryptographic primitives.

4.Verification Procedure

A Verifier validates an ELAI Attestation by the following procedure.

1. Parse the Attestation into its three components: payload, signature, public key.
2. Recompute the canonical JSON serialization of the payload per Section 3.1.
3. Compute the SHA-256 hash of the recomputed serialization per FIPS 180-4.
4. Verify the Ed25519 signature against the recomputed serialization using the included public key and the RFC 8032 Ed25519 verification algorithm.
5. Check the event-class label per Section 3.5 and present the result to the verifying party with the cryptographic-strength context preserved.

Bundle verification follows the same procedure for the outer signature, then recursively for each constituent Attestation.

A Verifier MAY additionally consult the Steward-operated Participant Registry to confirm that the signing public key is associated with a known Participant — but such consultation is OPTIONAL. ELAI verification is correct and complete without it.

5.Governance

5.1Steward

AmericaFirst4Us Inc., as Steward, is responsible for:

• Maintaining this Charter and publishing successive versions in a public, signed location.
• Operating the Participant Registry.
• Processing applications from prospective Participants and announcing admissions.
• Coordinating the resolution of interoperability disputes.
• Stewarding the ELAI patent portfolio (US Patent Application 17/085,257 and CIP, both pending) on terms consistent with ecosystem growth.

The Steward holds no privileged ability to revoke Attestations issued by any Participant or to invalidate User-Held Keys.

5.2Charter evolution

This Charter is versioned. Material changes require:

• Publication of the proposed revision in draft form for not less than thirty (30) days.
• Solicitation of comment from current Participants.
• Publication of the final version with revision history.

Backward-incompatible protocol changes (for example, retirement of Ed25519 in favor of a successor signature algorithm) require an extended public comment period of not less than ninety (90) days, and migration paths preserving the Survival Guarantee in Section 3.7.

5.3Disputes

Interoperability disputes between Participants are resolved by the Steward in the first instance. The Steward's process is published separately and is non-binding on commercial relationships between Participants.

6.Reference Implementations (Current Participants as of v1.0)

The following Surfaces are operated by the Steward and serve as reference implementations of ELAI compliance:

• 4PDFs (4pdfs.com) — document credential attestation surface. Generates signed PDF artifacts with embedded inner-payload Attestations and outer document-level manifest signatures.
• verifythecard.com — hardware credential attestation surface. Attests ISO/IEC 7816-4 chip cards and ISO/IEC 7811 magnetic stripe credentials with honest event classification per §3.5.
• idregulators.com — multi-credential identity wallet (launching 2026). Aggregates user-held Attestations across credential classes for the user's own benefit, with no cross-user aggregation.
• OuiAmi (Apple App Store) — mobile-native credential attestation surface. Embeds ELAI signing on iOS (CoreNFC) and Android (IsoDep) for in-the-field attestation.

A multi-card hardware Bundle, reduced to practice on May 23, 2026, was generated by verifythecard.com and independently verified by 4pdfs.com, by verifythecard.com itself, and by an offline Python implementation of RFC 8032 — demonstrating the cross-Surface verification property required by Section 3.6.

7.How to Become a Participant

Prospective Participants may apply by emailing the Steward at tpoc@americafirst4us.com with:

1. A description of the proposed Surface, including the Credential Class or Classes it will attest.
2. A statement of intent to comply with Sections 3 and 4 of this Charter.
3. A demonstration Attestation or Bundle produced by the proposed Surface, suitable for verification against an independent Verifier.
4. A point of contact responsible for ecosystem coordination.

The Steward will evaluate the application against Charter compliance, conduct an interoperability test against the existing reference implementations, and respond within thirty (30) days.

Successful applicants are added to the Participant Registry, granted the right to display the ELAI ecosystem mark on compliant Surfaces, and invited to the Participant coordination forum.

8.Intellectual Property and Licensing

The cryptographic primitives that define ELAI — Ed25519 (RFC 8032), canonical JSON (RFC 8785 or equivalent), and SHA-256 (FIPS 180-4) — are open standards and are not the subject of this Charter's licensing terms.

The architectural systems and methods of ecosystem participation and cross-Surface verification are the subject of US Patent Application 17/085,257 and its Continuation-in-Part, both pending and assigned to AmericaFirst4Us Inc.

The Steward's stated intent is to license the patent portfolio on fair, reasonable, and non-discriminatory (FRAND) terms to Participants in good standing under this Charter. Specific licensing terms will be published as a separate document and may include zero-cost licenses for small Participants, defense and government use, and educational use.

The Steward retains all patent enforcement rights against unauthorized implementations of the patented systems and methods.

9.Versioning and Effective Date

Version

1.0

Issued

May 26, 2026

Effective

Upon publication at americafirst4us.com/ecosystem/charter and ELAI-signing by the Steward.

Appendix A — Minimal compliant Attestation example

The following is a structurally minimal example of a compliant Attestation. Field names and structure illustrate the canonical-JSON serialization discipline. Implementations MAY add additional fields; the listed fields are required.

{
  "@type": "ELAI/Attestation/v1",
  "credentialClass": "iso7816-4-chip",
  "eventClass": "cryptographically_anchored",
  "issuedAt": "2026-05-23T14:32:11.000Z",
  "payload": {
    "credentialIdentifier": "<class-specific identifier>",
    "evidence": "<class-specific evidence object>"
  },
  "signature": {
    "algorithm": "Ed25519",
    "publicKey": "<base16 or base64 public key>",
    "value": "<base16 or base64 signature>"
  }
}

The payload field is canonically serialized per Section 3.1 and signed by the User-Held Key. The signature is verifiable by any Verifier following Section 4.

Appendix B — Honest-Decline Framework illustrated

A magnetic-stripe credential read at a point of sale produces an Attestation with eventClass: "presence_only". The Attestation evidences:

• The time and location at which the magstripe was read.
• The track-data identifiers observed.
• The Surface that performed the read.

The Attestation does NOT evidence:

• The cryptographic identity of the credential bearer.
• The non-cloned status of the credential.

A downstream Verifier presented with this Attestation MUST surface the presence_only event class to the verifying party rather than treat the Attestation as cryptographic authentication. This is the integrity guarantee that makes ELAI participant Attestations safe to chain into multi-Class Bundles.