Credential is my new favourite polyseme in digital identity.

In the real world, the Oxford Dictionary of English defines it as “a qualification, achievement, quality, or aspect of a person’s background” or a “document proving a person’s identity or qualifications”. It stems from the Latin verb credo, which can be translated as believing, confiding in, entrusting, and lending.

So a credential refers to both the phenomenon and its physical evidence. This evidence is a representation mediating between person identification or qualification (a social construct) and administrative practice (operational procedures). It affords users the capability to access its properties through processes such as issuance, holding, presentation, and validation. Though it can be entrusted or lent to a holder, it is never truly owned by them. The dual meaning causes no confusion in practice, since we typically speak only of credentials for which we assume we could find evidence. Interestingly, we usually speak of credentials in the plural – perhaps because a single credential gains trust only when corroborated by another.

In the digital world, the word got used in two developments that occurred since the 1960s. In essence, credentials operate either as representations of trust (evidential) or as performances of recognition (simulative).

The first is digitalising documents: the dematerialisation of the credential as representation. We first experienced electronic credentials as magnetic stripe cards, and then digital documents protected by computational secure areas. Let’s call these evidential credentials: the representation evidences trust in administrative practice by asserting identity attributes or qualifications. It is still mediating between the social construct and the mechanics, but now relying on computational media.

The second is implementing logical access control: the simulation of credentials as the institutional trust phenomenon, governing access to resources. We first used passwords as credentials to time-sharing systems. Later we applied protocols such as Kerberos to produce more granular credentials in distributed systems, and anti-cloning devices such as the SIM to protect credentials to access mobile networks. Let’s call these simulative credentials: the credential simulates the role of physical means of recognition for person identification and qualification, to enable efficient access to digital resources.

If we want to understand and design for digital identity wallets, we should map these concepts across bounded contexts. How many meanings can we find?

In entity authentication as per ISO/IEC 29115, credentials are simulative. These originate from some credential service provider, who either provides the credential or means to produce credentials. The relying party relies on identity claims (from claimants) or assertions (from identity providers) after corroboration of identity information by one or more verifiers. In this framework, credentials are not:

• activation data, such as the passcode or biometrics to prevent unauthorised use of the means;
• associated data, such as the certificate or attestation from an identity provider or a trusted third party;
• verification data, such as the public key the verifier uses to verify digital signatures as credentials;
• assertion data, such as the (protected) statement from the identity provider to the relying party after successful verification by the verifier.

In EU digital identity as per (EU) 910/2014, nobody speaks of credentials. Instead, natural and legal persons get an identification means, which maps to one or more entity authentication “credentials or means to produce credentials”. Additionally, natural and legal persons get e-attestations and certificates, which are representative credentials.

In US digital identity as per NIST SP 800-63-4, the experts replace the high-level principles with stricter rules:

• an authenticator is something the person controls: an entity authentication “credential or means to produce credentials”;
• an authenticator output is simulative: verifiable data produced by the authenticator;
• a credential is always representative: a credential service provider binds an identifier to one or more authenticators;
• an attribute bundle is also representative: a credential service provider packages identifiers and/or other attributes.

With this decoupling, they clarify what is not related to any type of credential:

• an activation factor is a PIN or biometric characteristics to prevent unauthorised use of the authenticator;
• an assertion is the statement from the identity provider to the relying party.

These concepts help model the EU digital identity wallets. Such a model includes several types of entities:

• identity provider (IdP): wallet component with trusted authenticator (“wallet secure cryptographic application” or WSCA);
• subscriber: a wallet user, enrolled at the identity provider with either the identity provider’s authenticator (when local) or their own (when remote);
• identifier provider (IP): credential service provider for credentials, binding subscriber identifier (“person identification data”) to the identity provider’s authenticators;
• attestation provider (AP): credential service provider for attribute bundles, binding subscriber attributes to the identity provider’s authenticators;
• relying party (RP): an identified and qualified natural or legal person.

When presenting data to a relying party, we see several credentials-as-authenticator-outputs and credentials-as-documents:

1. The IdP authenticates the RP’s identity using their credential, produced using a key certified for access.
2. The IdP authenticates the subscriber’s identity using their credential, produced using a key in the trusted component.
3. The RP authenticates the IdP’s identity using their credential, produced using the same or another key in the trusted component.
4. The IdP asserts the identifier and/or attributes to the RP, evidenced by credentials-as-documents, enforcing any configured disclosure policies.
5. The RP authenticates the identities of the IP and APs using their credentials, produced using keys certified for issuance.

In Internet engineering as per IETF RFC 4949, the simulative meaning of credential is explicitly rejected. Instead, credentials either represent an identifier (e.g. X.509 public key certificates) or an authorization (e.g. X.509 attribute certificates). But that rejection is from 18 Internet engineering years ago, which amounts to 85–125 human years.

In Web apps as per W3C Credential Management Level 1, credentials can be representative:

• digital credential: an issuer-signed digital document matching a US attribute bundle;
• federated credential: an origin configuration bound to a web-provided identity.

They can also be simulative:

• identity credential: an entity authentication assertion provided by a remote identity provider;
• (one-time) password credential: client-provided data for server-side authentication;

Or even both:

• public key credential: sometimes a private key (source data to produce entity authentication credentials), sometimes a public key (associated data for verifiers), sometimes an attestation (representative credential), and sometimes a signed “assertion” which is in terms of entity authentication closer to credentials than to assertions.

Indeed the Web got quite tangled. Luckily the W3C managed to make all of it work over a single abstraction. However, on the fringes of W3C (VCDM, DID) this becomes more challenging:

• verifiable credential: basically a W3C digital credential, typically held in a wallet;
• verifiable presentation: basically an entity authentication assertion with associated data;
• decentralized identifier document: basically a US digital identity credential.

Additionally, OpenID for Verifiable Presentations 1.0 introduces the non-verifiable presentation of verifiable credentials. This provides claims with associated data to relying parties without an entity authentication assertion.

Bounded contexts become easier to work with when they have a clear focus.

In mobile documentation as per ISO/IEC 18013-5, the mdoc is representative – in US terms, a credential or attribute bundle. The mdoc is under local access control, requiring holder and reader authentication before returning an assertion with selectively disclosed associated data. Reader authentication is specified using digital signatures as simulative credentials, and holder authentication is up to the applicable entity authentication assurance framework.

In remote e-signing as per CSC API v2, a credential is a remotely accessed resource that combines the private key with the public key and its certificate. Sounds complicated, but the outcome is simple: credentials are used representatively to validate e-signatures and e-seals. Since they are managed remotely, logical access control applies, potentially applying any of the concepts above.

In summary, we can give clearer names to the digital duality we already identified in the physical world:

• Entity authentication – credentials afford real-world entities the capability to present themselves as digital entities, simulating the role of physical means of recognition.
• Digital documentation – credentials afford digital entities the capability to present and rely on identity attributes or qualifications, evidencing trust in administrative practice.