Accredit RTAO, TAO and TI

Context

This document describes the Accredit and Authorise test module flows from 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's trust model and asserts the correctness of content written into the Trusted Registries.

The authentication of a Legal Entity by a Conformance Issuer is achieved using an ID Token. The Root TAO is an exception, as its authentication is reinforced with its DID document's authentication key. The authentication key must be pre-registered before initiating authentication. Conformance Issuers should implement authentication by a Verifiable Presentation exchange with Verifiable Credentials, requesting an id_token and authenticating a DID by OIDC ecosystem capabilities, or by pre-registration.

Conformance Authorisation Mock (Auth Mock) and Credential Issuer Mock (Issuer Mock) have separate functions. Auth Mock handles access management, and Issuer Mock supports credential issuance.

The flow contains four parties:

Client: the test subject
Auth Mock: the Issuer's backend for Authorisation Service
- The configuration can be found from /.well-known/openid-configuration
Issuer Mock: the Issuer's backend for credential issuance
- The configuration can be found from /.well-known/openid-credential-issuer
EBSI Authorisation Service and Registries: the EBSI platform

Requesting and Issuing Verifiable Credentials

Credential Issuers expose OpenID Credential Issuer Configuration through the ./well-known/openid-credential-issuer endpoint. The configuration exposes available credentials in the credentials_supported field, and it also contains authorization_server field to locate Authorisation Server for access token. The client should check if the credential in question is part of the list and proceed further with the supported credential types.

DID transmitted in 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 in this case the DID must not exist in the registry. Conformance Test requires ID Token for authentication, but other authentication means can be used in place of ID Token authentication.

Requesting and issuing mirrors the participants.

Discovery

Steps 1 and 2:
The client resolves authorization_server and credentials_supported through the ./well-known/openid-credential-issuer configuration. Credential issuer's configuration has authorization_server pointing towards external Authorisation Server, with a own client_id.

Example

Please see Credential Issuer Metadata specification for further details.

Steps 3 and 4:
The client resolves Authorisation Server's configuration through the Authorisation Server's ./well-known/openid-configuration. The configuration exposes the Authorisation Server configuration and how it can be used.

Example

Please see Authorisation Server Metadata specification for further details.

Authorisation and Authentication

Step 5:
At this point, the client understands the two services' capabilities and all supported credentials, thus discovery has been completed. 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 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:

ID Token

ID Token is requested and responded to demonstrate how authentication can be done. Other User Authentication means can be used in place of ID Token, and it may be fully omitted if identity does not need to be known for the authorisation purposes.

The Mock Auth validates the request and proceeds by requesting authentication of a DID from the client. The ID Token Request is also an Authorisation Request, and it MUST be signed Request Object.

The Request Object is signed with Authorisation Server's (Auth Mock) private keys, which are discoverable through 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 proceeds by issuing an ID Token signed by the DID document's authentication key. This will be used to prove the subject identity through the control of the DID. If client is requesting 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 "Authorization Server." In such cases, the Client must ensure that the values of the state parameter are identical in both.

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 original authorisation request to assert if access should be granted. Upon successful authentication, the direct_post endpoint returns a redirect into 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 Token Endpoint with the required details and signs 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. c_nonce (Challenge Nonce) must be stored by client until a new one is given. The first c_nonce can be transmitted from Authorisation Server to Conformance Issuer through 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:
At this point, the client has successfully obtained a valid access_token, which can be used to gain access into the Credential Issuer's Credential Endpoint.

The client proceeds by requesting 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 equal the one used in 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 the tests to be deemed conformant with the Accredit & Authorise module. The test module is split into 3 different roles, which adds incremental capabilities. All flows in the test cases expect that the previously mentioned authorisation with client credentials work and the Legal Entity or Conformance Issuer has a proper access token.

Trusted Issuers

The Trusted Issuer has four basic capabilities that include:

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. DID must be did:ebsi v1 and the DID document must have ES256 and ES256k1 public keys. ES256 is for authentication and assertionMethod, while ES256k1 is for capabilityInvocation.

Request VerifiableAuthorisationToOnboard and register DID document

VerifiableAuthorisationToOnboard is required to be able to register a new DID into 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 in exchange for an Access Token, which is used to gain access to write into the DID Registry. Client must request Presentation Definition with scope=openid didr_invite to be able to gain access to write into DID Registry.

The access token will be used with the signed Ethereum transaction to register the DID document. See Filling Trusted Registries for more information. The VerifiableAuthorisationToOnboard credential must NOT be registered into the TIR.

DID document's ID Token signature is not validated during VerifiableAuthorisationToOnboard`, as the DID document is not yet registered.

Request VerifiableAccreditationToAttest and register into TIR

A VerifiableAccreditationToAttest is required to prove that the DID is allowed to participate in the trust chain as a Trusted Issuer. After registering the VerifiableAccreditationToAttest into TIR, the client can include the TIR public endpoint into the issued VCs which needs the Accreditation.

After the Legal Entity has anchored the DID document, it must request VerifiableAccreditationToAttest. 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 the client has received the credential, it must complete the invitation by registering the credential into the TIR attribute defined by the credentials reservedAttributeId field.

Client must request Presentation Definition, from EBSI Authorisation v3 service, with scope=openid tir_invite to be able to gain access to write into DID Registry

Completing the blockchain transaction, the Legal Entity will become Trusted Issuer for the issued Trust Chain.

Issue CTRevocable Credential and revoke it

This test case will test StatusList2021 implementation bound into CTRevocable.

The Conformance Issuer's Service Wallet will request a CTRevocable from the test subject, which is now a Trusted Issuer. The test subject must issue a valid credential with StatusList2021 attached to the issued credential.

After a valid credential has been issued to the Service Wallet and has been validated, the issuer must revoke the credential.

After revocation has been completed, 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 gives them the accreditation to accredit. 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 the credential issuance and is co-located in the same instance as the Conformance Issuer. User controls the sub-account actions through the UI buttons, which will execute requests towards the user defined client_id.

The sub-account DID's Method Specific Identifier (MSI) is calculated with the algorithm of sha256 from 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 is required to prove that the DID is allowed to participate in the trust chain as a Trusted Accreditation Organisation. TAO's can onboard and accredit new Legal Entities into the trust chain.

Requesting VerifiableAccreditationToAccredit works exactly the same way as VerifiableAccreditationToAttest, the only difference is the type of the credential. See How to request VerifiableAccreditationToAttest.

Issue VerifiableAuthorisationToOnboard for sub-account DID

TAO's can onboard Legal Entities, which allows them to write a DID document.

User commands the sub-account through the UI, which will execute requests towards the user defined client_id. TAO will receive 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 is demonstrating the capability to generate a DID and sign of the ID Token. VerifiableAuthorisationToOnboard should not be issued if it is already reserved, as it will just fail at later point. 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 its types.

User commands the sub-account through the UI, which will execute requests towards the user defined client_id. The sub-account will request the VerifiableAccreditationToAttest to start the test case.

TAO (test subject) must first create an invitation into the Trusted Issuers Registry with the attributes described on the table below. After creating the invitation, the TAO must proceed by issuing a VerifiableAccreditationToAttest bound into the invitation's attributeId. This id must be put into the credential's reservedAttributeId field. The Sub-account will then accept the invitation, by writing the VC into the mentioned attributeId.

These are recorded as an attribute in TIR with 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 its types.

The test case works exactly like 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 TIR with 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 will be done through the Trusted Issuer Registry, by Root TAO or the one who made the invitation. The TAO must make the issuerType to equal Revoked to revoke existing VerifiableAccreditation or the invitation. VerifiableAccreditations must contain credentialStatus with type EbsiAccreditation, which validity 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 VerifiableAuthorisationForTrustChain. 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 TIR, the client MUST include the TIR public endpoint into the issued Accreditations.

The difference to other Verifiable Credential Requests are the following:

The DID document's key must be equal to the pre-registered key.
A VP Token will be requested instead of an ID Token. The VP Token contains the VerifiableAuthorisationToOnboard signed 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 5 seconds and uses a deferred credential endpoint.

Context​

Vocabulary​

Guidelines​

Requesting and Issuing Verifiable Credentials​

Discovery​

Authorisation and Authentication​

Credential Issuance​

Tests​

Trusted Issuers​

Create DID and DID document​

Request VerifiableAuthorisationToOnboard and register DID document​

Request VerifiableAccreditationToAttest and register into TIR​

Issue CTRevocable Credential and revoke it​

Trusted Accreditation Organisation​

Request VerifiableAccreditationToAccredit and register it into TIR​

Issue VerifiableAuthorisationToOnboard for sub-account DID​

Issue VerifiableAccreditationToAttest for sub-account DID​

Issue VerifiableAccreditationToAccredit for sub-account DID​

Revoke Trusted Issuer rights from sub-account DID​

Root Trusted Accreditation Organisation​

Request VerifiableAuthorisationForTrustChain and register it into TIR​