ISO/IEC 26451:2026

• Status: Published
• Publication Date: 02-Nov-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 03-Nov-2026
• Completion Date: 03-Nov-2026

International
Standard
ISO/IEC 26451
First edition
Information technology — Eclipse
2026-11
decentralized claims protocol
Reference number
© ISO/IEC 2026
All rights reserved.
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued by ISO,
an ISO member body, or an authorized third-party distributor.
Except as required for implementation or expressly permitted by a separate licence, no part of this ISO publication may be
reproduced, distributed, modified, used, or made available in any form or by any means – electronic or mechanical, including
photocopying, scanning, recording, or posting on internal or external digital platforms.
Any use beyond the scope of the granted rights is prohibited and may result in legal action.
ISO copyright office
CP 401 • CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Eclipse Decentralized Claims Protocol - v1.0
This document is licensed under The Apache License, Version 2.0.
Abstract
Dataspaces require the ability to communicate participant identities and credentials to secure
data access. This specification defines a set of protocols for asserting participant identities,
issuing verifiable credentials, and presenting verifiable credentials using a decentralized
architecture for verification and trust.
Table of Contents
1. Abstract
2. 1. Terminology
a. 1.1 Claim
b. 1.2 DID
c. 1.3 Holder
d. 1.4 Issuer
e. 1.5 Resource
f. 1.6 Subject
g. 1.7 Verifiable Credential
h. 1.8 Verifiable Presentation
i. 1.9 Verifiable Data Registry
j. 1.10 Verifier
3. 2. Dataspace Ecosystem Overview
a. 2.1 Interrelation to the Dataspace Protocol
b. 2.2 Systems
i. 2.2.1 Dataspace Governance Authority Systems
ii. 2.2.2 Participant Agent Systems
iii. 2.2.3 Credential Issuer Systems
4. 3. Trust Model and Information Flow Architecture
a. 3.1 Consent
b. 3.2 Trust Relationships
c. 3.3 Transport Security
5. 4. Base Concepts
© ISO/IEC 2026 – All rights reserved
iii
a. 4.1 Decentralization
b. 4.2 Identities
c. 4.3 Self-Issued ID Tokens
i. 4.3.1 Verifiable Presentation Access Token
ii. 4.3.2 Obtaining Self-Issued ID Tokens
iii. 4.3.3 Validating Self-Issued ID Tokens
d. 4.4 Schemas, Contexts, and Message Processing
i. 4.4.1 The Decentralized Claims Protocol Context
e. 4.5 The Base URL
6. 5. Verifiable Presentation Protocol
a. 5.1 Presentation Flow
b. 5.2 Credential Service Endpoint Discovery
c. 5.3 Credential Service Security
i. 5.3.1 Submitting an Access Token
d. 5.4 Resolution API
i. 5.4.1 Presentation Query Message
ii. 5.4.2 Presentation Response Message
iii. 5.4.3 Presentation Validation
7. 6. Credential Issuance Protocol
a. 6.1 Issuance Flow
b. 6.2 Issuer Service Endpoint Discovery
c. 6.3 Issuer Service Base URL
d. 6.4 Credential Request API
i. 6.4.1 Credential Request Message
e. 6.5 Storage API
i. 6.5.1 Credential Message
ii. 6.5.2 Credential Container
f. 6.6 Credential Offer API
i. 6.6.1 Credential Offer Message
ii. 6.6.2 CredentialObject
g. 6.7 Issuer Metadata API
i. 6.7.1 IssuerMetadata
h. 6.8 Credential Request Status API
i. 6.8.1 CredentialStatus
© ISO/IEC 2026 – All rights reserved
iv
i. 6.9 Key Rotation and Revocation
i. 6.9.1 Key rotation
ii. 6.9.2 Key revocation
j. 6.10 Verifiable Credential Revocation
8. 7. Conformance
9. A. Profiles of the Decentralized Claims Protocol
a. A.1 DCP Profile Definitions
i. A.1.1 Homogeneity requirement
b. A.2 Profile Authoring Recommendations
10. B. Notes
a. B.1 List of Figures
11. C. References
a. C.1 Normative references
b. C.2 Informative references
© ISO/IEC 2026 – All rights reserved
v
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Eclipse Foundation AISBL (as Eclipse Decentralized claims Protocol v1.0)
and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 26451:2026(en)

Information technology — Eclipse decentralized claims protocol
1. Terminology
The following terms are used to describe concepts in this specification.
1.1 Claim
An assertion made about a Subject (1.6).
1.2 DID
A decentralized identifier as defined by Decentralized Identifiers (DIDs) v1.0.
1.3 Holder
An entity that possesses a set of identity resources as defined by the VC DataModel version of the
selected profile (A). The holder will typically be the subject of a Verifiable Credential (1.7).
1.4 Issuer
An entity that asserts claims (1.1) about one or more subjects by issuing a Verifiable Credential (1.7)
to a Holder (1.3).
1.5 Resource
A resource is an entity managed by the Credential Service such as a Verifiable Credential (1.7) or
Verifiable Presentation (1.8).
1.6 Subject
The target of a set of claims contained in a Verifiable Credential (1.7) as defined by the VC
DataModel version of the selected profile (A). In a dataspace, a subject will be a participant.
1.7 Verifiable Credential
A tamper-evident credential whose authorship can be cryptographically verified as defined by the
VC DataModel version of the selected profile (A).
1.8 Verifiable Presentation
A tamper-evident presentation of information whose authorship can be cryptographically verified
as defined by VC DataModel version of the selected profile (A).
1.9 Verifiable Data Registry
Maintains identifiers such as DIDs (1.2) and Verifiable Credential (1.7) schemas in a dataspace.
© ISO/IEC 2026 – All rights reserved
1.10 Verifier
An entity that receives a Verifiable Credential (1.7), optionally presented inside a Verifiable
Presentation (1.8) as defined by the VC DataModel version of the selected profile (A).
2. Dataspace Ecosystem Overview
This section describes the core actors and systems in a dataspace ecosystem that are pertinent to
this specification. It adheres to the model defined by the Dataspace Protocol [dsp-base]:
• A Dataspace is a policy-based data sharing context between two or more entities.
• The Dataspace Governance Authority is responsible for operational management of a
dataspace (2), including participant (2) registration and designation of trust credential
issuers.
• A Participant is a member of the dataspace (2). Members MAY take on different roles, which
are attested to by verifiable credentials.
• A Participant Agent performs tasks such as publishing a catalog or engaging in data transfer.
Note that a participant agent is a logical construct and does not necessarily correspond to a
single runtime process.
• An Identity Provider is a service that generates identity tokens used to verify the identity of a
Participant Agent (2). Each participant (2) will use their own identity provider to generate a
self-signed identity token.
• A Credential Issuer issues Verifiable Credentials (1.7) used by participant agents (2) to allow
access to assets and verify usage control.
2.1 Interrelation to the Dataspace Protocol
The Dataspace Protocol (DSP) [dsp-base] is designed as a layered protocol, which is independent
of the identity and trust system used. The Decentralized Claims Protocol fills this gap by providing
such an orthogonal overlay for identity and trust in a decentralized manner.
2.2 Systems
2.2.1 Dataspace Governance Authority Systems
Registration System
The registration system is responsible for participant (2) registration, onboarding, and management
in a dataspace. The registration system is run by the Dataspace Governance Authority (2) and is
outside the scope of this specification.
2.2.2 Participant Agent Systems
Participants (2) will run one or more agent systems that interact in the dataspace. These systems
MAY offer data catalogs, perform data transfers, or provide application functionality. A participant
(2) MAY run the following identity-related agents. Note that this is a logical description and MAY not
represent an actual deployment topology.
© ISO/IEC 2026 – All rights reserved
Security Token Service (STS).
The STS creates self-issued authorization tokens that contain identity claims used by participant
agents (2) under the control of the same participant (2).
Credential Service (CS)
The CS manages Verifiable Credentials (1.7). This includes read and write endpoints for Verifiable
Presentations (1.8) and Verifiable Credentials (1.7).
DID Service (DIDS).
The DIDS creates, signs, and publishes DID documents.
2.2.3 Credential Issuer Systems
Issuer Service (IS)
The Issuer Service is run by a trust anchor and manages the lifecycle of Verifiable Credentials (1.7)
in a dataspace. A dataspace MAY contain multiple Issuer Services run by different trust anchors.
The Issuer Service:
• Issues Verifiable Credentials (1.7) for dataspace participants (2).
• Manages revocation lists for Verifiable Credentials (1.7) types it issues based on Verifiable
Credentials Status List v2021.
• Provides cryptographic material used to verify Verifiable Presentations (1.8) and Verifiable
Credentials (1.7).
3. Trust Model and Information Flow Architecture
This specification is based on the Issuer-Holder-Verifier model as described in the VC DataModel
version of the selected profile (A):
Issuer Issue credentials Holder Present credentials Verifier
Acquires and
Verifies VCs
Issues VCs
presents VCs
Register identifiers Verify identifiers
Verify identifiers
and use schemas and use schemas
and use schemas
Verifiable Data Registry
Maintains identifiers and schemas

Figure 1 The Issuer-Holder-Verifier Model
In this model, the Issuer (1.4) creates a Verifiable Credential (1.7) and provides it to the Holder (1.3),
which can then present the Verifiable Credential (1.7) to the Verifier (1.10).
The Verifier (1.10) decides which Verifiable Credentials (1.7) it will accept and the Holder (1.3)
decides which Verifiable Credentials (1.7) it will present. All parties rely on a Verifiable Data
Registry (1.9) to obtain identifier information and metadata about Verifiable Credentials (1.7), such
as schemas. Furthermore, parties communicate with each other using the protocols defined in the
Dataspace Protocol specification [dsp-base] and this specification.
© ISO/IEC 2026 – All rights reserved
The Issuer-Holder-Verifier model is mapped to the following architecture in this specification:
Issuer Holder Verifier
Issues VCs Verifies VCs
Acquires and presents VCs
Dataspace
Issue token
Protocol
Participant
Participant
Agent Agent
STS
Verify token
DCP Presentation
Issuer
Credential
Service
Service
DCP Issuance
Update DID document
Use schemas DID
Service
Verify identifiers Register identifiers Verify identifiers
and use schemas and use schemas
Verifiable Data Registry
Maintains identifiers and schemas

Figure 2 Information Flow Architecture
• Identity and claims information is exchanged between a Holder (1.3) and a Verifier (1.10) in
the context of Dataspace Protocol message interactions [dsp-base]. These messages will
contain metadata such as Offers and Agreements that determine the Verifiable Credentials
(1.7) a Holder (1.3) MUST present to a Verifier (1.10).
• The Issuer Service (2.2.3) issues credentials to a Holder (1.3)'s Credential Service (2.2.2)
using the protocol defined in Section 6. Credential Issuance Protocol. As part of this
process, the Issuer Service (2.2.3) will verify the Holder (1.3)'s identifier using the Verifiable
Data Registry (1.9). Since DID (1.2)s are mandatory in this specification, the registry will be
used to resolve the Holder (1.3)'s DID document and cryptographic material.
• The Holder (1.3) runs three logical services: a Participant Agent (2), an STS (2.2.2), and a
Credential Service (2.2.2). The Participant Agent (2) engages in dataspace communications
with the Verifier (1.10) agent [dsp-base]. As part of these interactions, the Participant Agent
(2) will include a Self-Issued ID Token as defined in Section 4.3 Self-Issued ID Tokens. This
token will be obtained from the STS (2.2.2) controlled by the Holder (1.3). Note that the STS
(2.2.2) is an internal system and therefore out of scope for the current specification. It
MAY be a standalone service or part of the Participant Agent (2) or Credential Service
(2.2.2). The Self-Issued ID Token will contain an access token bound to the Verifier (1.10)
that will be used to request a Verifiable Presentation (1.8). The Holder (1.3)'s Credential
Service (2.2.2) will verify the access token with the STS (2.2.2).
• The Verifier (1.10) runs a Participant Agent (2) that engages in dataspace message
exchanges with the Holder (1.3) agent [dsp-base]. When it receives a request, it will resolve
the Holder (1.3)'s DID document from the Verifiable Data Registry (1.9). The Participant
Agent (2) will resolve the Credential Service (2.2.2) endpoint from the DID document. The
Participant Agent (2) will send a request for a Verifiable Presentation (1.8) to the Credential
Service (2.2.2) using the protocol defined in Section 5. Verifiable Presentation Protocol. This
request will include the access token as a claim in the Self-Issued ID Token received from
the Holder (1.3)'s agent. The Participant Agent (2) will then match the credentials returned in
© ISO/IEC 2026 – All rights reserved
the Verifiable Presentation (1.8) against the policy constraints associated with the original
dataspace request.
3.1 Consent
Consent is the process where the Holder (1.3) approves the release of a Verifiable Presentation
(1.8) and the Verifier (1.10) agrees to allow access to a protected resource. Since the Dataspace
Protocol is built on machine-to-machine message exchange patterns, presentation protocols that
rely on end-user (i.e., human) consent are not applicable. The protocols defined in this
specification establish consent in the following way:
Holder Verifier
Participant Agent
Dataspace
Self-Issued
Protocol
Participant
ID token with
Agent
access token
Consent
Consent
STS
Verify token
DCP Presentation
Credential
Service
Policy-to-
Policy-to-
credential
credential
mappings
mappings
Verifiable Data Registry
Maintains identifiers and schemas
Register policies
and credential
mappings
Dataspace Governance
Policy
Authority
Verifiable
Defines Policies and Credentials
Credential
Figure 3 Consent in the Decentralized Claims Protocol
Consent is handled by first mapping Dataspace Protocol Offer and Agreement policies [dsp-base]
to a set of REQUIRED Verifiable Credentials (1.7). The exact mappings are dataspace-specific as
policies and Verifiable Credentials (1.7) are typically defined for a particular domain. The
expectation is that these mappings are made available by the Dataspace Governance Authority (2)
to Participant Agents (2) via the Verifiable Data Registry (1.9). Verifiable Credential (1.7) mapping is
© ISO/IEC 2026 – All rights reserved
done by both the Holder (1.3) and Verifier (1.10) Participant Agent (2) when a Dataspace Protocol
message is sent and received.
When sending a Dataspace Protocol message, the Holder (1.3)'s Participant Agent (2) will
determine the REQUIRED Verifiable Credentials (1.7) and issue a Self-Issued ID Token request to
the STS (2.2.2), including the list of credentials to allow the Verifier (1.10) to access via the
Credential Service (2.2.2). The returned Self-Issued ID token will contain an access token bound to
the Verifier (1.10) as described above. This access token serves as a verifiable mechanism the
Credential Service (2.2.2) uses to determine consent and release credentials to the Verifier (1.10).
The Verifier (1.10) establishes consent by performing the same mapping from metadata to a set of
Verifiable Credentials (1.7) during the initial Dataspace Protocol request. At that point, the Verifier
(1.10) Participant Agent (2) can query the Credential Service (2.2.2) for a Verifiable Presentation
(1.8). If it matches the REQUIRED credentials, the Verifier (1.10) can consent and grant access to
the associated protected resources.
3.2 Trust Relationships
Trust in the Issuer-Holder-Verifier model is established in different ways between each entity. This
section identifies key aspects of those trust relationships.
All Entities
All entities expect:
• The Verifiable Data Registry (1.9) to be tamper-evident and correctly reflect data controlled
by all entities. This MAY be done through the use of cryptographic resources.
• All Verifiable Credentials (1.7) and Verifiable Presentations (1.8) to be tamper-proof and
support revocation.
• Dataspace Protocol interactions and those defined in this specification to be secure and
use Transport Level Security.
Issuer
The Issuer (1.4) expects:
• Credential Service (2.2.2) integrity, i.e. that Verifiable Credentials (1.7) are securely stored
and the service does not reveal data to unauthorized parties.
Holder
The Holder (1.3) expects:
• The Dataspace Governance Authority (2) to provide a secure list of trusted Issuer (1.4) DID
(1.2)s. How this list is provided is out of scope of the current specification but MAY be part of
the Verifiable Data Registry (1.9).
• The Dataspace Governance Authority (2) to provide a secure list of participant DIDs (1.2).
How this list is provided is out of scope of the current specification but MAY be part of the
Verifiable Data Registry (1.9).
• The Credential Service (2.2.2) to maintain integrity and not release data to unauthorized
parties.
© ISO/IEC 2026 – All rights reserved
• The Issuer (1.4) to issue credentials correctly, including binding them to the holder in a
tamper-proof way, and maintaining credential integrity.
• The Verifier (1.10) not to leak information to third-parties.
Verifier
The Verifier (1.10) expects:
• The Dataspace Governance Authority (2) to provide a secure list of trusted Issuer (1.4) DID
(1.2)s. How this list is provided is out of scope of the current specification but MAY be part of
the Verifiable Data Registry (1.9). Verifiers (1.10) can recognize several Dataspace
Governance Authorities (2).
• The Issuer (1.4) to issue credentials correctly, including binding them to the holder in a
tamper-proof way, and maintaining credential integrity.
3.3 Transport Security
All participants MUST communicate via HTTPS [rfc9110].
4. Base Concepts
This section defines the core identity concepts used by the current specification.
4.1 Decentralization
Decentralization is achieved in the following ways:
• Self-Issued ID Tokens - Each participant (2) is responsible for creating and
cryptographically signing its own identity tokens. A central identity provider is therefore not
required, eliminating a potential source of network failure.
• Participant Verifiable Credential and Cryptographic Material Management - Each
participant (2) is responsible for storing Verifiable Credentials (1.7) and presenting them as
Verifiable Presentations (1.8). Participant (2) are also responsible for storing and making
their cryptographic material available to Verifiers (1.10). This specification defines how
Verifiable Credentials (1.7) are presented and verified without the need for a third-party
verification service.
• Multiple Trust Anchors - Participant (2) Verifiable Credentials (1.7) are signed by a third-
party issuer (1.4) acting as a trust anchor using a cryptographic proof. This specification
allows for multiple trust anchors in a dataspace.
4.2 Identities
The Dataspace Protocol specification mandates that all participants have a stable identifier
(Participant ID). This specification prescribes the Participant ID MUST be a DID (1.2).
© ISO/IEC 2026 – All rights reserved
4.3 Self-Issued ID Tokens
Participants (2) use a Self-Issued ID Token to authenticate themselves and present self-attested
claims to a Verifier (1.10). A Self-Issued ID Token is represented as a JSON Web Token [rfc7519]
signed with a private key under the participant's control.
The following claims MUST be included in the Self-Issued ID Token:
• The iss and sub claims MUST be equal and set to the bearer's (participant's) DID (1.2).
• The aud MUST be set to the Verifier (1.10) DID (1.2).
• The jti claim MUST be used to mitigate against replay attacks.
• The exp claim MUST be used to express the expiration time on or after which the ID Token
MUST NOT be accepted by the verifier (1.10). Implementers MAY provide for some leeway to
account for clock skew. Its value is a JSON [rfc8259] number representing the number of
seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.
• The iat claim MUST be used to specify the time the JWT was issued. Its value is a JSON
number representing the number of seconds from 1970-01-01T00:00:00Z as measured in
UTC.
4.3.1 Verifiable Presentation Access Token
A Self-Issued ID Token MAY contain an access token as a token claim that can be used by the
Verifier (1.10) to obtain Verifiable Presentations (1.8) from the participant's Credential Service
(2.2.2). The format of the token is implementation-specific and therefore SHOULD be treated as an
opaque string by the Verifier (1.10).
4.3.2 Obtaining Self-Issued ID Tokens
This section is non-normative.
How a Self-Issued ID token is obtained from a Secure Token Service (2.2.2) is implementation-
specific. An STS (2.2.2) MAY support a variety of APIs, including OAuth 2.
4.3.2.1 Using the OAuth 2 Client Credential Grant
A Self-Issued ID Token MAY be obtained by executing a Client Credential Grant as defined in The
OAuth 2.0 Authorization Framework against a Secure Token Service (2.2.2) endpoint. How the
participant agent (2) obtains the STS (2.2.2) endpoint address is implementation-specific and
beyond the scope of this specification.
If an token is REQUIRED to be included in the Self Issued ID token, the participant agent (2) will
need to request scopes for the access token. This is dependent on the API used to obtain the Self-
Issued ID Token. An STS (2.2.2) implementation MAY use endpoint parameters as defined in the
The OAuth 2.0 Authorization Framework to convey metadata necessary for the creation of the
token claim. In this case, the Self-Issued ID Token request MAY contain a bearer_access_scope
authorization request parameter set to a list of space-delimited scopes the token claim will be
enabled for. If no bearer_access_scope parameter is present, the token claim SHOULD not be
included.
© ISO/IEC 2026 – All rights reserved
Note
A non-normative OpenAPI spec of an STS (2.2.2) implementing client credentials flow is provided
here
4.3.3 Validating Self-Issued ID Tokens
The Verifier (1.10) MUST validate the Self-Issued ID Token using the following steps:
1. The Verifier (1.10) MUST assert that the iss and sub claims have the same DID value.
2. The Verifier (1.10) MUST assert that the aud claim is set to the Verifier (1.10) DID (1.2).
3. The Verifier (1.10) MUST validate the signature of the Self-Issued ID token by using a key
obtained from the resolved sub DID Document. DID (1.2) resolution is performed according
to the DID (1.2) Method specified by the sub claim. The resolved DID document is processed
to retrieve the value of the verificationMethod property.
o The signing key MUST have capabilityInvocation verification relationship with the
DID.
o If no kid token header is specified and the verificationMethod property contains
one entry and the entry has the capabilityInvocation verification relationship, the
verification method is used.
o If no kid token header is specified and the verificationMethod property contains
more than one entry, the token is rejected.
o If a kid token header is specified, the verification material from the entry
corresponding the kid token header is used. Furthermore, this verification material
MUST have capabilityInvocation verification relationship.
o If no matching entry is found, the token is rejected.
4. The Verifier (1.10) MUST assert that the sub claim value equals the id property in the DID
Document.
5. The Verifier (1.10) MUST assert the nbf claim if present. The Verifier (1.10) MAY allow for
some leeway to account for clock skew.
6. The Verifier (1.10) MUST assert that the current time is before the time represented by the
exp claim. The Verifier (1.10) MAY allow for some leeway to account for clock skew. The iat
claim MAY be used to reject a token that was issued much earlier than the current time,
thereby limiting the amount of time a jti value needs to be stored.
7. The Verifier (1.10) MUST assert that the jti claim value has not been used previously.
4.4 Schemas, Contexts, and Message Processing
All protocol messages are normatively defined by a [json-schema]. This specification also uses
JSON-LD 1.1 and provides a Json-Ld context to serialize data structures and message types as it
facilitates extensibility. The Json-Ld context is designed to produce message serializations using
compaction that validate against the Json Schema for the given message type. This allows
implementations to choose whether to process messages as plain Json or as Json-Ld and maintain
interoperability between those approaches. Extensions that use Json-Ld are encouraged to provide
similar contexts that facilitate this approach to interoperability.
© ISO/IEC 2026 – All rights reserved
4.4.1 The Decentralized Claims Protocol Context
The JSON-LD 1.1 context URI for the specification is: https://w3id.org/dspace-
dcp/v1.0/dcp.jsonld. Future specification releases SHALL reuse the versioning schema
according to the Semantic Versioning definitions, concatenated to a vMAJOR.MINOR number. The
current specifications use 1.0 version.
4.5 The Base URL
All endpoint URLs in this specification are relative. The base URL MUST use the HTTPS scheme. The
base URL is implementation-specific and MAY include additional context information such as a
sub-path that disambiguates a holder.
5. Verifiable Presentation Protocol
This section defines a protocol for storing and presenting Verifiable Credentials (1.7) and other
identity-related resources. The Verifiable Presentation Protocol covers the following aspects:
• Endpoints and message types for storing identity resources belonging to a Holder (1.3) in a
Credential Service (2.2.2)
• Endpoints and message types for resolving an identity Resource (1.5)
• Secure token exchange for restricting access to Credential Service (2.2.2) endpoints
Note
The Verifiable Presentation Protocol is designed to address the problem of resolving Verifiable
Presentations (1.8) and other claims when they cannot be passed as part of a client request. For
example, they often cannot be included as part of an HTTP message header due to size restrictions.
The protocol provides a secure mechanism for a Verifier (1.10) to resolve credential-related
resources. The protocol also provides a mechanism for storing issued Verifiable Credentials (1.7).
5.1 Presentation Flow
The following sequence diagram depicts a non-normative flow where a client interacts with a
Verifier (1.10) to present a Verifiable Credential (1.7):
Client Entity Verifier Entity
Client Secure Token Service DID Service Credential Service Verifier
1 request
2 response incl. access token
3 request w/ self-issued id token incl. access token
4 resolve DID
5 DID document response
6 request w/ self-issued id token incl. access token
7 VP response
8 response
Client Secure Token Service DID Service Credential Service Verifier

Figure 4 Presentation Flow
© ISO/IEC 2026 – All rights reserved
1. The client sends a request to its Secure Token Service (2.2.2) for a Self-Issued ID Token (4.3)
including an access token. The API used to make this request is implementation specific.
The client MAY include a set of scopes that define the Verifiable Presentations (1.8) the
client wants the Verifier (1.10) to have access to. This set of scopes is determined out of
band and MAY be derived from metadata the Verifier (1.10) has previously made available to
the client.
2. The Secure Token Service (2.2.2) responds with a Self-Issued ID Token (4.3) that MAY
include an access token in the token claim.
3. The client makes a request to the Verifier (1.10) for a protected resource and includes a Self-
Issued ID Token (4.3) containing the access token.
4. The Verifier (1.10) resolves the client DID (1.2) based on the value of the Self-Issued ID
Token (4.3) sub claim.
5. The DID Service (2.2.2) returns the DID Document. The Verifier (1.10) validates the Self-
Issued ID Token (4.3) following Section 4.3.3 Validating Self-Issued ID Tokens.
6. The Verifier (1.10) obtains the client's Credential Service (2.2.2) endpoint address using the
DID document as described in Section 5.2 Credential Service Endpoint Discovery. The
Verifier (1.10) then issues a request bearing a Self-Issued ID Token (4.3) of their own to the
Credential Service (2.2.2).If present in the client's initial Self-Issued ID Token (4.3), the
access token MUST be contained in the Credential Issuer (2)'s Self-Issued ID Token (4.3)
token claim.
7. The Credential Service (2.2.2) validates the Self-Issued ID Token (4.3) and, if present, the
access token. It returns a Verifiable Presentation (1.8) containing the requested credentials.
5.2 Credential Service Endpoint Discovery
The client DID Service (2.2.2) MUST make the Credential Service (2.2.2) available as a service
entry (Decentralized Identifiers (DIDs) v1.0, sect. 5.4) in the DID document that is resolved by its
DID (1.2). The type attribute of the service entry MUST be CredentialService. The
serviceEndpoint property MUST be interpreted by the Verifier as the base URL of the Credential
Service (2.2.2). The following is a non-normative example of a Credential Service entry:
Example 1: Credential Service Entry in DID document
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
],
"service": [
{
"id": "did:example:123#identity-hub",
"type": "CredentialService",
"serviceEndpoint": "https://cs.example.com"
}
]
}
© ISO/IEC 2026 – All rights reserved
5.3 Credential Service Security
As described in the previous presentation flow, a Credential Service (2.2.2) MAY REQUIRE an
access token when processing a request from a Verifier (1.10). The format of the access token is
not defined. How access control is defined in a Credential Service (2.2.2) is implementation-
specific. For example, implementations MAY provide the ability to selectively restrict access to
resources.
5.3.1 Submitting an Access Token
Implementations that support access control require an access token. To provide the opportunity
for Credential Service (2.2.2) implementations to enforce proof-of-possession, the access token
MUST be contained in the token claim of a Self-Issued ID Token as defined in Section 4.3 Self-
Issued ID Tokens. The Self-Issued ID Token (4.3) MUST be submitted in the HTTP Authorization
header prefixed with Bearer of the request.
5.4 Resolution API
The Resolution API defines the Credential Service (2.2.2) endpoint for querying credentials and
returning a set of Verifiable Presentations (1.8).
If a client is not authorized for an endpoint request, the Credential Service (2.2.2) SHOULD return
4xx Client Error. The exact error code is implementation-specific.

Sent by Verifier (1.10)
POST
HTTP Method
/presentations/query
URL Path
PresentationQueryMessage (5.4.1)
Request
Response PresentationResponseMessage (5.4.2) HTTP 2xx OR HTTP 4xx
5.4.1 Presentation Query Message

Schema JSON Schema
REQUIRED - @context: Specifies a valid Json-Ld context ([json-ld11], sect. 3.1)
- type: A string specifying the PresentationQueryMessage type.
OPTIONAL - scope: A non-empty array of scopes corresponding to Section 5.4.1.2 Scopes.
- presentationDefinition: A non-empty, valid Presentation Definition according
to [presentation-ex].
A PresentationQueryMessage MUST contain either a presentationDefinition or a scope
parameter. If both parameters are present it is an error and the server MUST return an HTTP 400
BAD REQUEST response.
© ISO/IEC 2026 – All rights reserved
The following are non-normative examples of the JSON body:
Example 2: PresentationQueryMessage with scope
{
"@context": [
"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
],
"type": "PresentationQueryMessage",
"scope": [
"presentation1",
"presentation2"
]
}
Example 3: PresentationQueryMessage with presentationDefinition
{
"@context": [
"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
],
"type": "PresentationQueryMessage",
"presentationDefinition": {
"id": "presentation1",
"input_descriptors": [
{
"id": "organization credential",
"format": {
"ldp_vc": {
"proof_type": [
"Ed25519Signature2018"
]
}
},
"constraints": {
"fields": [
{
"path": [
"$.type"
],
"filter": {
"type": "string",
"pattern": "OrganizationCredential"
}
}
]
}
}
]
}
}
© ISO/IEC 2026 – All rights reserved
5.4.1.1 Presentation Definitions
An implementation MAY support the presentationDefinition parameter. If it does not, it MUST
return 501 Not Implemented. The presentationDefinition parameter contains a valid
Presentation Definition according to the Presentation Exchange Specification. The Credential
Service (2.2.2) will use the presentation definition to return a set of matching VPs in the format
specified by the definition.
5.4.1.2 Scopes
Implementations MAY support requesting presentation of Verifiable Credentials (1.7) using a set of
scope values. A scope is an alias for a well-defined Presentation Definition. The specific scope
value and the mapping between it and the respective Presentation Definition are out of the scope
of this specification. The array MUST contain at least one value. If the array is empty, the Credential
Service (2.2.2) MUST return HTTP 4xx. If the array contains scopes that a client is not entitled to,
the Credential Service (2.2.2) MUST return HTTP 2xx with the PresentationResponseMessage
(5.4.2)'s presentation array holding less entries than requested.
A scope is a string value in the form:
[alias]:[descriminator]
The [alias] value MAY be implementation-specific.
The org.eclipse.dspace.dcp.vc.type Alias
The vc.type alias value MUST be supported and is used to specify access to a verifiable credential
by type. For example:
org.eclipse.dspace.dcp.vc.type:Member
denotes read-only access to the VC type Member and MAY be used to request a VC or VP.
The org.eclipse.dspace.dcp.vc.id Alias
The org.eclipse.dspace.dcp.vc.id alias value MUST be supported and is used to specify access
to a verifiable credential by id. For example:
org.eclipse.dspace.dcp.vc.id:8247b87d-8d72-47e1-8128-9ce47e3d829d
denotes read-only access to the VC identified by 8247b87d-8d72-47e1-8128-9ce47e3d829d and
MAY be used to request a Verifiable Credential (1.7).
5.4.2 Presentation Response Message

Schema JSON Schema
REQUIRED - @context: Specifies a valid Json-Ld context
([json-ld11], sect. 3.1).
- type: A string specifying the
PresentationResponseMessage type.
© ISO/IEC 2026 – All rights reserved
- presentation: An array of Verifiable
Presentations (1.8). The Verifiable Presentations
(1.8) MAY be strings, JSON objects, or a
combination of both depending on the format.
OPTIONAL - presentationSubmission: A valid
Presentation Submission according to
[presentation-ex].
A PresentationResponseMessage SHOULD only include valid (non-expired, non-revoked, non-
suspended) credentials. The following are non-normative examples of the JSON response body:
Example 4: Presentation Response Message
{
"@context": [
"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
],
"type": "PresentationResponseMessage",
"presentation": [
"presentation1",
"presentation2"
]
}
Example 5: Presentation Response Message with Presentation Submission
{
"@context": [
"https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
],
"type": "PresentationResponseMessage",
"presentation": [
"jwtPresentation"
],
"presentationSubmission": {
"id": "Presentation example 2",
"definition_id": "Example with multiple VPs",
"descriptor_map": [
{
"id": "id_credential",
"format": "jwt_vp",
"path": "$.presentation[0]",
"path_nested": {
"id": "id_nested_credential",
"format": "jwt_vc",
"path": "$.vp.verifiableCredential[0]"
}
}
]
}
}
© ISO/IEC 2026 – All rights reserved
5.4.2.1 Presentation Submissions
Implementations that support the presentationDefinition parameter MUST include the
presentationSubmission parameter in the 5.4.2 Presentation Response Message with a valid
Presentation Submission when a presentationDefinition is provided in the 5.4.1 Presentation
Query Message.
5.4.3 Presentation Validation
Verifier (1.10) SHOULD validate the Verifiable Presentation (1.8) in the following manner:
1. The Verifier (1.10) MUST assert that the Verifiable Presentation (1.8) is created either
according to the scope or presentationDefinition
2. The Verifier (1.10) MUST validate the signature of the Verifiable Presentation (1.8) by using
the key obtained from the resolved VerificationMethod of the Verifiable Presentation (1.8).
DID (1.2) resolution is performed according to the DID (1.2) Method specified in the DID (1.2)
part of the VerificationMethod of the Verifiable Presentation (1.8).
3. The Verifier (1.10) MUST validate that the VerificationMethod of the Verifiable Presentation
(1.8) has the Authentication Verification Relationship
4. The Verifier (1.10) MUST assert that the DID (1.2) in the VerificationMethod of the Verifiable
Credential (1.7) has the same value as the issuer of the Verifiable Credential (1.7).
5. The Verifier (1.10) MUST validate the signature of the Verifiable Credential (1.7) by using the
key obtained from the resolved VerificationMethod of the Verifiable Credential (1.7). DID
(1.2) resolution is performed according to the DID (1.2) Method specified in the DID (1.2)
part of the VerificationMethod of the Verifiable Presentation (1.8).
6. If the Verifiable Credential (1.7) contains a revocation mechanism, such as StatusList2021,
the Verifier (1.10) MUST validate the status of the Verifiable Credential (1.7) according to the
revocation mechanism.
7. If the Verifiable Presentation (1.8) contains any claims regarding its expiryDate or validity,
the Verifier (1.10) MUST validate those claims.
8. If any of the steps fail, the Verifier (1.10) MUST consider the Verifiable Presentation (1.8)
invalid.
Additionally, if the specific semantics of a data space and credentials require cryptographic holder
binding, the Verifier (1.10) MUST assert that the credentialSubject.id in the Verifiable Credential
(1.7) and the DID (1.2) part of the VerificationMethod of the Verifiable Presentation (1.8) have the
same value.
6. Credential Issuance Protocol
The Credential Issuance Protocol defines the endpoints and message types for requesting
Verifiable Credentials (1.7) from a Credential Issuer (2). The protocol is designed to handle use
cases where credentials can automatically be issued and where a manual workflow is REQUIRED.
© ISO/IEC 2026 – All rights reserved
6.1 Issuance Flow
The following sequence diagram depicts a non-normative flow where a client interacts with a
Credential Issuer (2) to issue a Verifiable Credential (1.7):
Client Entity Issuer Entity
Client Secure Token Service DID Service Credential Service Issuer Service
1 request
2 response incl. access token
3 request credential(s) w/ self-issued ID token incl. access token
4 resolve DID
5 DID document response
6 ack
(async) write credential(s)
w/ self-issued ID token access token
Validate token and
store credentials
Client Secure Token Service DID Service Credential Service Issuer Service

Figure 5 Issuance Flow
1. The client sends a request to its Secure Token Service (2.2.2) for a Self-Issued ID Token (4.3)
including an access token. The API us
...