WE BUILD Attestation Rulebook for attestations of type Membership Credential

This WE BUILD v1 Rulebook specifies the Membership Credential used in the WE BUILD Supply Chain 2 (SC2) MVP scenario "seamless onboarding" piloted by the Data Sharing Initiatives (DSI) DjustConnect (ILVO), DADS (ITC) and Tritom (Dataspace Europe), and the common agriculture dataspace "Agri-X".

• Author(s):
  • Ingo Wolf, Spherity GmbH
  • Martin Domajnko, Lutra Labs d.o.o.

Feedback:

• Main feedback channel: GitHub issues
• Alternative: contact Supply Chain 2 contact points in WE BUILD.

1 Introduction

1.1 Document scope and purpose

The Membership Credential expresses that its holder is a member of a specific Data Sharing Initiative (DSI) or dataspace, which roles the holder has within that DSI or dataspace, and to which dataspace governance rulebook the holder has conformed. It exists to enable seamless onboarding: common information already presented in a previous onboarding flow is trusted and not requested again when the holder onboards into a further DSI or the common dataspace.

In plain language, the credential combines all necessary information about the dataspace or DSI membership into a single attestation held in an EU Business Wallet (EBW), independent of any dataspace-specific connector technology.

• Real-world fact expressed: membership of a DSI or dataspace, the roles held within it (e.g. Data Rights Holder, Data Provider, Data Consumer, Operator, Onboarding Service Provider), and acceptance of the dataspace governance rulebook.
• Issuers: trusted issuers / onboarding service providers (the participating DSIs, or another technology partner acting as onboarding service provider). Agri-X is envisaged as a federation of DSIs; participants join Agri-X via a DSI or directly via a trusted issuer.
• Holders: organisations (legal persons) participating in a DSI or dataspace. The MVP scenario is limited to legal persons.
• Relying parties: DSI / dataspace platforms and participants that verify membership and roles during onboarding. Use during data-sharing transactions is a potential future application and is out of scope for this pilot: a data-transfer flow would likely require the Membership Credential to be transformed into a connector-native credential (for instance an EDC / dataspace protocol participant credential) rather than presented directly.
• Use case: WE BUILD SC2 "seamless onboarding" piloted by DjustConnect (ILVO), DADS (ITC) and Tritom (Dataspace Europe), targeting the common agriculture dataspace "Agri-X".
• Source document: MVP Membership credential — attestation description.

The schema is designed to be re-usable and interoperable with other dataspaces. It is aligned with the membership credential used within Catena-X; attributes that must remain interoperable with such operational dataspaces are marked as dataspace-specific (DS-specific) terminology that SHALL NOT be renamed.

1.2 Document structure

• Chapter 2, which describes the attestation attributes and metadata in an encoding-independent manner.
• Chapter 3, which specifies how the attestation attributes and metadata are encoded in case the attestation complies with [ISO/IEC 18013-5] and/or [SD-JWT VC] and/or [W3C VCDM v2.0]. Each encoding SHALL be specified in a separate section, or even in a separate chapter.
• Chapter 4, which specifies attestation usage.
• Chapter 5, which defines how trust anchors for attestation verification can be obtained.
• Chapter 6, which defines attestation revocation mechanisms.
• Chapter 7, which provides compliance information.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], i.e., to indicate requirements, recommendations and options specified in this document.

In addition, 'must' (non-capitalised) is used to indicate an external constraint, i.e., a requirement that is not mandated by this document, but, for instance, by an external document. The word 'can' indicates a capability, whereas other words, such as 'will', and 'is' or 'are' are intended as statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF.

2 Attestation attributes and metadata

Chapter overview and requirements

This chapter is used for defining all attributes that an attestation of the defined type may contain. In this section the attributes SHALL be defined in an encoding-independent manner (see ARB_06 in [Topic 12]). Each attribute can be mandatory, optional, or conditional and this SHALL be specified in the corresponding section (see ARB_09 in [Topic 12]).

When attributes are defined, referring to attributes that already exist in a catalogue of attestation attributes SHOULD be considered (see ARB_07 in [Topic 12]).

Where use-case documentation or an attestation description already defines attribute meanings, logical models, code lists, or integrity constraints, authors SHOULD align terminology with those sources and may copy and refine that material for this Rulebook.

[Topic 12] of Annex 2 of the ARF defines the following High-Level Requirements with respect to the Attestation Rulebooks:

Requirements for QEAA

• An attribute as meant in Annex V point a) of the [European Digital Identity Regulation] SHALL be included (see ARB_11 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex V point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_13 in [Topic 12])
• One or more attributes representing the set of data meant in Annex V point c)
  of the [European Digital Identity Regulation] SHALL be included (see ARB_16 in [Topic 12]).
• One or more attributes or metadata representing the set of data meant in Annex V point e) of the [European Digital Identity Regulation] SHALL be included (see ARB_18 in [Topic 12]).
• One or more attributes or metadata representing the location meant in Annex V point h) of the [European Digital Identity Regulation] SHALL be included. This location SHALL indicate at least the URL at which a machine-readable version of the trust anchor to be used for verifying the QEAA can be found or looked up (see ARB_20 in [Topic 12]).

Requirements for PuB-EAA

• An attribute as meant in Annex VII point a) of the [European Digital Identity Regulation] SHALL be included (see ARB_11 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex VII point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_14 in [Topic 12]).
• One or more attributes representing the set of data meant in Annex VII point c) of the [European Digital Identity Regulation] SHALL be included (see ARB_16 in [Topic 12]).
• One or more attributes or metadata representing the set of data meant in Annex VII point e) of the [European Digital Identity Regulation] SHALL be included (see ARB_18 in [Topic 12]).
• one or more attributes or metadata representing the location meant in Annex VII point h) of the [European Digital Identity Regulation] SHALL be included. This location SHALL indicate at least the URL at which a machine-readable version of the qualified certificate that signed the PuB-EAA can be found or looked up. (see ARB_20 in [Topic 12])

Requirements for non-qualified EAA

• An attribute indicating that the attestation is an EAA should be included (see ARB_12 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex V point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_15 in [Topic 12]).
• One or more attributes representing the set of data meant in Annex V point c) of the [European Digital Identity Regulation] SHOULD be included (see ARB_17 in [Topic 12])
• One or more attributes representing the set of data meant in Annex V point e) of the [European Digital Identity Regulation] SHOULD be defined (see ARB_19 in [Topic 12]).
• One or more attributes or metadata representing the location at which a machine-readable version of the trust anchor to be used for verifying the EAA can be found or looked up SHOULD be defined. What this location indicates precisely is dependent on the nature of the mechanism used for distributing trust anchors, detailed in section 5 (see ARB_21 in [Topic 12])

2.1 Introduction

The Membership Credential is a non-qualified EAA. This document defines the attribute attestationLegalCategory which SHALL have the value EAA. It qualifies the attestation as a whole rather than the member, and is therefore carried at credential level, outside the credential subject; in the W3C VCDM encoding the credential-level type SHALL include ElectronicAttestationOfAttributes, which is what defines the attribute. See Section 3.3.2.

The credential describes the member (the CredentialSubject) together with the dataspace governance rulebook the member conforms to (termsOfUse), the roles the member has within the DSI or dataspace (role), and the platform through which the member was onboarded (onboardedBy). Separately, at credential level, evidence records the identification means by which the holder's identity was proven during the initial onboarding process.

Logical model. The Membership Credential is structured as follows:

• The credential subject is identified by id (a UUID, may change) and member, an object of type EconomicOperator carrying the stable identifier of the holder in legalIdentifier; for the MVP this re-uses the EUID from the EUBWOID of that economic operator.
• memberOf names the DSI or dataspace the membership is for.
• role is an array of roles the holder has within that DSI or dataspace. The membership and its set of roles share the same lifecycle: a change of roles requires re-issuance of the credential.
• termsOfUse is an object of type GovernanceRulebook referencing the accepted dataspace governance rulebook (URL, version, SHA-256 hash, and acceptance datetime).
• holderIdentifier optionally carries the identifier by which the onboarding platform refers to the holder, where that differs from member.legalIdentifier. It sits alongside memberOf on the credential subject, because it describes the holder rather than the platform.
• onboardedBy is an object of type Platform identifying the onboarding party: the platform's identifier (platformId) and commercial name, and the operator — the economic operator hosting and running the platform.
• evidence records the identification means used to prove the holder's identity during the initial onboarding process, for example the VAT identifier presented in a paper-based onboarding flow. It is credential metadata about the issuance, not an attribute of the subject, and is therefore carried at credential level rather than inside the credential subject (Section 2.6).

Note that evidence describes how the holder was identified, whereas onboardedBy describes the platform and the organisation that performed the onboarding. Keeping the two apart is deliberate: an identifier recorded as evidence belongs to the holder, never to the platform operator. As a side effect, evidence also bridges the EU-level identifier in member.legalIdentifier to a legacy or platform-local identifier of the same holder, which may not be recognisable or interoperable outside the onboarding platform; see IR-03 and IR-04 for the limits on that use.

Standard credential metadata (issuer, issuance time, expiry, status) follows from the chosen VC format and is documented in Chapter 3 rather than as attributes here. Each Membership Credential has its own unique identifier.

DS-specific terminology. Attributes marked (*) below (id, member, memberOf) keep their names for cross-dataspace interoperability (e.g. with Catena-X) and SHALL NOT be renamed. For extensibility purposes the JSON Schema definition allows additional properties in the onboardedBy data type definition.

Subsections 2.2 - 2.7 define the attributes and metadata in an encoding-independent manner. Code lists are in Section 2.8 and integrity rules in Section 2.9. The structured objects termsOfUse and onboardedBy are defined as sub-tables in Section 2.2; evidence is defined in Section 2.6.

2.2 Mandatory attributes of object Membership

2.2.1 termsOfUse object of type GovernanceRulebook

2.2.2 onboardedBy object of type Platform

This object identifies the onboarding party: which platform performed the onboarding and which legal entity hosts it. Example reading: "DjustConnect, a platform hosted by ILVO, onboarded farmer XYZ."

Identifiers of the holder are not carried here. The identifier by which the onboarding platform refers to the holder is holderIdentifier at credential-subject level (Section 2.3), and the identification means used to prove the holder's identity is evidence at credential level (Section 2.6). The only identifier in this object, operator.identifier, belongs to the organisation hosting the platform.

2.2.3 EconomicOperator object

Used by member (the holder) and by onboardedBy.operator (the organisation hosting the onboarding platform). Identifier values follow the European Business Wallet Vocabulary pattern for identifiers: a typed literal whose datatype is the identifier scheme. See Section 2.8.

2.3 Optional attributes

This attribute belongs to the Membership credential subject, alongside the mandatory attributes of Section 2.2. It describes the holder, not the onboarding platform, and is optional: an issuer populates it only where the onboarding platform holds an identifier for the holder other than the one in member.legalIdentifier.

The scheme of the value is not stated by a separate attribute. It follows from the onboarding platform, which onboardedBy identifies (Section 2.2.2): a Relying Party that knows the platform knows which identifier that platform issues. Where the scheme has to be stated explicitly and machine-readably, evidence carries it as the datatype of a typed literal (Section 2.6.1).

The holder's official name is carried by member.legalName (Section 2.2.3).

Relationship to evidence (Section 2.6). The two are distinct and may both be present. holderIdentifier is the identifier the onboarding platform uses operationally to refer to the holder — the value that appears in that platform's own APIs and records. evidence records the identification means by which the holder's identity was proven at onboarding. In practice a platform will often use the same value for both, for instance a VAT identifier that was both checked during onboarding and used as the platform's reference thereafter. Where an issuer has only one of the two facts, it SHOULD populate only the corresponding attribute rather than duplicating the value into both.

2.5 Mandatory metadata

Standard VC metadata (issuer, issuance time, expiry, status, credential id) is provided by the chosen VC format and specified per encoding in Chapter 3. This Rulebook defines one additional mandatory metadata attribute.

2.6 Optional metadata

2.6.1 evidence attribute

Each evidence entry records one identification means presented by, or verified for, the holder during the initial onboarding process — for example the VAT identifier checked in a paper-based onboarding flow. evidence is optional; where the onboarding platform holds such a record, the issuer SHOULD include it.

evidence describes the holder. It SHALL NOT be used to carry an identifier of the onboarding platform or of its operator; those belong in onboardedBy (Section 2.2.2). See IR-03 and IR-04.

2.7 Conditional metadata

2.8 Code lists

The following code lists apply to attributes defined in Section 2. Lists are kept fit-for-pilot: they cover the minimal set needed by the three participating DSIs and are not exhaustive.

memberOf — fixes the DSI or dataspace the holder is a member of. The value is agreed at the governance level of the DSI or dataspace itself and registered in the code list below, as a URL under that DSI's or dataspace's own domain. Uniqueness therefore rests on domain ownership, and two DSIs cannot collide by independently choosing the same label.

The memberOf property is typed @id in the European Business Wallet Vocabulary, so the value is an absolute IRI and expands to a node reference, {"@id": "https://agri-x.eu"}. A Relying Party matches it by exact IRI comparison. The value need not dereference to anything, and a Relying Party SHALL NOT depend on it resolving. A relative value SHALL NOT be used: it would be resolved against the document base, so the same credential would yield different IRIs depending on where it was retrieved from. A new DSI or dataspace SHALL register its IRI in this code list before issuing.

role — roles a member can have. A member may have multiple roles in one credential. Based on the common roles agreed across the piloting DSIs, treating Agri-X as a federation of DSIs.

The role property is typed @id in the European Business Wallet Vocabulary, so each value is an absolute IRI and expands to a node reference. The values below are the DataSpaceRole individuals published in that vocabulary, under the https://w3id.org/ebwv# namespace. A relative value such as DataRightsHolder SHALL NOT be used: it would be resolved against the document base, so the same credential would yield different role IRIs depending on where it was retrieved from.

Because values are IRIs, a DSI MAY mint an additional role under a namespace it owns without any change to this Rulebook, to the JSON Schema, or to the vocabulary context, and a Relying Party MAY trust roles by namespace prefix rather than enumerating each value. Roles minted outside https://w3id.org/ebwv# are governed by the minting DSI's own trust framework; see Section 5. New roles intended for common use across the piloting DSIs SHOULD still be published as DataSpaceRole individuals by the WE BUILD Semantics work group and registered here.

Identifier schemes — the datatype of an identifier typed literal, wherever one appears: member.legalIdentifier, onboardedBy.operator.identifier and evidence.identifier. The European Business Wallet Vocabulary publishes these as named individuals used as datatypes, in the pattern {"@type": "VatId", "@value": "…"}.

Not every identification means in the pilot has a published scheme. The KMG-MID used by the DADS platform (unique farm id issued by the Slovenian Ministry of Agriculture) and any purely platform-specific identifier have no individual in the vocabulary. Until one is published, such a value SHALL be carried as an untyped string — "identifier": "1234567" — which is valid and expands correctly but does not record the scheme. Publishing KmgMid, a generic PlatformSpecific scheme, and an OnboardingEvidence class is the recommended vocabulary addition.

No code list applies to holderIdentifier (Section 2.3). Its scheme is not stated by a separate attribute: it follows from the onboarding platform identified by onboardedBy. Where the scheme has to be stated explicitly, the identifier is carried as evidence instead, using the schemes in the table above.

A common code list distinguishing Legal Person from Natural Person identifiers is being prepared by the WE BUILD Semantics work group. It is not required for this version: the MVP scenario pilots legal persons only. Values will be added once provided.

2.9 Integrity rules

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

Not applicable for this version. The Membership Credential is used in online onboarding flows; no proximity / offline presentation requirement applies (ARB_02). The primary format is W3C VCDM (JSON-LD), see Section 3.3, with SD-JWT VC considered as an additional flow (Section 3.2). No ISO/IEC 18013-5 mdoc document type is defined.

3.2 SD-JWT VC-based encoding

Considered as an additional flow (not the primary format for the MVP). The Membership Credential MAY additionally be piloted as an SD-JWT VC. If issued in this format, attestations SHALL comply with the 'SD-JWT VCs' profile specified in [HAIP] (ARB_01b). This Rulebook follows the catalog baseline of [HAIP] draft-03 and [SD-JWT VC] draft-ietf-oauth-sd-jwt-vc-09.

Verifiable Credential Type (vct): eu.we-build.ds-membership.1

The issued SD-JWT VC SHALL use the JOSE typ header value required by [SD-JWT VC]. For draft -09, this value is dc+sd-jwt.

3.2.1 IANA-registered and standard JWT / SD-JWT VC claims

The following claims are standard JWT or SD-JWT VC claims.

3.2.2 Private names specific to the Membership Credential

The following private claims map to the attributes defined in Chapter 2. Claim names are identical to the Chapter 2 data identifiers; the two SHALL be kept in step.

Identifier representation in this encoding. SD-JWT VC is not JSON-LD, so an identifier is encoded as a plain JSON object with scheme and value members — for example {"scheme": "VatId", "value": "BE0123456789"}. This is the SD-JWT VC form of the typed literal described in Section 2.2.3; the W3C VCDM encoding uses the JSON-LD form {"@type": "VatId", "@value": "BE0123456789"} (Section 3.3). Both carry the same scheme and value, and the scheme is drawn from the same code list 2.8. Where no published scheme applies, the identifier is a plain string in both encodings.

Reading the Disclosable column. MUST means the issuer SHALL make the claim selectively disclosable; MAY means the issuer MAY do so; MUST NOT means the claim SHALL remain in the always-visible signed payload.

Disclosability is independent of whether an attribute is mandatory in the credential. Optionality governs what the issuer SHALL include when issuing; disclosability governs what the holder may withhold when presenting. All subject attributes are therefore selectively disclosable, including the mandatory ones: a Relying Party enforces the set it needs through its presentation request and rejects a presentation that omits any of them, so disclosability costs the Relying Party nothing while leaving the holder in control of everything beyond that set. The claims marked MUST NOT are exactly those required to process or validate the credential itself, which no presentation can omit.

Granularity for structured attributes. Where an attribute is an object or an array, the following applies:

• Members of termsOfUse, member, onboardedBy and their nested objects SHALL be individually disclosable (structured/recursive selective disclosure), so that a holder can present, for example, termsOfUse.hash and termsOfUse.version without disclosing termsOfUse.acceptedAt, which is onboarding-date metadata a Relying Party rarely needs.
• Elements of role SHALL be individually disclosable, so that a holder with several roles can present only the role or roles the Relying Party's policy requires.
• Elements of evidence SHALL be individually disclosable. Evidence reveals how the holder was identity-proofed and carries an identifier that may correlate the holder across services, so a holder SHOULD be able to withhold it entirely or disclose a single entry.

Note that the granularity, not the requirement, is what depends on the data type: MUST applies uniformly to memberOf, role and termsOfUse alike, since all three are part of the atomic set a Relying Party uses to decide whether to accept the credential. The distinction between a string, an array of strings and an object determines only how selective disclosure is applied to each.

3.2.3 Status Claim

The Membership Credential is revocable (Chapter 6). Therefore, an SD-JWT VC-compliant Membership Credential SHALL include a status claim unless a future profile explicitly defines a short-lived, non-revocable variant.

The status claim SHALL use the status-list mechanism used by the other SD-JWT VC rulebooks in this catalog. It SHALL be a JSON object with the following members:

• type (string): SHALL be "status-list".
• status_list_credential (string, URI): URI of the Status List Credential that contains the status bitstring.
• status_list_index (integer, >= 0): zero-based index into the status list bitstring for this credential.
• status_purpose (string): SHALL be "revocation" for this attestation.

Example:

{
  "status": {
    "type": "status-list",
    "status_list_credential": "https://djustconnect.be/status/membership/1",
    "status_list_index": 42,
    "status_purpose": "revocation"
  }
}

3.2.4 Example Payload

The following non-normative example shows the JWT claim set before SD-JWT processing.

{
  "iss": "https://djustconnect.be",
  "iat": 1782205200,
  "nbf": 1782205200,
  "exp": 1813741200,
  "jti": "urn:uuid:8d6f0e3c-1c2a-4e2b-9f1a-1234567890ab",
  "vct": "eu.we-build.ds-membership.1",
  "attestation_legal_category": "EAA",
  "id": "did:web:example.com:participant:123",
  "member": {
    "legalName": "Farm Example BV",
    "legalIdentifier": {
      "scheme": "Euid",
      "value": "BEEUID0123456789"
    }
  },
  "memberOf": "https://agri-x.eu",
  "holderIdentifier": "BE0123456789",
  "role": ["https://w3id.org/ebwv#DataRightsHolder", "https://w3id.org/ebwv#DataProvider"],
  "termsOfUse": {
    "url": "https://agri-x.eu/rulebook",
    "version": "1.2",
    "hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "acceptedAt": "2026-06-20T14:30:00Z"
  },
  "onboardedBy": {
    "platformId": "did:web:djustconnect.be",
    "name": "DjustConnect",
    "operator": {
      "legalName": "Instituut voor Landbouw-, Visserij- en Voedingsonderzoek (ILVO)",
      "identifier": {
        "scheme": "VatId",
        "value": "BE0848278827"
      }
    }
  },
  "evidence": [
    {
      "identifier": {
        "scheme": "VatId",
        "value": "BE0123456789"
      }
    }
  ],
  "status": {
    "type": "status-list",
    "status_list_credential": "https://djustconnect.be/status/membership/1",
    "status_list_index": 42,
    "status_purpose": "revocation"
  },
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

Note the distinct roles of the VAT identifiers. onboardedBy.operator.identifier is the VAT-ID of ILVO, the organisation hosting the DjustConnect platform. holderIdentifier is the VAT-ID by which DjustConnect refers to the holder, Farm Example BV, in its own communication. evidence[0].identifier is the VAT-ID that was used to prove that holder's identity during initial onboarding. The latter two carry the same value here, as they commonly will; member identifies the same legal person at EU level by its EUID.

The SD-JWT VC JSON Schema and sample payload are published at:

• data-schemas/sd-jwt/ds-membership-sd-jwt.json
• data-schemas/sd-jwt/sample-data/ds-membership-sd-jwt-sample.json

3.3 W3C Verifiable Credentials Data Model-based encoding

This is the primary format for the MVP. The Membership Credential is a non-qualified EAA, which is the only legal category permitted to use the W3C VCDM format (ARB_01a). W3C VCDM (JSON-LD) is chosen for semantic interoperability with the dataspaces domain and because it supports selective disclosure via ZKP.

The credential subject carries the attributes defined in Chapter 2. Standard VCDM metadata is used for the credential envelope: issuer, validFrom, validUntil, credentialStatus, and the credential id (unique per credential). The credential subject is modeled by the Membership class

evidence is credential-level, not part of the credential subject. The W3C VCDM v2 context defines evidence inside the type-scoped context of VerifiableCredential. It is therefore only defined as a member of the credential itself. Placing it inside credentialSubject, whose type is Membership, leaves the term undefined; since the VCDM v2 context is @protected and sets no @vocab, that is an expansion failure rather than a silent omission. This placement is also the semantically correct one: evidence records how the issuer verified the holder's identity, which is a statement about the issuance, not an attribute of the subject.

evidence is optional, but where the onboarding platform holds a record of the identification means used, the issuer SHOULD include it: it is what allows a Relying Party operating a legacy system to reconcile the holder against its existing records. It SHALL NOT be confused with onboardedBy.operator.identifier, which identifies the organisation hosting the platform. See IR-03 and IR-04.

Illustrative example (informative):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/ebwv/v0.1"
  ],
  "type": ["VerifiableCredential","ElectronicAttestationOfAttributes"],
  "id": "urn:uuid:8d6f0e3c-1c2a-4e2b-9f1a-1234567890ab",
  "issuer": "did:web:djustconnect.be",
  "validFrom": "2026-06-23T09:00:00Z",
  "validUntil": "2027-06-23T09:00:00Z",
  "attestationLegalCategory": "EAA",
  "credentialStatus": {
    "id": "https://djustconnect.be/status/membership#42",
    "type": "BitstringStatusListEntry"
  },
  "evidence": [
    {
      "type": "EconomicOperator",
      "identifier": { "@type": "VatId", "@value": "BE0123456789" }
    }
  ],
  "credentialSubject": {
    "id": "urn:uuid:650805cd-8abf-4f2d-bc23-9552511c7e01",
    "type": "Membership",
    "member": {
      "type": "EconomicOperator",
      "legalName": "Farm Example BV",
      "legalIdentifier": { "@type": "Euid", "@value": "BEEUID0123456789" }
    },
    "memberOf": "https://agri-x.eu",
    "holderIdentifier": "BE0123456789",
      "role": ["https://w3id.org/ebwv#DataRightsHolder", "https://w3id.org/ebwv#DataProvider"],
    "termsOfUse": {
      "type":"GovernanceRulebook",
      "url": "https://agri-x.eu/rulebook",
      "version": "1.2",
      "hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
      "acceptedAt": "2026-06-20T14:30:00Z" 
    },
    "onboardedBy": {
      "type": "Platform",
      "platformId": "did:web:djustconnect.be",
      "name": "DjustConnect",
      "operator": {
        "type": "EconomicOperator",
        "legalName": "Instituut voor Landbouw-, Visserij- en Voedingsonderzoek (ILVO)",
        "identifier": { "@type": "VatId", "@value": "BE0848278827" }
      }
    }
  }
}

This example reads: "DjustConnect, a platform hosted by ILVO, onboarded Farm Example BV — proven during onboarding by VAT-ID BE0123456789 and identified at EU level by EUID BEEUID0123456789 — into Agri-X as a Data Rights Holder and Data Provider." The VAT-ID under operator.identifier belongs to ILVO; the VAT-ID under evidence is the identification means used for the holder.

Expanding this example makes three things explicit. role and memberOf become node references — {"@id": "https://w3id.org/ebwv#DataProvider"}, {"@id": "https://agri-x.eu"} — because the vocabulary types both properties @id (Section 2.8). This is why their values are absolute IRIs: a relative value would be resolved against the document base, producing a different IRI for every location the credential is served from. holderIdentifier, by contrast, is typed xsd:string and expands as a plain literal. Identifiers expand as typed literals carrying their scheme as the datatype IRI, for example {"@value": "BE0123456789", "@type": "https://w3id.org/ebwv#VatId"}. And attestationLegalCategory expands to a node reference, {"@id": "https://w3id.org/ebwv#EAA"}, because the vocabulary types it @vocab. Section 3.3.2 sets out the type declarations this depends on.

3.3.2 Type declarations required for expansion

The European Business Wallet Vocabulary context defines almost all of its properties inside type-scoped contexts, not at the top level. Only description, issuer, name and termsOfUse are defined globally. A property is therefore undefined — and, since the context sets no @vocab, silently dropped on expansion — unless the enclosing object declares the type that scopes it. Issuers SHALL declare the following types, and verifiers SHOULD reject a credential in which an expected attribute does not survive expansion:

Three consequences worth stating plainly:

• ElectronicAttestationOfAttributes SHALL appear in the credential-level type. It is what brings attestationLegalCategory into scope; without it the attribute required by Section 2.1 is dropped on expansion. The vocabulary types that property @type: @vocab with a nested context mapping EAA, QEAA and Pub-EAA to their individuals, so the value expands to a node reference — {"@id": "https://w3id.org/ebwv#EAA"} — rather than a string literal. That nested context also sets "@vocab": "ebwv:INVALID_VALUE:", so a value outside the three published categories expands to a visibly invalid IRI instead of being silently dropped.

• Membership types the credential subject, not the credential. The credential-level type is ["VerifiableCredential", "ElectronicAttestationOfAttributes"], neither of which is Membership. Membership is declared a subclass of CredentialSubject in the vocabulary, and putting it in the credential-level type array leaves every Membership property undefined inside credentialSubject, so member, memberOf, role and onboardedBy are all dropped on expansion without any error being raised.

• Each evidence entry is typed EconomicOperator. The identifier property is scoped to that type, and the entry does describe the holder as an economic operator identified by the means used at onboarding, so the typing is both necessary and semantically correct. It also satisfies the domain of identifier.

Coverage. Every attribute defined by this Rulebook now has a property term in the European Business Wallet Vocabulary context, and the illustrative example in Section 3.3 expands without loss. This was verified against the context published on 2 September 2026, which added holderIdentifier to the Membership type-scoped context.

Because that context sets no @vocab, an attribute with no term is silently dropped on expansion rather than raising an error. Issuers and verifiers SHOULD therefore treat a successful expansion as something to check rather than assume: a Relying Party SHALL NOT infer the absence of an attribute from an expanded document alone without confirming that its context set defines the corresponding term.

Proof type: an EU-approved Data Integrity proof / VC-JOSE-COSE securing mechanism SHALL be used. [PROOF TYPE TO BE FIXED once the WE BUILD profile selects it; e.g. a Data Integrity ECDSA proof to support ZKP-based selective disclosure.]

4 Attestation usage

The Membership Credential is used in the WE BUILD SC2 "seamless onboarding" scenario. Its use case in this pilot is:

• Onboarding into a DSI or into Agri-X. The holder presents the EUBWOID to identify their organisation, accepts the applicable dataspace governance rulebook, and receives a Membership Credential reflecting their membership and roles. Information already presented during a previous onboarding flow is trusted and not requested again. Where the onboarding platform holds a identification means used to prove the holder's identity, it is recorded in evidence, so that a later Relying Party can reconcile the holder with its own legacy records.

Potential future use, out of scope for this pilot. Verifying membership and roles during data-sharing transactions between participants of a DSI or dataspace is a plausible further application, but it is not piloted in the MVP and is not specified by this Rulebook. Direct presentation of the Membership Credential inside a data-transfer flow is not assumed: such a flow would most likely require the credential to be transformed into a connector-native credential (for instance an EDC / dataspace protocol participant credential) first. Any statement about data-sharing use elsewhere in this document is to be read in that light.

PID verification. The holder is a legal person identified via the EUBWOID/EUID, not via a PID. A Relying Party therefore does not need to request and verify a PID (ARB_27) for this attestation in the MVP scenario.

Relying Party obligations. A Relying Party SHALL verify the issuer signature/proof, check credential validity (validFrom/validUntil) and revocation status (Section 6), and confirm the issuer is an authorised onboarding service provider for the relevant memberOf value (Section 5). Where rulebook conformance matters, the Relying Party MAY compare termsOfUse.hash / termsOfUse.version against the expected rulebook. A Relying Party MAY additionally use evidence to reconcile the holder with its own legacy records, subject to IR-04. It SHALL match role and memberOf as exact, case-sensitive strings per IR-05.

Presentation requirements. Presentation is online. The primary format is W3C VCDM (JSON-LD) presented via OpenID4VP; an SD-JWT VC flow may be piloted additionally. No proximity/offline presentation is required.

Device binding. The attestation is bound to an organisation (legal person) held in an EU Business Wallet rather than to a natural person's device; the MVP does not require cryptographic binding to a PID. The cryptographically_bound_to attribute (ARB_28) is therefore not included. If a future scenario requires binding to the EUBWOID, add cryptographically_bound_to as optional metadata in Section 2.6 with the corresponding attestation type / vct value.

Transactional data. No transactional data (per [Topic 20]) is defined for this attestation; it is not used for strong user authentication of electronic payments.

5 Trust anchors

This Rulebook (non-qualified EAA): the trust anchor is the public key of the issuing onboarding service provider, resolvable from the issuer DID (issuer in the VCDM credential, e.g. a did:web document). A Relying Party obtains the trust anchor by resolving that DID and verifies the credential proof against it. Authorisation of an issuer to issue Membership Credentials for a given memberOf value is governed by the WE BUILD / dataspace trust framework (WP4).

memberOf vocabulary governance. memberOf values are absolute IRIs registered in code list 2.8 by the governance level of the owning DSI or dataspace, under that DSI's or dataspace's own domain. A Relying Party SHALL match memberOf by exact IRI comparison and confirm WP4 authorisation of the issuer for that specific value (IR-05). Domain ownership makes the values globally unique. Prefix matching does not apply, since each value identifies a distinct DSI or dataspace rather than a term in a shared vocabulary, and a Relying Party SHALL NOT depend on the IRI dereferencing. Registering the value in code list 2.8 before issuing remains a governance obligation, not a convenience.

Role vocabulary governance. role values are absolute IRIs. Those registered in code list 2.8 are the DataSpaceRole individuals published by the WE BUILD Semantics work group under https://w3id.org/ebwv#, independently of this Rulebook's own versioning. Because the vocabulary types role as @id, a Relying Party MAY trust roles by namespace prefix rather than an exact-match list, so that new individuals published under that namespace do not require a Relying Party policy change. A DSI MAY likewise mint role IRIs under a namespace it owns without a change to this Rulebook or to the vocabulary context; such values SHALL be governed by that DSI's own trust framework, and a Relying Party SHALL ignore any role IRI it does not recognise (IR-05).

6 Revocation

The Membership Credential is revocable. Membership and the associated set of roles share a single lifecycle: adding, changing, or removing a role requires re-issuance of the credential and revocation of the superseded one. The credential carries a credentialStatus entry (see the Section 3.3 example) used to publish status.

7 Compliance

The Membership Credential is defined as a non-qualified EAA under the [European Digital Identity Regulation]:

• It includes an attribute indicating it is an EAA (attestation_legal_category = EAA, Sections 2.1 and 2.5), per ARB_12.
• It carries attributes about the holder (member.legalIdentifier, member.legalName, memberOf, role) per ARB_15 / ARB_17 (Annex V points b and c).
• The W3C VCDM (JSON-LD) format is used, which is permitted only for non-qualified EAA (ARB_01a).
• The trust-anchor location is provided via the issuer DID (Section 5), per ARB_21 / ARB_26.
• Revocation is addressed in Section 6, per [Topic 7].

8 References