Credential packaging models

An iSHARE participant is described by the same underlying information: who they are, which dataspaces they participate in, and how they comply with the iSHARE framework. That information can be packaged into Verifiable Credentials in more than one way, and the right choice depends on how much flexibility, privacy and operational simplicity a deployment needs.

Why three models?

The models all carry the same claims. They differ in how those claims are grouped into signed credentials, which changes four things: who is able to issue each part, how much a holder has to put into a presentation, how independently each part can be revoked, and how much there is to manage. There is no single best answer, so iSHARE defines three points along that trade-off rather than forcing one.

Moving from Model 1 to Model 3, credentials get larger and fewer: the number of possible issuers goes down and the amount that must travel in a presentation goes up, while simplicity of issuance, presentation and verification goes up. Identity (the party credential) is treated as a shared building block and is normally issued once, independently of whichever model is used.

How the three models package the same claims The same participant claims packaged into ten separate credentials in Model 1, two domain credentials in Model 2, and one combined credential in Model 3. MODEL 1 Fully modular party membership ds-role ds-agreement fw-role fw-agreement fw-compliance auth-registry x509-cert idp-assertion 10 separate credentials MODEL 2 Semi-modular Dataspace participation membership · roles · agreements Framework Compliance roles · agreements · certs · IdP Party credential external · shared MODEL 3 Consolidated Trusted Participant credential identity frameworks [ ] dataspaces [ ] More granular · more flexible Fewer credentials · simpler
The same participant data, packaged into progressively fewer credentials.

Who issues what

Packaging decides issuance. Because a credential is signed as a whole, every claim inside it is attested by the same issuer, so grouping claims together forces a single issuer to be authoritative for all of them. Splitting them apart allows each claim to come from the authority that is genuinely authoritative for it, and lets a dataspace decide how many issuers it wants to operate.

Which issuers sign which credentials in each model In Model 1 up to five different authorities each sign their own claim credentials. In Model 2 one issuer signs each domain credential. In Model 3 a single issuer signs one credential covering the whole participant. ISSUER SIGNS MODEL 1 · FULLY MODULAR Dataspace authority Scheme / party registry Certificate authority Identity provider Authorisation registry ds-membership ds-role ds-agreement party fw-role fw-agreement fw-compliance x509-cert idp-assertion auth-registry 10 credentials · up to 5 different issuers · each claim signed by the authority that is authoritative for it The dataspace chooses how far to split, and may collapse several of these onto one issuer for operational efficiency. MODEL 2 · SEMI-MODULAR Dataspace authority Scheme authority External / shared Dataspace participation credential membership · roles · agreements Framework Compliance credential framework roles · agreements · certificates · IdP Party credential identity · issued once, reused across models 2 domain credentials · one issuer per domain · each issuer must be authoritative for its whole domain MODEL 3 · CONSOLIDATED Single issuer Trusted Participant credential identity + frameworks [ ] + dataspaces [ ] 1 credential · 1 issuer · that issuer must be authoritative for the entire participant
Who signs what. Splitting credentials multiplies the possible issuers; combining them concentrates authority in one.
Model 1

Fully modular

Every claim is its own standalone credential: the base party credential for identity, plus one credential each for dataspace membership, dataspace role, dataspace agreement, framework role, framework agreement, framework compliance, authorisation registry, X.509 certificate and IdP assertion.

Best for: deployments that need the finest possible presentations and independent lifecycles, where a holder may present a single fact and issuers need to revoke one claim without touching the rest. Well suited to claims that come from different authorities.

Who issues it: a collection of credentials gathered from various issuers, or from the same issuer where that is more practical. Each claim can be signed by the authority that is actually authoritative for it, so certificates can come from a certificate authority, IdP assertions from an identity provider, delegation evidence from an authorisation registry, and dataspace facts from the dataspace itself. Nothing forces this split: the same issuer may sign several of these credentials, which means each dataspace can decide how far to distribute issuance based on its own operational efficiency.

In iSHARE: this is the model that lets a dataspace place issuance where the authority already sits, rather than routing everything through one registry. It matches the way iSHARE roles are distributed in practice, since the party registry, the identity provider and the authorisation registry are already distinct roles held by distinct parties.

Advantages

  • Only the claim credentials a verifier actually needs go into the presentation.
  • Each credential is issued, renewed and revoked on its own.
  • Different issuers can be responsible for different claims, each signing only what it is authoritative for.
  • Each dataspace can choose how many issuers to operate, collapsing or distributing issuance as it prefers.
  • Smallest data footprint per interaction.

Disadvantages

  • Many credentials to issue, store and keep track of.
  • Verifiers check more signatures, and must trust each issuer for its part.
  • More status lists and revocation endpoints to operate, and more issuers to onboard and govern.
Model 2

Semi-modular

The minimum set of claims grouped by domain into two credentials: a dataspace participation credential (membership, roles and agreements) and a Framework Compliance credential (framework roles, agreements, certificates and IdP assertions). Neither credential carries identity attributes; both identify the subject by credentialSubject.id alone. In this model a participant either uses an existing identity credential issued by a trusted third party identity issuer, or receives an iSHARE Party ID credential along with its Framework Compliance credential.

Best for: most deployments. It keeps the two concerns that tend to have different owners and lifecycles, dataspace participation and framework compliance, as separate credentials, without the overhead of a credential per claim.

Who issues it: one issuer per domain. The dataspace authority signs dataspace participation, and the scheme level authority signs Framework Compliance. Identity is issued separately rather than embedded: a participant that already holds an identity credential from a trusted third party identity issuer keeps using it, and one that does not is issued an iSHARE Party ID credential alongside its compliance credential at onboarding. Keeping identity out of the compliance credential means a verifier always reads identity from one place, and a change of name reissues only the Party ID credential. This follows the governance boundary: framework compliance is established once at the organisation level and reused across dataspaces, while participation is specific to each dataspace. Each issuer must be authoritative for everything inside its own credential, but not beyond it.

In iSHARE: the split matches who owns the information. Compliance with the framework is a scheme level statement, so it is reused unchanged when a party joins an additional dataspace, and only a new dataspace participation credential is issued. It also means a dataspace never has to attest to framework compliance it does not govern.

Advantages

  • Far fewer credentials than the fully modular model.
  • Dataspace and framework concerns can be issued and revoked independently.
  • The dataspace authority and the framework authority can each own their credential, with no issuer attesting outside its remit.
  • Framework compliance is issued once and reused across dataspaces.

Disadvantages

  • The whole domain credential travels in a presentation even when only one attribute from it is required.
  • Revoking one fact means revoking the whole domain credential.
Model 3

Consolidated

Everything combined into a single participant credential, with all frameworks and dataspaces carried as arrays under one subject. One credential describes the whole participant.

Best for: the simplest deployments, where a single authority is able to attest to the whole participant. Easiest to issue, hold, present and verify.

Who issues it: a single issuer, typically the party registry, signs everything. Because one signature covers identity, framework compliance and every dataspace, that one issuer has to be authoritative for all of it, including facts that originate elsewhere such as certificates or delegation evidence. Distributing issuance is not possible in this model; the trade for that is a single trust relationship for the verifier to manage.

In iSHARE: this is the closest fit to how participant information is served today, where one registry returns a single authoritative record describing the whole party. It maps most directly onto the existing party information API, so it is the least disruptive starting point, at the cost of concentrating every attestation in one issuer.

Advantages

  • One credential to issue, store, present and verify.
  • A single status entry covers the whole participant.
  • One trust relationship and one issuer to onboard.
  • Lowest management and integration overhead.

Disadvantages

  • The entire credential must be sent in a presentation even when a verifier needs a single attribute. Attribute level hiding within the credential is still possible where a selective disclosure securing mechanism such as SD-JWT is used, but the credential remains the unit of presentation, so there is no way to send only the relevant part.
  • Any change requires reissuing the entire credential.
  • One issuer must be able to attest to everything, including facts that originate with other authorities.

At a glance

Model 1 · Fully modular Model 2 · Semi-modular Model 3 · Consolidated
Credentials One per claim Two, grouped by domain One combined
Issuers Many possible, one per claim or grouped; the dataspace chooses the split One per domain: dataspace authority and scheme authority Single issuer for everything
Each issuer must be authoritative for Only its own claim Its whole domain The entire participant
What must go in the presentation Only the claim credentials actually needed The whole domain credential, even for one attribute The whole participant credential, always
Attribute level disclosure within a credential Available in all three models where a selective disclosure securing mechanism such as SD-JWT is used; it is not what separates them
Revocation Per claim Per domain Whole participant
Management overhead Moderate to highest, depending on how many issuers and status lists are operated Moderate Lowest

Notes for review. The following points are interpretation rather than anything fixed by the schemas, and need confirming:

  1. Issuer role names. All example credentials in the repository currently use the same generic example issuer, so the schemas do not record who issues which credential. The mapping of claims to issuers shown here (dataspace authority, scheme or party registry, certificate authority, identity provider, authorisation registry) is inferred from the claim names and from existing iSHARE roles. Names and boundaries should be confirmed against official terminology.
  2. "Single issuer" in Model 3. Described here as typically the party registry. Confirm the exact role name to use.
  3. SD-JWT. The published examples are secured as vc+jwt, so selective disclosure securing is referred to as a possibility rather than as something the schemas currently commit to. Confirm which securing mechanisms are in scope before this wording is treated as normative.
  4. Management overhead for Model 1 is given as a range, since it depends on how many issuers and status lists a dataspace chooses to operate.

The schemas for all three models, together with the Data Rights credential and the shared building blocks, are listed on the index page.