Concepts

The role model

The ISBE trust chain follows a descending hierarchical model. Each role is accredited by the immediately superior role and can only exercise capabilities within the scope of that accreditation.

TA (Trust Anchor — fixed DID, configured in clients)
 └── RTAO (Root Trusted Accreditation Organisation)
       └── TAO (Trusted Accreditation Organisation)
             └── TI (Trusted Issuer)

The trust anchor (TA) has no accreditation registered in the TIR: its DID is known to verifier clients through static configuration. Everything else in the chain is validated against that anchor.

Trust Anchor (TA)

The TA is the entity whose DID is the starting point of validation. In ISBE, the TA and the entity that issues RTAOs are the same. The TA's DID is configured in the accreditation CLI (trustAnchors), and in any verifier client.

RTAO — Root Trusted Accreditation Organisation

The RTAO accredits the TAOs of a domain. Only ISBE has the capability to issue RTAOs. An RTAO accreditation uses the VC type VerifiableAuthorisationForTrustChain.

The RTAO accreditation contains:

• credentialSubject.id — DID of the entity receiving the RTAO role.
• credentialSubject.accreditedFor — array of { schemaId, types[], limitJurisdiction? } defining which credential types can be accredited under this RTAO.
• credentialSubject.reservedAttributeId — attribute identifier in the TIR (64 hex chars).

TAO — Trusted Accreditation Organisation

The TAO accredits TIs (and can accredit sub-TAOs) within the domain and types established in its own accreditation. A TAO accreditation uses the VC type VerifiableAccreditationToAccredit.

The TAO accreditation contains the same fields as the RTAO, plus:

• termsOfUse[].id — URL of the parent accreditation (RTAO or TAO) that endorses this TAO.
• termsOfUse[].type — "IsbeAccreditationEntry".

TI — Trusted Issuer

The trusted issuer is the entity with final capability to issue verifiable credentials to users. A TI accreditation uses the VC type VerifiableAccreditationToAttest.

The TI accreditation contains the same fields as the TAO. The types in accreditedFor must be a subset of those authorized by the parent TAO.

TV — Trusted Verifier (not implemented)

The TV role is defined in the ISBE-ART-00024 specification but is not implemented in the current infrastructure. It is not used in any production flow.

Accreditation types

VC type	Role it represents	Signed by
VerifiableAuthorisationForTrustChain	RTAO	ISBE TA
VerifiableAccreditationToAccredit	TAO	RTAO or parent TAO
VerifiableAccreditationToAttest	TI	Parent TAO

All three types inherit from the W3C VC Data Model 2.0 context (https://www.w3.org/ns/credentials/v2). The type field of the VC is an array that always includes "VerifiableCredential" plus the specific type:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "VerifiableAccreditationToAttest"],
  "issuer": "did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV",
  "validFrom": "2023-03-29T12:56:16Z",
  "validUntil": "2090-01-09T05:40:42Z",
  "credentialSubject": {
    "id": "did:isbe:uc:<TI_DID>",
    "accreditedFor": [
      {
        "schemaId": "https://raw.githubusercontent.com/alastria/isbe-identity-schemas-repository/main/use-cases/isbe/portal/lear/portalLear-schema.json",
        "types": ["VerifiableCredential", "IsbePortalLearCredential"],
        "limitJurisdiction": "https://publications.europa.eu/resource/authority/atu/ESP"
      }
    ],
    "reservedAttributeId": "abfc5a265e1b3aa60718619c0041e3c051686fd05d0f0954679eaa756136b343"
  },
  "termsOfUse": [
    {
      "id": "https://tir.portal.redisbe.com/trusted-issuers-registry/v1/issuers/did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV/attributes/fad7068b8f890f20b86554be9f9d66d6b0ce08ec3b057a937e21f8a30ec545c7",
      "type": "IsbeAccreditationEntry"
    }
  ],
  "credentialSchema": [
    {
      "id": "https://github.com/alastria/isbe-identity-schemas-repository/raw/main/commons/isbe-accreditation-schema.json",
      "type": "JsonSchema"
    }
  ]
}

Accreditation domain

All accreditations are bound to a domain: a text string that delimits the operational scope. The domain "ISBE" is the production domain. The domain "ISBE-PRE" is used in the pre-production environment.

The domain ensures that an accreditation issued in the context of a specific network is not valid on another network, even if the TIR is shared.

The reservedAttributeId field

The reservedAttributeId is the attribute identifier in the TIR smart contract. It is a string of 64 randomly generated hexadecimal characters created by whoever generates the accreditation (the accreditation CLI). This same value is used as revisionId and attributeId in the JSON-RPC API methods.

Example: "abfc5a265e1b3aa60718619c0041e3c051686fd05d0f0954679eaa756136b343"

The termsOfUse field

The termsOfUse field links the accreditation to the parent accreditation that endorses it. Its id is the public TIR URL where the parent accreditation resides. Verifiers follow this URL to validate the chain upward.

Accreditation lifecycle

[Creation]
    │
    ▼
[JWT Signing]  ←  Accreditation CLI
    │
    ▼
[Publication in TIR]  ←  ISBE operator (via JSON-RPC API + blockchain)
    │
    ├── [Valid]    ←  validFrom ≤ now ≤ validUntil, issuerType ≠ REVOKED
    │
    ├── [Expired]  ←  now > validUntil
    │
    └── [Revoked]  ←  issuerType = REVOKED (4)

An accreditation cannot return to valid state once expired or revoked. If an entity needs a new accreditation after revoking the previous one, a new accreditation with a different reservedAttributeId must be published.

Storage: hybrid on-chain and off-chain

Current storage architecture

The TrustedIssuersRegistryFacet smart contract stores the attribute metadata on the blockchain: issuer type (issuerType), subject DID, TAO DID that accredits, and the attributeId. The full accreditation JWT is stored publicly in the isbe-identity-accreditations-chains GitHub repository.

The TIR API REST read endpoint (GET /trusted-issuers-registry/v1/issuers/{did}/attributes/{attributeId}) retrieves the data from the GitHub repository, not directly from the contract. This architecture reduces gas cost without sacrificing public availability of accreditations.

Revocation

Revocation is performed by publishing a new transaction to the TIR with issuerType = REVOKED (numeric value 4) for the attribute to be revoked. The contract records the change and from that point on any verifier querying the TIR will obtain the type REVOKED.

Revocation can only be executed by the entity that published the accreditation or by an entity with higher hierarchy in the chain. There is no self-revocation mechanism: the accreditation subject cannot revoke its own accreditation.

Relationship with credentialStatus in issued VCs

Verifiable credentials issued by a TI may include a credentialStatus field that references the TIR to allow checking whether the credential (not the issuer's accreditation) has been revoked. The type IsbeAccreditationEntry identifies a TIR entry. This mechanism applies both to accreditations and to credentials issued with revocation support.