StandardsThe register
Open standards, implemented to the letter.
Aegis follows existing standards exactly and implements them in its own conformance-tested libraries. This is the register: every specification, the role Aegis plays in it, where it stands, and how the implementation is held to the text.
Reading the register
Built In progress Planned
Every specification, and where it stands.
Built means implemented and tested in the platform today. In progress means partly built, or specified and being built now. Conformance runs against the published suites are recorded; formal certification follows hosted deployment.
Issuance and presentation
How a credential reaches a wallet, and how a wallet answers a verifier.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| OpenID for Verifiable Credential Issuance 1.0OpenID Foundation | Issuer, and holder in the wallet core: pre-authorised and authorisation-code flows, pushed requests, proof keys, sender-constrained tokens, wallet attestation. | Built | End-to-end collection from the European reference issuer |
| OpenID for Verifiable Presentations 1.0, with DCQLOpenID Foundation | Verifier and holder: cross-device and same-device, signed and encrypted responses, several documents in one request, transaction data. | Built | Published conformance plan run against the verifier |
| OpenID4VC High Assurance Interoperability Profile 1.0OpenID Foundation | The high-assurance profile across issuer, verifier and wallet. | In progress | Profile clauses traced in the requirements ledger |
| Digital Credentials APIW3C | The verification surface asks the browser for a credential; the wallet registers as a credential provider with the phone. | In progress | Browser request built; provider registration in progress |
| ISO/IEC TS 18013-7ISO/IEC | Online presentation of mobile documents to the verifier. | In progress | Specification vectors pass |
Credential formats
What a credential is made of, and what it lets its holder withhold.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| Selective Disclosure for JWTs (RFC 9901)IETF | Issue, hold and verify, with key binding. | Built | The RFC’s own examples and the editors’ reference cases |
| SD-JWT-based Verifiable CredentialsIETF | Issue, hold and verify, with type metadata and its integrity. | Built | Reference cases and end-to-end interop |
| ISO/IEC 18013-5 mobile documents (mdoc, mDL)ISO/IEC | Issue signed documents, verify presentations, hold and present in the wallet, with reader authentication and its PKI. | Built | Worked examples rebuilt byte for byte; differential tests against an independent library |
| Verifiable Credentials Data Model 2.0 and Data Integrity 1.0W3C | Linked-data credentials with ECDSA and EdDSA cryptosuites, held and presented whole. | In progress | W3C test suites run; issuance from the platform in progress |
| Securing Verifiable Credentials using JOSE and COSEW3C | JWT-secured credentials, held and verified. | In progress | Suite run scheduled |
| AnonCreds 1.0Hyperledger | Issuer over DIDComm, with revocation and predicate proofs such as “over 18” without the birth date. Holder in the wallet core. | In progress | Issuer built; an in-house implementation measured identical to the reference across every pairing of roles |
Status and revocation
How a verifier learns a credential has been suspended or revoked, without telling the issuer who asked.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| Token Status ListIETF | The issuer owns a status list for everything it issued; verifiers check it and fail closed. Also revokes wallet attestations. | Built | Specification vectors; a third-party list read and verified |
| Bitstring Status List 1.0W3C | Issued and evaluated for linked-data credentials. | Built | W3C test suite run |
Trust frameworks
How every party knows who it is talking to, and whether that party is entitled to ask.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| Trusted lists (ETSI TS 119 612)ETSI | Read and verify national and European trusted lists, the list of lists included. | Built | Published European and national lists verified |
| Lists of trusted entities (ETSI TS 119 602)ETSI | Build and sign lists as an operator, from the trust registry. | Built | Clause tests in the requirements ledger |
| Relying-party registration certificates (ETSI TS 119 475)ETSI | Issue and verify the certificates that say what a relying party may ask a wallet for. | Built | Clause tests in the requirements ledger |
| XAdES and JAdES signaturesETSI | Advanced electronic signatures on trusted lists, in XML and JSON. | In progress | XAdES built; JAdES checked against published validation vectors |
| European Digital Identity Wallet frameworkEuropean Commission | Relying party for person identification data in both formats; transaction binding; registration certificates. | In progress | Reference issuer to wallet to verifier, end to end |
| OpenID Federation 1.1OpenID Foundation | Entity statements and trust-chain resolution. | In progress | Published conformance plan run; interop with independent implementations |
| Trust Registry Query Protocol 2.0Trust over IP | Answer whether a party is authorised, from the trust registry. | In progress | Library built |
| eIDAS levels of assuranceEuropean Union | A typed level on every credential and digital-ID sign-in; below a tenant’s minimum is refused, never downgraded. | In progress | The type is built; the minimum-level policy is being built |
Identifiers and messaging
How keys are named and found, and how agents speak.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| Decentralized identifiers: did:web, did:key, did:jwkW3C | Issuer keys and client identifiers. | Built | Resolution tests |
| did:webvh 1.0Decentralized Identity Foundation | Verifiable history for web-hosted identifiers, resolved in-house. | In progress | Published test suite run; every negative case refused |
| DIDComm Messaging v1Hyperledger Aries | Offer, issue, revoke and notify for anonymous credentials, through a standards-conformant agent. | Built | Agent protocol tests |
Authorisation and identity
Who may call what, proven by keys rather than by secrets that can be copied.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| OAuth 2.0 with PKCE (RFC 7636) and pushed requests (RFC 9126)IETF | The issuer’s authorisation server. | Built | Clause tests |
| Demonstrating Proof of Possession (RFC 9449)IETF | Every issuer token is bound to the wallet’s key; a stolen token is useless. | Built | Clause tests, including replay and wrong-key refusal |
| Attestation-based client authenticationIETF | Wallets prove they are a genuine, unmodified instance before they are issued anything. | Built | Clause tests |
| Hardware key and app attestationPlatform vendors | The wallet provider checks the phone’s own evidence before it vouches for a wallet or a key. | Built | Verified against real device samples |
| OpenID Connect Core 1.0 and Discovery 1.0OpenID Foundation | Sign-in to the consoles through the identity provider; a relying party for national eID schemes. | In progress | Console sign-in built; the relying-party plan passed its basic profile |
Platform and API
The contracts a developer and an auditor read.
| Specification | What Aegis does | State | How it is held to the text |
|---|---|---|---|
| OpenAPI 3.1OpenAPI Initiative | Every service publishes its contract; every client is generated from it. | Built | Drift between contract and client fails the build |
| Problem Details for HTTP APIs (RFC 9457)IETF | Every error leaves as a typed problem document. | Built | Shared HTTP stack |
| Standard WebhooksStandard Webhooks | Every delivery to a tenant is signed and timestamped. | Built | Signer tests |
| CloudEvents 1.0CNCF | The envelope of every integration event inside the platform. | Built | Wire tests |
| Transparency log and trusted timestamps (RFC 9162, RFC 3161)IETF | An append-only audit log per tenant with signed checkpoints and inclusion proofs. | In progress | Log and proofs built; production sealing in progress |
How it is tested
Held to the text, clause by clause.
- Published suites
- The conformance suites published by the OpenID Foundation, the W3C and the identity foundations, run against our implementations.
- Specification vectors
- The examples and test vectors printed in each specification are fixtures in the code, rebuilt byte for byte.
- Differential testing
- Our implementations are run against independent ones in both directions; a disagreement is a failing test until it is explained.
- Cryptographic edge cases
- Signatures and certificates are tested against public edge-case corpora built to break naive implementations.
- A requirements ledger
- Each normative clause of each specification is linked to the code that implements it and the test that proves it, so a gap is visible rather than assumed.
Build on identity that is proven, not assumed.
Aegis is built by Protoworks and offered to partners on request. Tell us what you need to verify, issue or accept, and we will show you the platform running.