Identity

The following explores in depth how identities are represented in Volt4 and describes the interactions with other elements in the architecture.

The Volt4 identity model is based on the principles of self-sovereign identity (SSI), which is a model for managing digital identities in a way that is secure, private, and decentralized.

Public key cryptography

At the heart of the identity management (and Volt4 itself) is public key cryptography.

All identities known to a Volt4 are associated with one or more public/private key pairs. By default, the Volt4 never stores or even sees the private portion of the key, which must be kept private by the identity. The Volt4 has a copy of the public key(s).

In order to perform any interaction with Volt4, an identity must prove that it is in possesion of the private key corresponding to one of the public keys the Volt4 is holding for that identity.

This proof is usually achieved by the identity signing some message or claim with its private key, which Volt4 can then verify using the public portion of the key. Another method is via an x509 certificate-backed TLS connection, which includes the key verification as part of the handshake.

The Volt4 uses the Edwards-curve Digital Signature Algorithm (EdDSA) by default. This is a modern, secure, and efficient algorithm that is well-suited to the requirements of the Volt4.

Decentralized Identifiers (DIDs)

Internally, an identity is represented by an immutable unique identifier rather than its public key. This is known as a ‘decentralised identifier’ or DID. This level of indirection ensures that an identity can easily periodically change keys as a security precaution or in case of compromise. This also allows for an identity to utilise more than one key pair which might be useful in certain scenarios to limit exposure.

A decentralized identfier, or DID, is a new type of identifier that enables verifiable, self-sovereign digital identity. DIDs are fully under the control of the DID subject, independent of any centralized registry, identity provider, or certificate authority. DIDs are URIs that relate a DID subject to means for trustable interactions with that subject.

For more information, see the W3C Decentralized Identifiers (DIDs) specification.

Each Volt4 maintains a database or registry of DIDs and their associated documents, which in turn contains their public key(s). This registry is used to look up the public key of an identity when it is presented to the Volt4. See the DID Registry section for more information.

Authentication

The core authentication mechanism is based on standard public key infrastructure (PKI) technology.

The Volt4 acts as a certificate authority (CA), issuing verifiable credentials or certificates to clients that request access.

Any client wanting to access resources or services on the Volt4 must present a credential that has been issued by the Volt4 CA, or by some other Volt4 that is trusted.

Each Volt4 maintains a list of public keys that it knows about, and each public key has a mapping to a unique identity within the Volt4. This is known as a DID Registry.

There are varying degrees of trust implemented, for example a Volt4 may be configured to trust a public key to connect to and use services, or it may trust a public key to sign additional public keys for access to the Volt. The latter is achieved in combination with Verifiable Credentials.

This provides a flexible and scalable mechanism of establishing trust, whereby a Volt4 can decide, on a case-by-case basis, to trust any client that presents a credential signed by its own key or that of another trusted identity.

The following notes relate to the core Volt4 management interface as well as any service registered with the Volt4 by other applications/clients.

The Authenticate step

For the purposes of this discussion, a client is, for example, an application that wants to access some resource or service.

When a client first starts it must obtain a credential from the Volt4 in order to be able to connect to any service or resource. It does this by sending an authentication request to the Volt.

The authentication request includes the public key of the client, and a signature. Upon receipt of this request, the Volt4 can infer that the client is in possession of the corresponding private key.

When submitting an authentication request, a client may also supply one or more additional certificates or Verifiable Credentials that can be used to help the Volt decide whether or not to issue a credential. For example, a Samsung device may submit a certificate that chains to the Samsung CA. If the Volt4 has been configured to permit the Samsung CA to authenticate clients, it might automatically issue the credential.

Once in possession of a credential, the client can connect to the Volt. As part of the default TLS mechanism, the client provides one or more root certificates that it trusts. If the Volt4 server does not present a certificate that chains to one of these root certificates the client will abort the call.

For example, Bob (the client) wants to access a resource on Alice’s Volt4.

• Alice’s Volt4 starts its grpc service using a certificate issued by her Volt4 CA
• Bob issues a call to Alice’s Volt4 service. As part of the call Bob mandates that the server must present a credential issued by the Volt4 CA. Bob also sends his own credential to the server, which has been issued by Alice’s Volt4 CA.
• Alice’s Volt4 receives Bob’s request and verifies that a credential was presented, and that it chains to the Volt4 CA.
• Alice’s Volt4 extracts the public key from Bob’s credential and looks it up in the DID Registry. If no matching identity is found (or the identity has been revoked) the call is rejected.
• Alice’s tdxVolt can now provide this identifier to the policy engine, which will determine if Bob has permission to access the resource or service he has requested.

Token authentication

Some grpc platforms do not support client certificate inspection from server implementations. In these scenarios, the client presents a certificate and grpc will enforce and verify the certificate requirement, but the actual service implementation has no visibility of the client certificate that was presented.

This makes it impossible for the service to identify the client without further information provided with the call.

This isn’t a problem for the Volt4 itself which is implemented in C++ and can access the client certificate. However grpc is platform agnostic and third-party services that are registered with the Volt4 may be implemented in any language. These third-party services need to be able to identify the client in order to determine if they have permission to access the service, among other things.

To address this the Volt4 supports additional authentication by way of a JSON Web Token (JWT) that is sent as part of the grpc call metadata, which is available on all platforms.

The JWT contains a claim that identifies the client, which is the resource id that was assigned to the client at the authentication stage. The JWT is then signed by the client private key.

Upon receipt of the token, a server can decode it to extract the resource id and then verify the signature using the client public key, which will be stored alongside the resource id in the Volt4 DID Registry.

This is conceptually very similar to an x509 certificate in the sense that it is binding a public key to some identifier. The key difference is that the use of a client certificate (as used, for example, in TLS) requires the client to be in possession of the private key, whereas a token does not. Tokens are typically obtained through some authentication step that requires the private key or similar verification, and is then used subsequently for repeated calls to an API. It is therefore possible that if a token is misplaced or stolen it can be abused.

There are ways of limiting the vulnerability of tokens such as adding additional claims for expiry and such. In some situations a token is preferable to full- blown PKI, such as when securely storing a private key is impossible or impractical. As such, Volt4 services can support a combination of authentication mechanisms tailored to suit their individual requirements.