Standards and Interoperability
UbID is designed as an interoperable trust fabric rather than a closed identity silo. Open standards define how identifiers are resolved, credentials are represented, wallets interact with issuers and verifiers, users authenticate, services receive authorization, agents exchange protected messages, and software assistants discover governed capabilities.
Standards establish common contracts between participants that may use different products and internal technology stacks. They do not remove the need for governance, policy, security engineering, privacy controls, testing, or institutional accountability.
Interoperability layers
| Layer | Main standards or profiles | Purpose in the UbID model |
|---|---|---|
| Identification and resolution | DID Core and did:web | Publish resolvable identifiers, verification methods, and service references. |
| Credential semantics | W3C Verifiable Credentials Data Model | Express issuer, holder, subject, claims, schema, status, and evidence consistently. |
| Selective disclosure | SD-JWT and credential profiles based on SD-JWT | Allow a holder to disclose selected claims instead of the complete credential payload. |
| Credential issuance | OpenID4VCI | Coordinate offers, authorization, proof, and delivery between a wallet and an issuer. |
| Credential presentation | OpenID4VP and DCQL | Request and return suitable credentials or presentations for a defined purpose. |
| Web authentication | WebAuthn and FIDO2 | Provide phishing-resistant public-key authentication and passkeys. |
| Federation and sessions | OpenID Connect | Establish authenticated web sessions and interoperable identity assertions. |
| API authorization | OAuth 2.0, PKCE, and current security best practice | Delegate bounded access to protected APIs. |
| Agent messaging | DIDComm Messaging | Exchange identity-bound encrypted messages independently of a specific transport. |
| AI and tools | Model Context Protocol | Expose resources and tools to authorized software assistants through a governed integration contract. |
Other standards can contribute to specialized controls, including JSON Schema for validation, JOSE and COSE for cryptographic envelopes, status-list formats, OHTTP and HPKE for transport privacy, and post-quantum standards for long-term crypto-agility. Their use must be declared by the relevant product or partner profile rather than inferred from the platform name.
Four dimensions of interoperability
Syntax
Participants must agree on how information is encoded and transported. Examples include JSON, JWT, JWS, JWK, HTTP, and DIDComm message envelopes.
Semantics
A technically valid JSON object is not interoperable if the participants assign different meanings to its fields. Credential types, claim definitions, schema versions, status meanings, assurance levels, and purpose definitions must be governed.
Trust
Interoperability does not mean accepting every issuer, key, algorithm, wallet, or verifier. Each institution still applies trust registries, issuer policy, algorithm policy, status checks, assurance requirements, and risk controls.
Operations
Production interoperability also requires version negotiation, metadata discovery, error handling, replay protection, lifecycle management, conformance testing, monitoring, and change governance.
Standard maturity and UbID maturity are different
A specification can be final while a particular UbID capability remains planned, limited, or available only to partners. Conversely, UbID can implement a controlled profile based on a draft specification while clearly identifying the pinned version and migration obligations.
The public portal therefore separates:
- the external maturity of a specification;
- the architecture role assigned to it;
- the current UbID capability status;
- the feature subset enabled in a specific deployment;
- the conformance evidence available for review.
No standards page should be interpreted as a universal conformance claim for every UbID product, tenant, credential type, or environment.
Version and profile governance
An interoperable deployment should record:
- the exact specification or profile version;
- mandatory and optional features supported;
- credential formats and algorithms allowed;
- metadata and discovery requirements;
- error and retry behavior;
- privacy and retention rules;
- conformance tests and known limitations;
- migration and deprecation policy.
This profile-based approach allows UbID to evolve without silently changing the trust contract between issuers, holders, wallets, verifiers, and partners.
What standards do not replace
Open standards do not determine whether an institution is authorized to issue a claim, whether identity proofing was sufficient, whether a verifier's request is proportionate, whether a credential should be accepted for a transaction, or whether processing is lawful in a jurisdiction.
Those decisions remain with governance, policy, assurance, and accountable institutional actors.
Public documentation boundary
The public portal explains standards, roles, lifecycle concepts, and approved interoperability positions. It excludes private schemas, customer profiles, endpoint inventories, client registrations, trust lists, cryptographic key identifiers, recovery routing, internal protocol extensions, conformance gaps, and operational credentials.
Continue with Decentralized Identifiers, Verifiable Credentials and SD-JWT, or OpenID for Verifiable Credentials.