Verifiable Credential Schemas & Vocabulary
This site contains the schemas and vocabulary supporting Verifiable Credentials in the iSHARE Trust Framework. The schemas are profiles of the W3C Verifiable Credentials Data Model 2.0, extended with the vocabulary that iSHARE adds: data rights, the agreements between organisations, and framework and collaboration roles. iSHARE publishes and maintains the schemas; credentials are issued by certified issuers on the Trusted Issuers List and verified by parties directly, without a central authority at the moment of access.
Data Rights Credential
The Data Rights Credential is where control over data is expressed. It answers one question: what may be done with a specific data resource. The data rights holder states who may access the data, for what purpose and on what terms, as policies, licences and access rules that travel with the credential while the data stays at its source. A data user presents it, together with the participant credentials it requires, to the party that holds the data.
A Data Rights Credential can require conditions of the data user, for example compliance with the Trust Framework, membership of a specific collaboration, or a particular role. Those conditions are proven with the participant credentials described in the next section. The Data Rights Credential is issued and consumed independently of how those participant credentials are packaged.
- datarights/
- context.jsonld – JSON-LD context for Data Rights credentials
- manifest.json – Manifest metadata for Data Rights schema
- schema.json – JSON Schema for Data Rights credentials
Conditions on the data user: participant credentials
Where the Data Rights Credential says what may be done with data, participant credentials say who a party is and what it is compliant with or entitled to do: its identity, its compliance with the Trust Framework, and its participation and role in a collaboration. A Data Rights Credential references these as conditions; the data user proves them by presenting the matching participant credentials. Throughout these schemas, "dataspace" refers to any collaboration operating under the Trust Framework — a data space, a sector initiative, a supply-chain or business network — not to data spaces alone.
Credential packaging models
The same participant data can be packaged as Verifiable Credentials at three levels of granularity. A claim is a single statement about a subject. A credential is the signed envelope that carries one or more claims and can be issued, presented and revoked on its own.
The three models package the same participant information differently, from one credential per claim (maximum flexibility and selective disclosure) to everything in a single credential (simplest to issue and present). All three are valid under the Trust Framework; which one an issuer uses depends on the needs of the collaboration it serves.
Fully modular credentials
Every claim is issued as its own independently revocable credential, giving maximum flexibility and selective disclosure at the cost of more credentials to manage.
- party-id/
- context.jsonld – JSON-LD context for the Party ID Credential
- manifest.json – Manifest metadata for the Party ID schema
- schema.json – JSON Schema for the Party ID Credential
- claims/
- auth-registry/
- context.jsonld – JSON-LD context for Authorization Registry claims
- manifest.json – Manifest metadata for Authorization Registry schema
- schema.json – JSON Schema for Authorization Registry claims
- dataspace-agreement/
- context.jsonld – JSON-LD context for Dataspace Agreement claims
- manifest.json – Manifest metadata for Dataspace Agreement schema
- schema.json – JSON Schema for Dataspace Agreement claims
- dataspace-membership/
- context.jsonld – JSON-LD context for Dataspace Membership claims
- manifest.json – Manifest metadata for Dataspace Membership schema
- schema.json – JSON Schema for Dataspace Membership claims
- dataspace-role/
- context.jsonld – JSON-LD context for Dataspace Role claims
- manifest.json – Manifest metadata for Dataspace Role schema
- schema.json – JSON Schema for Dataspace Role claims
- framework-agreement/
- context.jsonld – JSON-LD context for Framework Agreement claims
- manifest.json – Manifest metadata for Framework Agreement schema
- schema.json – JSON Schema for Framework Agreement claims
- framework-compliance/
- context.jsonld – JSON-LD context for Framework Compliance claims
- manifest.json – Manifest metadata for Framework Compliance schema
- schema.json – JSON Schema for Framework Compliance claims
- framework-role/
- context.jsonld – JSON-LD context for Framework Role claims
- manifest.json – Manifest metadata for Framework Role schema
- schema.json – JSON Schema for Framework Role claims
- idp-assertion/
- context.jsonld – JSON-LD context for Identity Provider Assertion claims
- manifest.json – Manifest metadata for Identity Provider Assertion schema
- schema.json – JSON Schema for Identity Provider Assertion claims
- x509-certificate/
- context.jsonld – JSON-LD context for X.509 Certificate claims
- manifest.json – Manifest metadata for X.509 Certificate schema
- schema.json – JSON Schema for X.509 Certificate claims
- auth-registry/
- examples/
- credentials/party-credential.json – Decoded Party ID (identity) credential payload
- enveloped/party-credential.json – Enveloped Party ID credential
- credentials/claims/ – one decoded credential per claim:
- framework-role-credential.json
- framework-agreement-credential.json
- framework-compliance-credential.json
- dataspace-role-credential.json
- dataspace-agreement-credential.json
- dataspace-membership-credential.json
- x509-certificate-credential.json
- idp-assertion-credential.json
- auth-registry-credential.json
Examples: the Party ID base credential plus one decoded credential per claim are listed above, one worked example for each fully-modular credential type.
Semi-modular credentials
The minimum practical split into two credentials: a Framework Compliance Credential carrying compliance with the Trust Framework (established at the organisation level), and a Dataspace Participant Credential carrying participation in a specific collaboration. Each can be issued and revoked independently. Neither carries identity attributes: a participant either uses an existing identity credential from a trusted third-party identity issuer, or receives a Party ID Credential from its certified issuer together with its Framework Compliance Credential.
- dataspace-participant/
- context.jsonld – JSON-LD context for Dataspace Participant credentials
- manifest.json – Manifest metadata for Dataspace Participant credential schema
- schema.json – JSON Schema for Dataspace Participant credentials
- framework-compliance/
- context.jsonld – JSON-LD context for Framework Compliance credentials
- manifest.json – Manifest metadata for Framework Compliance credential schema
- schema.json – JSON Schema for Framework Compliance credentials
- examples/
- credentials/framework-compliance-credential.json – Decoded Framework Compliance credential payload
- enveloped/framework-compliance-credential.json – Enveloped Framework Compliance credential
- credentials/dataspace-participant-credential.json – Decoded Dataspace Participant credential payload
- enveloped/dataspace-participant-credential.json – Enveloped Dataspace Participant credential
Trusted Participant Credential
All information combined into a single Trusted Participant Credential, with one subject carrying identity plus the frameworks[] and dataspaces[] arrays. Simplest to issue and present; least granular for selective disclosure and revocation. Consolidated refers to the credential, not to the issuer: it is issued by a certified issuer like any other credential under the framework.
- trusted-participant/
- context.jsonld – JSON-LD context for the Trusted Participant Credential
- manifest.json – Manifest metadata for the Trusted Participant Credential schema
- schema.json – JSON Schema for the Trusted Participant Credential
- examples/
- credentials/trusted-participant-credential.json – Decoded Trusted Participant Credential payload
- enveloped/trusted-participant-credential.json – Enveloped Trusted Participant Credential
Shared building blocks
- index.json – Index of available schemas
- common/
- bitstring-status-list-credential.json – JSON Schema for BitstringStatusListCredential Verifiable Credential (W3C Bitstring Status List v1.0)
- credential-status.json – Shared JSON Schema for credentialStatus property using BitstringStatusListEntry (W3C Bitstring Status List v1.0)
- enveloped-verifiable-credential.json – JSON Schema for W3C EnvelopedVerifiableCredential objects
- enveloped-verifiable-presentation.json – JSON Schema for W3C EnvelopedVerifiablePresentation objects
Shared examples
The decoded and enveloped credential payloads are listed under each packaging model above. The examples below are cross-cutting: presentations bundle credentials from more than one model, and the key is used to verify every signed envelope.
- examples/
- README.md – Notes about the v3 example credentials and presentations
- party/
- presentations/
- participant-presentation.json – Verifiable Presentation carrying the enveloped participant credentials
- enveloped-presentations/
- participant-presentation.json – W3C EnvelopedVerifiablePresentation for the combined participant presentation
- presentations/
- keys/
- example-issuer-public-jwk.json – Example public key for verifying the signed example envelopes