Trust Chain

If your entity is going to issue verifiable credentials, in addition to having a DID and a P-256 key registered with assertionMethod, you need to be part of a trust chain. This step is only necessary for issuers.

Roles

Role	Who can issue	Capability
RTAO	Only ISBE	Generates the root of a domain.
TAO	Entity accredited by ISBE	Accredits TIs or subTAOs within the domain.
TI	Entity accredited by a TAO	Issues verifiable credentials of the authorized types.

Prerequisites

Have a registered DID and a P-256 key with the assertionMethod relationship.
Have the isbe-identity-accreditation-cli CLI installed.
Have an RTAO previously requested from ISBE for your domain. ISBE is the only entity with the capability to issue RTAOs.

CLI Configuration

The first time you run any command, the CLI will generate the default configuration. To force it:

./isbe-accreditation-cli.sh config --show

This creates the isbe-data/ directory with an isbe-config.json file. Edit it so that it has the following structure:

{
  "issuerDid": "did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV",
  "jwkPrivateKeyPath": "./config/key.json",
  "logging": { "debug": false },
  "accreditationSchema": "https://raw.githubusercontent.com/alastria/isbe-identity-schemas-repository/main/commons/isbe-accreditation-schema.json",
  "authorizationSchema": "https://raw.githubusercontent.com/alastria/isbe-identity-schemas-repository/main/commons/isbe-authorization-schema.json",
  "credentialSchema": "https://...",
  "tirUrl": "https://tir.portal.redisbe.com/trusted-issuers-registry/v1",
  "trustAnchors": ["did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV"]
}

Adjust tirUrl, trustAnchors, and the schemas to the environment you will operate in.

Next, create isbe-data/config/key.json with the P-256 key you registered in the DID:

{
  "kid": "did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV#WqpsDjTHnYVNvX8qx4a1FER8NgnEBS6DjLbDVrX-Fg4",
  "kty": "EC",
  "crv": "P-256",
  "alg": "ES256",
  "x": "<X>",
  "y": "<Y>",
  "d": "<D>"
}

Format of the kid

The kid is built as <DID> + "#" + <JWK thumbprint>. It must match the verificationMethod registered in the DID exactly. Otherwise, signatures will be rejected during verification.

Generating an RTAO Accreditation

This operation is performed by ISBE, but it is useful to know the command for context:

pnpm run cli generate \
  --sub did:isbe:uc:<ENTITY_DID> \
  --domain ISBE \
  --type rtao \
  --attribute "<64_RANDOM_HEX_CHARACTERS>" \
  --exp 2090222442

The output is a signed JWT representing the accreditation. ISBE registers this accreditation in the TIR.

Generating a TAO Accreditation

./isbe-accreditation-cli.sh generate \
  --sub <Accreditation Subject DID> \
  --domain <DOMAIN> \
  --type tao \
  --attribute "<64_RANDOM_HEX_CHARACTERS>" \
  --accreditedFor <CREDENTIAL_TYPE> \
  --accreditedSchemas <CREDENTIAL_SCHEMA> \
  --accreditedBy <PARENT_ACCREDITATION_URL>

Meaning:

Parameter	Description
`sub`	DID of the subject of the accreditation (can be your own DID or a third party).
`domain`	Domain associated with the accreditation.
`type`	`tao` or `ti`.
`attribute`	64 random hex characters. Unique identifier of the resource in the TIR.
`accreditedFor`	VC types enabled by the accreditation (separated by spaces).
`accreditedSchemas`	URLs of the corresponding schemas (1:1 with `accreditedFor`).
`accreditedBy`	Public URL (TIR) of the parent accreditation validating this one. For a TAO, it must point to an RTAO or to another TAO with a superset of types.

Example

pnpm run cli generate \
  --sub did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV \
  --domain ISBE \
  --type tao \
  --attribute "abfc5a265e1b3aa60718619c0041e3c051686fd05d0f0954679eaa756136b343" \
  --accreditedFor IsbePortalLearCredential \
  --accreditedSchemas https://raw.githubusercontent.com/alastria/isbe-identity-schemas-repository/main/use-cases/isbe/portal/lear/portalLear-schema.json \
  --accreditedBy "https://tir.portal.redisbe.com/trusted-issuers-registry/v1/issuers/did:isbe:uc:z12kVar5p6bD5WCjEJcQ18Zyt8XV/attributes/fad7068b8f890f20b86554be9f9d66d6b0ce08ec3b057a937e21f8a30ec545c7" \
  --exp 2090222442

The output is a JWT (eyJ...) representing the accreditation.

Generating a TI Accreditation

./isbe-accreditation-cli.sh generate \
  --sub <Accreditation Subject DID> \
  --domain <DOMAIN> \
  --type ti \
  --attribute "<64_RANDOM_HEX_CHARACTERS>" \
  --accreditedFor <CREDENTIAL_TYPE> \
  --accreditedSchemas <CREDENTIAL_SCHEMA> \
  --accreditedBy <PARENT_TAO_ACCREDITATION_URL>

The same rules apply as for TAO, with two restrictions:

The domain must match that of the parent TAO.
The types / schemas must be a subset of those accredited by the parent TAO.

Registering the Accreditation in the TIR

Currently, this step must be performed by an ISBE operator. The ability for the accreditation owner to register it directly is under development.

To request registration:

Send the generated JWT to the ISBE team.
Indicate the domain, the subject entity, and the types of credentials it will issue.
ISBE will publish the accreditation in the TIR of the corresponding environment.

Once published, the TIR URL will be used by verifiers to validate credentials issued by your entity.

Configuring the Connector

After registering the accreditations in the TIR, configure your instance's Connector to use the new identifiers and keys:

Access the Connector admin panel: https://<your-instance>/admin/login/.
In the Accreditation section, fill in the Accreditation URL published in the TIR. Important: use the URL, NOT the JSON.
In the Framework / Metadata section, enter the corresponding DID.
Register the kid and the P-256 private key in the Keys section.

Keys in production

Never use the repository's example keys in production. For security reasons, the Connector keys must be unique per entity and environment.

Validating the Chain

To verify that your trust chain is working:

Generate a test verifiable credential with the Connector.
Call the verification endpoint of the Trusted Issuer Service.
Verify that the chain resolves correctly up to the ISBE RTAO.

If verification fails, check:

That the URLs in accreditedBy point to the correct TIR.
That the schemas are a subset of the accredited ones.
That the Connector signing key matches the one registered in the DID.

Roles​

Prerequisites​

CLI Configuration​

Generating an RTAO Accreditation​

Generating a TAO Accreditation​

Example​

Generating a TI Accreditation​

Registering the Accreditation in the TIR​

Configuring the Connector​

Validating the Chain​