Identity

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

The tdx Volt 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 tdx Volt itself) is public key cryptography.

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

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

This proof is usually achieved by the identity signing some message or claim with its private key, which tdx Volt 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 tdx Volt 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 tdx Volt.

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 tdx Volt 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 tdx Volt. See the DID Registry section for more information.

Authentication

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

The tdx Volt 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 tdx Volt must present a credential that has been issued by the tdx Volt CA, or by some other tdx Volt that is trusted.

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

There are varying degrees of trust implemented, for example a tdx Volt 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 tdx Volt 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 tdx Volt management interface as well as any service registered with the tdx Volt 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 tdx Volt 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 tdx Volt 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 tdx Volt 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 tdx Volt 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 tdx Volt.

• Alice’s tdx Volt starts its grpc service using a certificate issued by her tdx Volt CA
• Bob issues a call to Alice’s tdx Volt service. As part of the call Bob mandates that the server must present a credential issued by the tdx Volt CA. Bob also sends his own credential to the server, which has been issued by Alice’s tdx Volt CA.
• Alice’s tdx Volt receives Bob’s request and verifies that a credential was presented, and that it chains to the tdx Volt CA.
• Alice’s tdx Volt 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 tdx Volt 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 tdx Volt 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 tdx Volt 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 tdx Volt 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, tdx Volt services can support a combination of authentication mechanisms tailored to suit their individual requirements.