Using Vectors of Trust

The Vectors of Trust (VoT) specification provides a simple but still expressive mechanism for measuring trust in an identity transaction. It takes several components of an identity transaction into account. The result is a composable and extensible construct.

The Challenge

After successful authentication, an Identity Provider typically assigns the user some attributes and returns a summary of the identity transaction to the Relying Party. The question is, how can the Relying Party (the client application) check that the identity transaction (the identification, authentication, and the representation of the user) meets specific requirements? These requirements may be: How was the user authenticated? How can the client be sure that the attributes related to the user are accurate? How much can the client trust the data?

The OpenID Connect Core specification defines the amr claim that holds the identifier of one or more authentication methods that the user chose for authentication. Providing this information does answer the question about the authentication, but it fails to give any assertion on the user attributes. Consequently, the OpenID Core standard also specifies the acr claim, which references the business rules that the authentication process satisfied. An example of such requirements is Level Of Assurance (LoA) definitions. Such definitions simplify the complexity of enrollment and authentication into a single digit like 1 (low), 2 (substantial), or 3 (high). Low could mean that the user self-registered on a web page without any identification and authenticates with a username and password. High could require that the user be present in person during enrollment and authenticate with a smart card or similar device. The amr claim can be used to further define how the claim is satisfied. Using a single class to represent the trust is not flexible, though. There can be cases where it is not clear which Level of Assurance to apply. For instance, what is the correct level if the user was personally present during enrollment but used a lower level authentication method?

The Vectors of Trust specification introduces a value that is more expressive than a single digit. Though expressive, a vector is still pretty simple and easy to parse and process. A vector of trust must always be put into context — there must be an accompanying trust framework that defines the values for the vector and its meaning.

Component Architecture

In general, the value for a vector of trust consists of several components represented by an uppercase letter in the range [A-Z] and separated with a dot ("."). Each component can have different levels identified by a single digit in the range [0-9] or a lowercase letter in the range [a-z].

The components may appear in any order, zero or several times but never twice with the same level. For example, "P1.Ca.Cc.Ab" is a valid vector but "Cc.Cc" is not. If a component is omitted from the vector, then the vector does not make any statement about the component as there is explicitly no default value.

It is up to the trust framework to define the components and component values (called levels above). However, the specification recommends reusing component definitions whenever possible and applicable. The standard defines the following four separate components:

• Identity Proofing (P)
• Primary Credential Usage (C)
• Primary Credential Management (M)
• Assertion Presentation (A)

The Identity Proofing (P) dimension is about the identity attributes and how strongly they have been verified. For example, this could indicate if the user had to present a passport during enrollment.

Primary Credential Usage (C) is about the authentication method and describes how strongly the Identity Provider can verify the credential. For example, this can state how easy it is to forge or steal the credential.

Primary Credential Management (M) is about policies and the lifecycle of the primary credential in use. For example, it describes if users can bring their own devices.

The Assertion Presentation (A) dimension defines how the identity assertion (the ID token in OpenID Connect) is transmitted to the Relying Party and how secure that transport is. For example, it can describe if the assertions are signed or encrypted.

OpenID Connect

The client may signal the Identity Provider to enforce a certain vector by providing the vtr claim in the request object. The claim contains a list of the accepted vector of trust values or parts of such. For example, if the client requests "vtr": ["P1.Cc.Ab","Ca"], then the Identity Provider can choose to either fulfill "P1.Cc.Ab" or "Ca".

The Identity Provider processes the request and respects the vtr by selecting an appropriate authentication method and putting the result in the vot claim (the vector of trust value). The Identity Provider must include the vtm claim that contains an HTTPS URL to the description of the vector values. This is the vector trustmark URL. Both claims are part of the ID token and thus signed. The following excerpt of an ID token lists the claims:

{
  "jti": "664629e1-b1b7-4976-866c-d675977777ea",
  "iss": "https://login-demo.curity.io/oauth/v2/oauth-anonymous",
  "aud": "demo-web-client",
  "sub": "test",
  "given_name": "John",
  "amr": "urn:se:curity:authentication:html-form:username-password",
  "acr": "LOA1",
  "vot": "P1.Cc.Ab",
  "vtm": "https://www.rfc-editor.org/rfc/rfc8485"
}

A vector value itself is opaque and additional context is needed for interpretation. To understand the vector in the vtr claim, the Relying Party must be familiar with the description of the values of the trust framework. The link to the description can be found in the vtm claim.

Implementations may support both the acr and vot claim for compatibility reasons. Since the vector value is more informative, it will take precedence over the acr claim, providing that the client supports the Vectors of Trust specification.

Example

The ID token above contains both the acr and vot claims. Clients that support the Vectors of Trust specification can ignore the acr claim and validate the vector value. Clients that do not support the Vectors of Trust specification can still validate the acr claim.

The example vector "P1.Cc.Ab" used throughout this article translates — in the context of the trust framework defined in the specification — to a user with self-asserted attributes, possible pseudonyms ("P1"), who used a shared secret like a username or password ("Cc") to authenticate. "Ab" maps perfectly to an ID token that passed through the front channel (web browser). The vector is missing the Primary Credential Management ("M") component and does not provide any information about the password policy or similar. The user could have provided a very simple and possibly old password. Furthermore, "P1" means that the attributes come from the user. The given_name claim in the ID token listed above may be true or false. All that is known is that the user calls themself "John" and that the user is identified as test throughout the system.

Conclusion

The vector of trust value needs to be placed in context. On the one hand, this makes it hard to implement a general-purpose solution. But on the other, it offers great flexibility. In the end, there is no simple answer to who and what to trust, and each federated system must define its own rules in a trust framework. Within that framework, the Vectors of Trust specification offers a simple and expressive way of measuring trust in an identity transaction.