Skip to main content

UbID Connect

UbID Connect is the product domain for interoperability and trusted messaging. It helps institutions, wallets, issuers, verifiers, and authorized agents exchange identity information without requiring every participant to use the same internal technology stack.

Interoperability is not only message transport. A trustworthy connection must resolve who the parties are, which keys and services they advertise, which protocol is being used, what policy applies, and what evidence should be retained.

What it addresses​

Identity ecosystems become expensive and fragile when every institution builds a proprietary connection to every other participant. Credentials lose portability, trust decisions become opaque, and changing a vendor can require redesigning the entire integration.

UbID Connect uses standards-based contracts and adapter boundaries so that internal technologies can evolve without changing the meaning of the external trust exchange.

Core responsibilities​

Publicly, UbID Connect covers:

  • decentralized identifier resolution and verification material;
  • issuer, wallet, verifier, and service discovery;
  • identity-bound encrypted messaging;
  • standards-based credential issuance and presentation exchanges;
  • enterprise federation where appropriate;
  • trust bridges between institutional domains;
  • routing and delivery abstractions for authorized participants;
  • evidence describing the parties, protocol, purpose, and outcome of an exchange.

Trusted messaging​

Trusted messaging differs from ordinary application messaging in several ways:

  • the communicating parties are linked to verifiable identifiers;
  • messages can be encrypted independently of the underlying transport;
  • message purpose and protocol state are explicit;
  • recipients validate sender identity and authorized keys;
  • delivery and processing can produce evidence without exposing plaintext content.

This pattern is especially useful for recovery, credential coordination, device lifecycle, and software-agent collaboration.

Federation and credential trust​

Federated login and verifiable credentials solve different problems.

  • Federation can establish an authenticated session with an enterprise identity provider.
  • A verifiable credential provides portable signed claims that can be presented across contexts.

UbID Connect can support both, but it does not collapse them into one trust model. An authenticated enterprise session does not automatically make every claim acceptable, and a valid credential does not automatically create an application session.

Trust boundaries​

External proofing services, communication providers, registries, clouds, and partner systems remain explicit dependencies. UbID Connect places adapters and policy boundaries around those dependencies so that their role can be reviewed and replaced.

A connection should identify:

  • which participant is authoritative for each claim;
  • which identifiers and keys are trusted;
  • which protocols and algorithms are accepted;
  • how status and revocation are checked;
  • which data may cross the boundary;
  • what happens when a dependency is unavailable or untrusted.

Relationship with other products​

  • UbID Credential Cloud uses Connect for issuer-to-wallet exchange.
  • UbID Wallet uses Connect to interact with issuers and verifiers.
  • UbID Recover uses trusted messaging among recovery participants.
  • UbID Trust API exposes partner-facing integration contracts.
  • UbID Access uses federation and identity-domain integration where appropriate.

What this product does not decide​

Transport success does not equal trust success. UbID Connect can deliver and validate an exchange, but the relevant issuer, verifier, relying party, or recovery policy remains responsible for the business decision.

Public documentation boundary​

Public documentation covers standards, roles, trust boundaries, and message concepts. Network topology, routing credentials, mediator configuration, customer connections, private service names, and operational addresses remain controlled.

See also Standards and Interoperability, DIDComm, and Integration Model.