Context
This document outlines the flows from the Accredit and Authorise test module in the Conformance Test.
Vocabulary
| Term | Definition |
|---|---|
| LE | A Legal Entity NOT registered as a Trusted Issuer. |
| Trusted Issuer | A Legal Entity registered in the Trusted Issuers Registry with roles TI, TAO or Root TAO. |
| TI | A Trusted Issuer that participates in the trust chain with attestation rights. |
| TAO | A Trusted Accreditation Organisation that participates in the trust chain with accreditation rights. |
| Root TAO | A Root Trusted Accreditation Organisation serving as the root of the trust chain. |
| Conformance Issuer | A Mock Issuer for Conformance Tests. This is a Root TAO. |
Guidelines
The Accredit and Authorise module tests a Legal Entity's conformance to the Issuer Trust Model and ensures the correctness of content written into the Trusted Registries.
Authentication of a Legal Entity by a Conformance Issuer is achieved using an ID Token, except for the Root TAO, which uses its decentralised identifier (DID) document's authentication key. This key must be pre-registered before initiating authentication. Conformance Issuers should implement authentication via a Verifiable Presentation exchange with Verifiable Credentials, requesting an ID Token and authenticating a DID by OIDC ecosystem capabilities, or through pre-registration.
The Conformance Authorisation Mock (Auth Mock) and Credential Issuer Mock (Issuer Mock) have separate functions. The Auth Mock handles access management, and the Issuer Mock supports credential issuance.
The flow contains four parties:
- Client: the test subject
- Auth Mock: the Issuer's backend for the Authorisation Service
- Configuration available at /.well-known/openid-configuration
- Issuer Mock: the Issuer's backend for credential issuance
- Configuration available at /.well-known/openid-credential-issuer
- EBSI Authorisation Service and Registries: the EBSI platform
Requesting and Issuing Verifiable Credentials
Credential Issuers expose the OpenID Credential Issuer Configuration through the ./well-known/openid-credential-issuer endpoint. The configuration lists available credentials in the credentials_supported field and includes the authorization_server field to locate the Authorisation Server for access tokens. The client should verify that the credential in question is supported before proceeding.
The DID transmitted in the ID Token is checked against the DID Registry, where the signature must be resolvable with the DID document's authentication key. The VerifiableAuthorisationToOnboard is an exception, as the DID must not exist in the registry. The Conformance Test requires an ID Token for authentication, but other authentication means can also be used.
Requesting and issuing mirrors the participants.
Discovery
Steps 1 and 2:
The client resolves the authorization_server and credentials_supported fields through the ./well-known/openid-credential-issuer configuration. The Credential Issuer's configuration points to an external Authorisation Server, with its own client_id.
Refer to Credential Issuer Metadata for further details.
Steps 3 and 4:
The client resolves the Authorisation Server's configuration through the Authorisation Server's ./well-known/openid-configuration. This exposes the Authorisation Server configuration and usage details.
Refer to Authorisation Server Metadata for further details.
Authorisation and Authentication
Step 5:
With discovery complete, the client should now understand the two services' capabilities and all supported credentials. The client proceeds with the Verifiable Credential Issuance flow by requesting access for the required credential from the Authorisation Server.
The Request Object must be signed with the client's private key, owned by the requesting client_id. The corresponding public key must be resolvable through the client_metadata.jwks_uri provided in the initial Authorisation Request.
Authorisation Request
GET from https://api-conformance.ebsi.eu/conformance/v3/auth-mock/authorize?
client_id=https%3A%2F%2Fmy-issuer.eu%2Fsuffix%2Fxyz
&response_type=code
&scope=openid
&redirect_uri=https%3A%2F%2Fmy-issuer.eu%2Fsuffix%2Fxyz%2Fcode-cb
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkpwLTliRUk4dTY4LWU5NW1Ud25DRktLSWdUbkR1Ukhjb1RIYXpwWENKdDQifQ.eyJpc3MiOiJodHRwczovL215LWlzc3Vlci5ldS9zdWZmaXgveHl6IiwiYXVkIjoiaHR0cHM6Ly9hcGktY29uZm9ybWFuY2UuZWJzaS5ldS9jb25mb3JtYW5jZS92My9hdXRoLW1vY2siLCJleHAiOjE1ODk2OTg4MDAsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwic2NvcGUiOiJvcGVuaWQiLCJub25jZSI6Imdsa0ZGb2lzZGZFdWk0MyIsImNsaWVudF9pZCI6Imh0dHBzOi8vbXktaXNzdWVyLmV1L3N1ZmZpeC94eXoiLCJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJvcGVuaWRfY3JlZGVudGlhbCIsImZvcm1hdCI6Imp3dF92YyIsInR5cGVzIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmVyaWZpYWJsZUF0dGVzdGF0aW9uIiwiVmVyaWZpYWJsZUF1dGhvcmlzYXRpb25Ub09uYm9hcmQiXX1dLCJyZWRpcmVjdF91cmkiOiJodHRwczovL215LWlzc3Vlci5ldS9zdWZmaXgveHl6L2NvZGUtY2IiLCJjbGllbnRfbWV0YWRhdGEiOnsiandrc191cmkiOiJodHRwczovL215LWlzc3Vlci5ldS9zdWZmaXgveHl6L2p3a3MiLCJhdXRob3JpemF0aW9uX2VuZHBvaW50Ijoib3BlbmlkOiJ9fQ.scj7e0uEbME1eBpn9Cjkgl-uNih1D-dnNcFokoDEVCi0xGq2_z6o5DtQancbo84lpfXX6me3EQ83Yz6ykPHPbQ
JWT Header:
{
typ: 'JWT',
alg: 'ES256',
kid: 'Jp-9bEI8u68-e95mTwnCFKKIgTnDuRHcoTHazpXCJt4'
}
JWT Payload:
{
iss: 'https://my-issuer.eu/suffix/xyz',
aud: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock',
exp: 1589698800,
response_type: 'code',
scope: 'openid',
nonce: 'glkFFoisdfEui43',
client_id: 'https://my-issuer.eu/suffix/xyz',
authorization_details: [
{
type: 'openid_credential',
format: 'jwt_vc',
locations: ['https://api-conformance.ebsi.eu/conformance/v3/issuer-mock'],
types: [
'VerifiableCredential',
'VerifiableAttestation',
'VerifiableAuthorisationToOnboard'
]
}
],
redirect_uri: 'https://my-issuer.eu/suffix/xyz/code-cb',
client_metadata: {
jwks_uri: 'https://my-issuer.eu/suffix/xyz/jwks',
authorization_endpoint: 'openid:'
}
}
Step 6:
An ID Token is requested and responded to demonstrate authentication. Other User Authentication methods can be used instead, and the ID Token may be omitted if identity is not required for authorisation.
The Mock Auth validates the request and requests DID authentication from the client. The ID Token Request, which is also an Authorisation Request, MUST be a signed Request Object.
The Request Object is signed with the Auth Mock's private keys, discoverable through the jwks_uri parameter in ./well-known/openid-credential-issuer. The request uses response_mode=direct_post, and the response location is delivered in redirect_uri. The redirect location will be the client defined client_metadata.authorization_endpoint or the default of openid:.
ID Token Request
HTTP 302 Location: openid://
?client_id=https%3A%2F%2Fapi-conformance.ebsi.eu%2Fconformance%2Fv4%2Fauth-mock
&response_type=id_token
&scope=openid
&redirect_uri=https%3A%2F%2Fapi-conformance.ebsi.eu%2Fconformance%2Fv4%2Fauth-mock%2Fdirect_post
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6ImM0S3JlcEpYem1CTVctcW8ybnREQ3drVGdMbTJDYl81ZWFiemtsalRoXzAifQ.eyJpc3MiOiJodHRwczovL2FwaS1jb25mb3JtYW5jZS5lYnNpLmV1L2NvbmZvcm1hbmNlL3YzL2F1dGgtbW9jayIsImF1ZCI6Imh0dHBzOi8vbXktaXNzdWVyLmV1L3N1ZmZpeC94eXoiLCJleHAiOjE1ODk2OTkxNjIsInJlc3BvbnNlX3R5cGUiOiJpZF90b2tlbiIsInJlc3BvbnNlX21vZGUiOiJkaXJlY3RfcG9zdCIsImNsaWVudF9pZCI6Imh0dHBzOi8vYXBpLWNvbmZvcm1hbmNlLmVic2kuZXUvY29uZm9ybWFuY2UvdjMvYXV0aC1tb2NrIiwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly9hcGktY29uZm9ybWFuY2UuZWJzaS5ldS9jb25mb3JtYW5jZS92My9hdXRoLW1vY2svZGlyZWN0X3Bvc3QiLCJzY29wZSI6Im9wZW5pZCIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.eN3IFS38mBnXruHeCYWQTdFm_Xy5iLIihI5n6ctnsf1C-mK46n8cpWbcz6dRbSY2ci2PMJVFi_IwZMKMq9k4sQ
JWT Header:
{
typ: 'JWT',
alg: 'ES256',
kid: 'c4KrepJXzmBMW-qo2ntDCwkTgLm2Cb_5eabzkljTh_0'
}
JWT Payload:
{
iss: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock',
aud: 'https://my-issuer.eu/suffix/xyz',
exp: 1589699162,
response_type: 'id_token',
response_mode: 'direct_post',
client_id: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock',
redirect_uri: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock/direct_post',
scope: 'openid',
nonce: 'n-0S6_WzA2Mj'
}
Step 7:
The client issues an ID Token signed by the DID document's authentication key to prove the subject's identity through the control of the DID. If the client requests a VerifiableAuthorisationToOnboard, the signature cannot be validated as the DID document is not yet registered.
The state parameter is mandatory for the ID Token Response when it is present in the ID Token Request sent by the Authorisation Server. The state parameter must match in both the ID Token Request and Response.
ID Token Response
POST into https://api-conformance.ebsi.eu/conformance/v3/auth-mock/direct_post
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6ImRpZDplYnNpOnpkUGoxR1BYamZFUlh4WFBFMVlUWWRKIzdqM1RwYU5kUE5UT3pPdG91T09rbmxPTFFrM0pQLXlrVGZyYVd0WTNHTUUifQ.eyJpc3MiOiJkaWQ6ZWJzaTp6ZFBqMUdQWGpmRVJYeFhQRTFZVFlkSiIsInN1YiI6ImRpZDplYnNpOnpkUGoxR1BYamZFUlh4WFBFMVlUWWRKIiwiYXVkIjoiaHR0cHM6Ly9hcGkuY29uZm9ybWFuY2UuZWJzaS5ldS9jb25mb3JtYW5jZS92My9hdXRoLW1vY2siLCJleHAiOjE1ODk2OTkzNjAsImlhdCI6MTU4OTY5OTI2MCwibm9uY2UiOiJuLTBTNl9XekEyTWoifQ.1WysYi3W4gCB9Y1ichUUObT-Hvm08WYiFXQKN7D9GQUrnMaymVxD8g16BR_ErpkWbNwyxl_E7vwqukoSu6YMPQ
JWT Header:
{
typ: 'JWT',
alg: 'ES256',
kid: 'did:ebsi:zdPj1GPXjfERXxXPE1YTYdJ#7j3TpaNdPNTOzOtouOOknlOLQk3JP-ykTfraWtY3GME'
}
JWT Payload:
{
iss: 'did:ebsi:zdPj1GPXjfERXxXPE1YTYdJ',
sub: 'did:ebsi:zdPj1GPXjfERXxXPE1YTYdJ',
aud: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock',
exp: 1589699360,
iat: 1589699260,
nonce: 'n-0S6_WzA2Mj'
}
Step 8:
The Authorisation Server evaluates the authentication response and the original authorisation request to determine if access should be granted. Upon successful authentication, the direct_post endpoint returns a redirect to the originally requested redirect_uri (step 5) with a code.
Authorisation Response
HTTP 307 Location: https://my-issuer.eu/suffix/xyz/code-cb?
code=SplxlOBeZQQYbYS6WxSbIA
Step 9:
The client proceeds with the code flow. The client calls the Token Endpoint with the required details and signs the client_assertion JWT with their private keys. The public key counterparts MUST be resolvable through client_metadata.jwks_uri provided in the initial Authorisation Request.
Token Request
POST into https://api-conformance.ebsi.eu/conformance/v3/auth-mock/token
grant_type=authorization_code
&client_id=https%3A%2F%2Fmy-issuer.eu%2Fsuffix%2Fxyz
&code=SplxlOBeZQQYbYS6WxSbIA
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkpwLTliRUk4dTY4LWU5NW1Ud25DRktLSWdUbkR1Ukhjb1RIYXpwWENKdDQifQ.eyJpc3MiOiJodHRwczovL215LWlzc3Vlci5ldS9zdWZmaXgveHl6Iiwic3ViIjoiaHR0cHM6Ly9teS1pc3N1ZXIuZXUvc3VmZml4L3h5eiIsImF1ZCI6Imh0dHBzOi8vYXBpLmNvbmZvcm1hbmNlLmVic2kuZXUvY29uZm9ybWFuY2UvdjMvYXV0aC1tb2NrIiwianRpIjoiZjJlODFjOTYtZTA4ZS00MzhlLTk1YmMtOGI3ZDA5ZGI2Y2IxIiwiZXhwIjoxNTg5Njk5NjYwLCJpYXQiOjE1ODk2OTk1NjB9.CfdxPWhgfnU3LZqWOL7ajPxOPSHw1ybHguUjx1aGU43lGdch_yry8xNk9ZG7cQ6eZJK7Khfq058LA4LDktnA_g
JWT Header:
{
typ: 'JWT',
alg: 'ES256',
kid: 'Jp-9bEI8u68-e95mTwnCFKKIgTnDuRHcoTHazpXCJt4'
}
JWT Payload:
{
iss: 'https://my-issuer.eu/suffix/xyz',
sub: 'https://my-issuer.eu/suffix/xyz',
aud: 'https://api-conformance.ebsi.eu/conformance/v3/auth-mock',
jti: 'f2e81c96-e08e-438e-95bc-8b7d09db6cb1',
exp: 1589699660,
iat: 1589699560
}
Step 10:
The Access Token is delivered as a response payload from a successful Token Endpoint initiation. The c_nonce (Challenge Nonce) must be stored by the client until a new one is given. The first c_nonce can be transmitted from the Authorisation Server to the Conformance Issuer through the Access Token.
Token Response
HTTP Response for the POST request
Content-Type: application/json
{
access_token: 'eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ',
token_type: 'bearer',
expires_in: 86400,
id_token: 'eyJodHRwOi8vbWF0dHIvdGVuYW50L..3Mz',
c_nonce: 'PAPPf3h9lexTv3WYHZx8ajTe',
c_nonce_expires_in: 86400
}
Credential Issuance
Step 11:
With a valid access_token, the client can access the Credential Issuer's Credential Endpoint.
The client requests issuance of the Verifiable Credential from the Issuer Mock. The requested Credential must equal to the granted access. The DID document's authentication key must be used for signing the JWT proof, and the DID must match the one used for authentication.
Credential Request
POST into https://api-conformance.ebsi.eu/conformance/v3/issuer-mock/credential
Content-Type: application/json
Authorization: BEARER eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ
{
types: [
'VerifiableCredential',
'VerifiableAttestation',
'VerifiableAuthorisationToOnboard'
],
format: 'jwt_vc',
proof: {
proof_type: 'jwt',
jwt: 'eyJ0eXAiOiJvcGVuaWQ0dmNpLXByb29mK2p3dCIsImFsZyI6IkVTMjU2Iiwia2lkIjoiZGlkOmVic2k6emRQajFHUFhqZkVSWHhYUEUxWVRZZEojN2ozVHBhTmRQTlRPek90b3VPT2tubE9MUWszSlAteWtUZnJhV3RZM0dNRSJ9.eyJpc3MiOiJkaWQ6ZWJzaTp6ZFBqMUdQWGpmRVJYeFhQRTFZVFlkSiIsImF1ZCI6Imh0dHBzOi8vYXBpLWNvbmZvcm1hbmNlLmVic2kuZXUvY29uZm9ybWFuY2UvdjMvaXNzdWVyLW1vY2siLCJpYXQiOjE1ODk2OTk1NjIsImV4cCI6MTU4OTY5OTk2Miwibm9uY2UiOiJQQVBQZjNoOWxleFR2M1dZSFp4OGFqVGUifQ.MbVwusjJsHbhYa-X2opfrahelrJ_ksIK2KKWq8rEiaZEdxIYVN1s4toIKDWoO7j5cJ5AU9HW2cii_-ZWaj3MeA'
}
}
JWT Header:
{
typ: 'openid4vci-proof+jwt',
alg: 'ES256',
kid: 'did:ebsi:zdPj1GPXjfERXxXPE1YTYdJ#7j3TpaNdPNTOzOtouOOknlOLQk3JP-ykTfraWtY3GME'
}
JWT Payload:
{
iss: 'did:ebsi:zdPj1GPXjfERXxXPE1YTYdJ',
aud: 'https://api-conformance.ebsi.eu/conformance/v3/issuer-mock',
iat: 1589699562,
exp: 1589699962,
nonce: 'PAPPf3h9lexTv3WYHZx8ajTe'
}
Step 12.:
After the successful request, the response payload will contain the requested credential.
Credential Response
HTTP Response for the POST request
Content-Type: application/json
{
format: 'jwt_vc',
credential: 'LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L',
c_nonce: 'fGFF7UkhLa',
c_nonce_expires_in: 86400
}
Tests
The client must pass all tests to be deemed conformant with the Accredit and Authorise module. The test module is split into three roles, each adding incremental capabilities. All flows in the test cases assume the previously mentioned authorisation with client credentials is operational and that the Legal Entity or Conformance Issuer possesses a valid access token.
Trusted Issuers
The Trusted Issuer role includes four basic capabilities:
- Creating a DID and DID document;
- Requesting onboarding and accreditation for an attestation;
- Registering these into the Trusted Issuers Registry; and
- Revoking a credential.
Create DID and DID document
The DID and DID document are self-generated and must NOT be registered. The DID must be did:ebsi v1 and the DID document must contain ES256 and ES256k1 public keys. ES256 is for authentication and assertionMethod, while ES256k1 is for capabilityInvocation.
Request VerifiableAuthorisationToOnboard and register DID document
A VerifiableAuthorisationToOnboard credential is required to register a new DID in the DID Registry.
After creating a DID and DID document, the Legal Entity must request a VerifiableAuthorisationToOnboard credential from the Conformance Issuer. This credential must be presented to the EBSI Authorisation server to obtain an Access Token, which is then used to gain write access to the DID Registry. The client must request the Presentation Definition with the scope=openid didr_invite to gain access to write to the DID Registry.
The access token is used with a signed Ethereum transaction to register the DID document. Refer to Filling Trusted Registries for further details. The VerifiableAuthorisationToOnboard credential must NOT be registered in the TIR.
The DID document's ID Token signature is not validated during the VerifiableAuthorisationToOnboard request, as the DID document is not yet registered.
Request VerifiableAccreditationToAttest and register into TIR
A VerifiableAccreditationToAttest credential is required to prove that the DID is allowed to participate in the trust chain as a Trusted Issuer. After registering the VerifiableAccreditationToAttest in the TIR, the client can include the TIR public endpoint in the issued VCs requiring accreditation.
After the Legal Entity has anchored the DID document, it must request a VerifiableAccreditationToAttest credential. The Conformance Issuer will invite the Legal Entity to participate in the trust chain by reserving a location and issuing the VerifiableAccreditationToAttest for that location. After receiving the credential, the client must complete the invitation by registering the credential into the TIR attribute defined by the credential's reservedAttributeId field.
The client must request the Presentation Definition from the EBSI Authorisation v3 service, with the scope=openid tir_invite to gain write access to the DID Registry
Completing the blockchain transaction, the Legal Entity will become a Trusted Issuer for the issued trust chain.
Issue CTRevocable Credential and revoke it
This test case will test the StatusList2021 implementation bound to CTRevocable Credentials.
The Conformance Issuer's Service Wallet will request a CTRevocable Credential from the test subject, now a Trusted Issuer. The test subject must issue a valid credential with StatusList2021 attached.
After a valid credential has been issued and validated by the Service Wallet, the Issuer must revoke the credential.
After revocation, the Conformance Wallet will check the revocation status through a publicly accessible endpoint linked to the credentialStatus details.
Trusted Accreditation Organisation
TAO's can extend the trust chain when the Root TAO accredits them to do so. To verify the TAO's accreditation capabilities, the Conformance Issuer creates a controlled sub-account, which will be a DID to receive the TAO's accreditation and authorisation flows. The sub-account will use its DID during credential issuance and is co-located in the same instance as the Conformance Issuer. The user controls the sub-account actions through the UI buttons, which execute requests towards the user defined client_id.
The sub-account DID's Method Specific Identifier (MSI) is calculated using the SHA-256 algorithm from the TAO's DID (test subject) MSI, truncated to 16 bytes. This allows the TAO to know beforehand what requests to expect.
Request VerifiableAccreditationToAccredit and register it into TIR
A VerifiableAccreditationToAccredit credential is required to prove that the DID can participate in the trust chain as a TAO. TAOs can onboard and accredit new Legal Entities into the trust chain.
Requesting a VerifiableAccreditationToAccredit credential follows the same process as as VerifiableAccreditationToAttest credentials, with the only difference being the type of credential. See How to request VerifiableAccreditationToAttest.
Issue VerifiableAuthorisationToOnboard for sub-account DID
TAOs can onboard Legal Entities, allowing them to write a DID document.
The user commands the sub-account through the UI, executing requests towards the user defined client_id.
The TAO receives the client's DID through the ID Token, which must exist in the issued VerifiableAuthorisationToOnboard.
The sub-account's DID is not yet anchored, thus the signature cannot be validated, but it demonstrates the capability to generate a DID and sign the ID Token. A VerifiableAuthorisationToOnboard should not be issued if it is already reserved, as it will fail later point. The TAO can use the client_id to whitelist the allowed applicants.
Issue VerifiableAccreditationToAttest for sub-account DID
TAOs can grant the right to issue Verifiable Credentials for accredited schemas and types.
The user commands the sub-account through the UI, executing requests towards the user defined client_id. The sub-account requests the VerifiableAccreditationToAttest credential to start the test case.
The TAO (test subject) must first create an invitation in the Trusted Issuers Registry with the attributes described in the table below. After creating the invitation, the TAO must issue a VerifiableAccreditationToAttest credential bound to the invitation's attributeId. This ID must be put into the credential's reservedAttributeId field. The Sub-account then accepts the invitation by writing the VC into the mentioned attributeId.
These are recorded as an attribute in the TIR with the following values:
| Field | Type | Meaning |
|---|---|---|
| DID | DID | Subject's DID (the sub-account) |
| TAO | DID | Accreditor's DID (the test subject) |
| RootTAO | DID | The Root of the trust chain (Conformance Issuer in test case) |
| IssuerType | Enumeration | Accredited role. Possible values are: RootTAO, TAO, TI, Revoked (TI in test case) |
Issue VerifiableAccreditationToAccredit for sub-account DID
TAOs can grant the right to accredit other legal entities for accredited schemas and types.
This test case follows the same process as the previous test case, except the TIR registry will contain a issuerType as TAO. See How to request VerifiableAccreditationToAttest.
These are recorded as an attribute in the TIR with the following values:
| Field | Type | Meaning |
|---|---|---|
| DID | DID | Subject's DID (sub-account DID) |
| RootTAO | DID | The Root of the trust chain (Conformance Issuer in test case) |
| TAO | DID | Accreditor's DID (The Issuer) |
| IssuerType | Enumeration | Accredited role. Possible values are: RootTAO, TAO, TI, Revoked (TAO in test case) |
Revoke Trusted Issuer rights from sub-account DID
Revocation of a VerifiableAccreditation is done through the Trusted Issuers Registry by a Root TAO or the one who made the invitation. The TAO must set the issuerType to equal Revoked to revoke an existing VerifiableAccreditation or the invitation. VerifiableAccreditations must contain a credentialStatus with the type EbsiAccreditation, the validity of which is determined by the smart contract.
Root Trusted Accreditation Organisation
Root TAOs are invited through EBSI and must conform with EBSI Issuer pre-registration and credential issuance.
Request VerifiableAuthorisationForTrustChain and register it into TIR
The Legal Entity must request a VerifiableAuthorisationForTrustChain credential. The Conformance Issuer will invite the Legal Entity to participate in the Trust Chain by reserving a location and issuing the VerifiableAuthorisationForTrustChain for that location. After the client has received the credential, it must complete the invitation by registering the credential into the TIR attribute defined by the credential's reservedAttributeId field.
After registering the VerifiableAuthorisationForTrustChain into the TIR, the client MUST include the TIR public endpoint in the issued accreditations.
The difference with other Verifiable Credential Requests are the following:
- The DID document's key must be equal to the pre-registered key.
- A VP Token is requested instead of an ID Token. The VP Token contains the
VerifiableAuthorisationToOnboardsigned by the specific Issuer. - The Credential endpoint uses deferred flow instead of plain in-time flow, as the actual authorisation is not instant. The test emulates a delay of five seconds and uses a deferred credential endpoint.