Trust Management

Defining the challenge for ecosystem builders as Trust Vectors. What Mechanisms and Conventions do they need to convey trust between ecosystem components? Can those convey meaning to others globally?

If you don’t have a paid Medium account, use this link.

This straw man is open for your collaboration. See Questions at the end. It is coordinated with SIDI Hub. Please feel free to email david at decipher dot id.

Trust = Assurances that Mitigate Risk

Each participant in identity transactions carries some risk. Some are merely perceived risks, but they are real toward the participant taking part.

The Ecosystem works because every participant plays a role in providing assurances to others that mitigate or meet their risk. Trust is the term used to express that ecosystem participants are meeting their obligations to provide assurances for their role according to ecosystem expectations. Rules for meeting expectations are written in a **Trust Framework**.

Trust Management

Trust Management is the rules, guidelines, conventions, and mechanisms that allow any participant to discover in advance or determine in real time that another participant they interact with has met their obligations and, therefore, mitigates risk. Rules are enforceable Guidelines that determine how each participant should fulfill their trust obligations for their role.

Mechanisms are methods, often standardized, for inspecting that a participant is a verifiable member of the Ecosystem fulfilling their obligations — they are in conformity. The ICAO Public Key Directory (PKD) for passports is an example of a mechanism for obtaining materials to verify trust in a passport being read.

Conventions may sit on top of mechanisms to customize or configure that mechanism for usage within a particular role, thereby allowing one role to be inspected differently than other roles. A Convention explains how to take part in the Mechanism and therefore expresses the meaning of the Mechanism. The policies for how to join the ICAO PKD and obtain approval as a country to upload certificates to the PKD are some of the Conventions surrounding the Mechanism and implementation.

Categories of the Mechanisms of Trust Management

• Centralized trust anchor (one CA authority)
• Hierarchical PKI (common trust anchor)
• Federated (multiple trust anchors authorized by the Trust Framework). A Trust Registry may be the mechanism for dispensing trust anchors for inspection. There may be a convention for querying any participant about conformance.
• Decentralized Trust (Smart Contracts as trust anchors (?) coordinated by the Trust Framework)
• Free Market (lack of conventions or mechanisms; can create reliance on reputational trust only)

These categories of mechanisms are being defined in standardized ways within multiple communities and it will be useful to gather information about available mechanisms to evaluate them. More importantly, Operators must establish Conventions in their Ecosystem for inclusion in the mechanism.

Wallet Ecosystems

Fig 1: Trust Relationships needed for Credential Actions to happen in current 3-Party Wallet Ecosystems

Definitions

Issuers endorse Digital ID Credentials on behalf of Users (aka residents or citizens) as a verifiable representation of an accurate point-in-time collection of attributes about the User’s identity. Endorsement is typically by cryptographic digital signature that indicates the accuracy and provenance of the attributes at the time of Provisioning. Issuers use a Wallet Connector to offer Credentials to a User and they must trust the Wallet before Provisioning

The User can store these Credentials in cloud or mobile Wallets operated by a Wallet Provider.

A Verifier is an entity seeking to read and validate Credentials received from the User’s Wallet using a Reader during a transaction. Readers can be physical, an application, or a web service. The End User must trust the Verifier and be informed about the transaction to be comfortable to give Consent. The Reader must trust the Issuer in order use an Issuer public key to validate the Credential data.

Issuers, Verifiers and Wallet Providers each operate within the rules of an Ecosystem. Trust List Providers help distribute certificates for participants that conform to ecosystem rules.

Adding User Authentication

Users authenticate to the Wallet app before sharing credentials, which gives the Verifier some confidence that the Credential presenter is the proper Holder. In many transactions, the Holder shares a portrait to the Reader that the Verifier can then visually inspect. In other ecosystems, there is an expectation of achieving “substantial” user authentication before any credential data is released.

Fig 2: Adding the Trust Vector that will permit User Authentication by the Wallet app/service

When Users are provided the standardized ability to authenticate to their Wallet and provide the results of User Authentication to the Reader, a new trust relationship appears. The Reader must trust the Wallet software to trust the result of the User Authentication (sometimes called Holder binding).

Trust Between Components

Trust Vectors

How can the verifier be assured that the Issuer is in fact the entity that officially endorses and is the authoritative entity to provision that credential? How can partners in a digital interaction be certain that a public key really belongs to the claimed entity? What protections are afforded the User as they present identity credentials across one or more ecosystems? How do Users establish some assurance about Verifiers and Readers they interact with? How do Verifiers and Issuers trust Wallets?

Below is the complete view of Trust Vectors associated with trust management for wallet-based architectures.

Assumptions:

• Issuer controls the lifecycle of credentials - endorsement and revocation
• the Ecosystem sets the policy across all of the Trust Vectors within their Ecosystem, and those policies, rules, conventions, and mechanisms may vary across different ecosystems
• It is beneficial to have law behind policy and to have policy fit within local law
• It is beneficial to have an Ecosystem Operator who enforces the Trust Framework policy

Vectors:

1. Issuer Trusts Wallet. The Issuer must trust the security and credential protection of a Wallet in order to approve provisioning credentials for its Users into that Wallet. The Issuer may also need to trust that the Wallet will appropriately authenticate the User during credential presentation. Conversely, the Wallet should not report transactions to the Issuer.
2. Reader Trusts Wallet. The Reader device used by the Verifier must trust assertions from the Wallet in order to establish that credential protection and User Authentication were adequately performed. This mitigates the Verifier’s risk in the transaction.
3. User Trusts Verifier. To establish informed consent and approve the sharing of identity attributes, the User (of a Wallet) must trust the Verifier operating the Reader. For instance, the User should know with some level of certainty that they are interacting with a known Reader in that context (e.g., the Reader at the automated checkout counter is operated by the Verifier store and is not a rogue Reader).
4. Reader Trusts Issuer. Upon receipt of a credential, the Verifier must ensure that the Reader validates the credential using the procedures established by the Issuer.
5. Ecosystem Trusts Reader (Reader can Identify Itself). The Reader has registered with a Registrar within an Ecosystem to properly identify itself to Users as part of a request for attributes. In some instances an Ecosystem or Issuer authorizes a Reader to request scopes (data sets) that the Wallet could enforce on behalf of the User.
6. User Trusts Wallet (against leaks, profiling, surveillance, correlation). This may seem like a wallet purchase decision topic similar to browsers… but unlike browsers, Wallets caching transaction logs and receipts insecurely or allowing user-profiling subjects the user to identity takeover, “identity fraud” (financial takeover), or worse.

There are mechanisms in many standards for signing a request or providing an attestation during engagement of the standard communication so that two entities can trust each other. We’re not talking about communication security here, although that also is established. We’re talking about how a component establishes and then trusts the identity of another component with which it is communicating. The receiving component checks the cryptographic signature.

Many times in current ecosystems, such as Mobile Driver’s Licenses in the United States, some of these Trust Vectors become trusted by default because the same entity (often the Issuer) is publishing Wallet applications that connect to Wallet Connector for provisioning and even publishing Readers that accept and verify credentials.

Some bilateral agreements are also made out-of-band for Wallet providers (often OS Platform Wallets) to accept credentials from Wallet Connectors when they meet Issuer requirements ahead of time and interactively to assure the Holder is the correct credential recipient. In the US mDL Ecosystem, for the Transportation Security Administration (TSA) to accept credentials from Wallets, they must establish a bilateral agreement with the Wallet-WalletConnector-Issuer combination.

However, to facilitate User choice in their components, reduce the complexity of bilateral agreements between many Ecosystem players, and allow for optimal flexibility, Mechanisms and Conventions are required. They will reduce the complexity of multiple, bi-lateral agreements.

Trust Providers

Since there are multiple Issuers and multiple Verifiers in ecosystems, and Verifiers may operate multiple independent Readers, there must be Mechanisms to distribute public keys to participants in the ecosystem. These Mechanisms may have controls placed on them as to how public keys can be included in the mechanism. As mentioned above, a List Provider can establish Conventions by policy or law that define these controls and determine how participants become members of their Trust List. The Trust List, then, also expresses what it means to be a member of that list so that other participants can trust. Consuming a Trust List reduces independent individual trust relationships because the gathering was performed for participants according to convention.

Fig 3: Wallet Ecosystem with Trust Vectors and associated Mechanisms for conveying trust on these vectors

Issuer List Provider

This is perhaps the most well-known “list” mechanism currently. The Reader must check the cryptographic signature on credential data in order to verify it. Many Readers pull public keys from an Issuer List Provider to perform that verification.

Some Readers have an embedded list or pull an updated list in real time from their services software, In this case the Trust List Publisher is the same entity as the Reader publisher. However, Issuer List Providers are cropping up around the world to publish lists of public keys for Verifiers (a/k/a Relying Parties) to approve and load into their Reader devices.

Multiple Issuer List Providers are expected. For instance, AAMVA in the US, AustRoads in Australia, and eReg in Europe are expected to publish a list of public keys for their Issuers. For businesses with global reach, they may need to set conventions to harmonize lists from multiple Issuer List Providers according to their policy and trust requirements. Similarly, Ecosystem Operators may approve Issuer Trust Lists from multiple other Ecosystems.

Many other Mechanisms are applicable to groups of public keys: PKD Directories, Distributed Ledger, DID-Key Mechanisms, etc.

Reader List Provider

For the Wallet to provide confirmation and information to the User that shows the Reader belongs to the Verifier (is not a rogue) and is operated according to Verifier and Ecosystem policy, it must perform a verification of certificates or cryptographic signatures it receives from the Reader before or during credential requests. Preformulated, bilateral agreements can apply here when the Wallet is expected to reply only to one or more known readers. But in open ecosystems such as our identity document ecosystems today where visual inspection is performed by a Verifier who is handed the document, more flexibility is required.

Ecosystem Operators can decide to become, or can appoint, Registrars who inspect the characteristics of the Verifier (business, agency, individual) in order to include them in a Reader List.

Wallet Attestations

A Wallet should be able to provide a Wallet Attestation to a Reader that identifies its specific instance and information about how it was built, who built it, who authorized it, and what operations it can perform. This can be essential for the Reader to trust any dynamic, transaction time information from the Wallet such as User Authentication. For user authentication after the wallet attestation is presented, the Wallet would match the live holder to the credential and express the result to the Reader for it to evaluate.

Similarly, the Wallet can provide a Wallet Attestation to a Wallet Connector of an Issuer to allow it to verify that the Wallet meets its requirements to provision a credential. This is separate from the process that confirms the identity of the Holder to be the rightful owner of the credential. That process often follows the inspection of the Wallet Attestation. Conceptually this is very similar to above. In order for the Wallet Connector to trust dynamic, registration time information from the Wallet, it must trust the attestation that the software process meets its requirements and that of the ecosystem.

Wallet Attestations are currently being defined, and Lists mechanisms could be utilized similarly to Reader and Issuer Lists in order to allow groupings of Wallets

Federation Login Ecosystems

Utilizing similar terminology to above, Verifiers will often allow online login for access to services on their Website through an external Identity Provider (IDP) also known as a Credential Service Provider (CSP). The Trust Vectors are similar to that of a Wallet Ecosystem.

The Verifier typically chooses the IDP ahead of time, either through a 1:1 tight coupling or by selecting a well-known, reputable identity provider that matches their requirements. The Verifier’s Website obtains certificate and trust information from the IDP by querying Well-Known endpoints of the IDP defined in the Open ID standards. These mechanisms are called Federation Endpoints when they are used by groups of Websites across the same IDP within an Ecosystem. The Ecosystem Operator sets the rules, conventions, and policy that overlay meaning onto the certificates and information that Verifiers can gather from the mechanisms.

1:1 Pairing, RP Operates IDP

Fig 4: Verifier / Relying Party deployed Identity Provider for login to their website for claims or credentials

At transaction time, the Website trusts the Browser to act as the User’s agent and collect Passkeys (credentials) that will unlock the User’s account at the Website. When attribute information is required about the User, the Website can query token and user information endpoints of the IDP that trigger user consent gathering, and then validate the information received using channel authentication or cryptographic validation if the data is signed.

You’ll see that conceptually these are very similar to Wallet Ecosystems but operate in different contexts. Information about the User comes from the IDP in credential form instead of directly from the User in credential form so the cryptographic signature validation has a different path.

Two Additional IDP Pairings

As ecosystems evolve, Issuers (sometimes Governmental Issuers) are deploying Open ID Identity Providers (IDPs). These can have the advantage of being an implementation of the Rules and Guidelines for a National Ecosystem with accompanying simpler legal agreements. They also can be authoritative sources for attributes given they are closer to Identity Proofing.

Wallet Providers are also deploying Open ID IDPs. These can gain widespread reputational trust or fit specific usable facets of individual holders’ personhood (e.g., LinkedIn for profession). These can have the advantage of being a one-stop shop for Verifier / Relying Parties.

Fig 5: (Government) Issuer deployed Identity Provider that the Verifier trusts for User login to RP website

Fig 6: Wallet deployed Identity Provider where Verifier trusts the IDP for User login (perhaps by reputation)

These three IDP deployment pairings: Verifier/RP, Wallet, and Issuer (including Governmental Issuers) will co-exist. The meaning behind accepting identity credential actions or data from any one of them is different. The policy and guidelines they follow during operation also differ as does their ability to make enforceable rules out of them in conformance with law and the expectation of their users. When you query the Federation endpoint mechanism, what conventions were followed that are providing you your result?

Overlaying Login & Wallet Ecosystems

For more on this section, at concept level, read Combining Login & Wallet.

Current eGov Momentum Using Open ID Login

Multiple Governments are deploying login services for residents and even visitors to their country. Examples include:

• SPID in Italy; ItsMe in Belgium — unlock countrywide service delivery
• ArizonaMVDNow for AZ DOT, one of the first States to roll out mDL
• Estonian eID with card form that matches online account for eEstonia
• With Apps: UAE Pass in United Arab Emirates; SingPass in Singapore.

These are a key starting point toward the combination of in-person, mobile, and web eGovernment services. There are also “decentralized” architectures that can be used in these contexts to identify people, verify credentials, and distribute trust material.

When you overlay a Government login provider with a Government Digital ID document Issuer, you gain additional synergies. If coordinated, it can open service delivery across channels WHILE improving the User’s privacy in their personal business interactions across contexts.

Fig 7: Overlaying a Wallet Ecosystem with a Login Ecosystem does not change the Trust Vectors

Trust Vectors Don’t Change Much

You can see that the Trust Vectors do not change much when you overlay Government Digital ID documents and Government Login. The types of Verifiers change, however. In the Verifier <-> Issuer channel, the Claims delivery, AuthN, and Validate credential actions are complementary to each other. Also interesting to note that the 18013–5:OIDC flow takes a token from the Wallet and allows the Reader to spend the token calling Authorize at the IDP to authenticate the user and release signed claims per the mdoc data model — this is the standard OIDC Core flow.

This configuration is most likely when the Verifier is a government agency or associated entity (they should be purple in Fig 7). I would not expect a commercial Verifier to accept a Government IDP and, conversely, despite the assurance of complete data anonymity when no claims are requested, for an End User to expect to use their Government IDP to log in to a business. The exceptions are well-known regulated transactions that require Government ID like alcohol purchase, online age verification, etc. From a consumer comfort level, most of these are better left to commercial IDP implementations… or authorized aggregators such as specified in UK.

Another Trust Vector to analyze is the parallel between the Wallet Attestation and the Mechanism in use for TLS certificate introspection when creating secure connections from browsers to RP web sites. The parallel to the security of the connection and to the operational trust of the wallet/browser on behalf of the Reader/Website are similar. Further, the Convention for obtaining identifying certificates for websites to present to Users makes operational business sense

Mechanisms and Conventions Become More Complex

Now, however, there are similar Mechanisms for distributing trust and public key material that must be implemented in parallel so that each ecosystem — wallet and login — can function independently. Could they be utilized across the ecosystems? Could a Reader of a wallet credential obtain the Issuer List from the Login IDP well-known endpoints? Or that endpoint redirects the Reader to the Ecosystem service, directory, ledger?

Key here is to establish conventions that make it simple for Verifiers to obtain what they need for omni-channel service delivery without onerous effort, and to make sure that real-time delivery of trust vector materials is efficient and accurate while providing for revocation.

Applying Conventions Across Mechanisms

In either of these types of Ecosystems, I want to point out how important it is for the Ecosystem Operator to establish Conventions for how wallet and federation mechanisms are utilized. The Conventions — the collection of rules, policies, and guidelines for inclusion in a mechanism — become the reason components can trust each other and verify assurances of that trust in real time.

As an example in a Wallet Ecosystem, AAMVA in the US has publicly posted their Mobile Driver’s License Implementation Guidelines that express the rules, policies, and guidelines that AAMVA will enforce before allowing an mDL Credential Issuer to place their public key in AAMVA’s Trust List that they call Digital Trust Service. Verifiers can choose to load AAMVA’s Trust List (in VICAL format) into their Readers to verify cryptographic signatures on mDL. In addition, User’s have assurances of the behavior of Issuers that provision their mDL.

Questions of Readers of this Blog Post

These questions are here so that you can comment on this post or send email to the author to assist in gathering information about the Mechanisms available and the Conventions for utilizing those mechanisms. These do NOT have to have been developed in any particular standards body or type of standards organization… looking to list optimal solutions in order to inform Ecosystem Operators of their best options in mixed standards environments. ISO, W3C, and OpenID credential ecosystems that are already converging for interoperability.

Are there any other Trust Vectors overlooked?

What Trust List types are being standardized? Additional Attestations? Additional Categories of Trust Mechanisms?

These can come from Wallets, Federations, Verifiable Credentials, and other Trust Coordination Bodies that have created mechanisms or the conventions surrounding those mechanisms. The goal is to write these up.

What Standards Bodies are Creating Mechanisms for Lists, Groups, or Attestations?

What Conventions make most sense to guide the use of these mechanisms?

Are you an authority on standards for any mechanism that purports to carry trust for one of these Trust Vectors?

If so, can you assist in describing the mechanism for your vector in two paragraphs? Further, can you help to determine Conventions for utilizing your mechanism or point to Ecosystems that are establishing those conventions?