Skip to main content
info
IOTA Identity for Rebased is currently in alpha and may still be subject to significant changes

Verifiable Presentations

A verifiable presentation is the recommended data format for sharing one or more verifiable credentials. It is constructed and signed by a holder to prove control over their credentials and can be presented to a verifier for validation.

For instance, after an issuer creates and issues a verifiable credential to a holder, such as a university issuing a degree to a graduate, the holder stores it securely until asked to present it. A company could then request proof of that university degree: the holder can create a verifiable presentation containing their credential, already signed by their university, and present it to the company to validate.

Note that verifiable presentations that contain personal data should, as with verifiable credentials, be transmitted and stored securely off-chain to satisfy data privacy regulations such as GDPR.

note

See the Verifiable Credentials Data Model Specification for more information on verifiable presentations.

Security Considerations​

Replay Attacks​

A malicious actor could potentially store a verifiable presentation without a challenge and replayed to a different verifier, impersonating the holder. This is because the holder's signature on a presentation would still be seen as valid indefinitely, until they rotate the verification method used.

To mitigate this, verifiers should always send a unique challenge when requesting a verifiable presentation. This challenge can be set as the nonce property of the JWS by the holder during signing. The digital signature prevents these properties from being altered as it would invalidate the signature, effectively preventing a malicious actor from injecting different values into old verifiable presentations. A presentation without a challenge in its proof that matches what was sent by the verifier should be considered invalid.

The challenge string should be sufficiently random and unique for each verifiable presentation requested by a verifier to avoid being predicted.

Holders may additionally specify that their signature on a verifiable presentation expires after a short duration, as per JwtPresentationOptions. However, verifiers and different implementations could ignore that property, so setting a signature expiration alone should not be relied upon.