Overview

This page specifies a Pub-EEA Wallet Issuing Service as needed in Synergy 5 of the OOTS - EUDI Wallet synergies proof-of-concept.

Pub-EEA Wallet Issuing Service 

The wallet triggers the credential issuance workflow by calling a credential offering deep link with this format:

openid-credential-offer://?credential_offer_uri=ENCODED_URL

The encoded URL format is not standardised, but the implementation for the PoC will use the following convention:

https://[DOMAIN]/issuer/[ISSUER's DID:KEY]/credential-offer?credential-identifier=[Evidence/Credential Type]

The response obtained when calling the deep link is similar to the following:

{
    "credentials": [
        {
            "format": "jwt_vc",
            "types": [
                "VerifiableCredential",
                "VerifiableAttestation",
                "CTWalletSameAuthorisedInTime"
            ],
            "trust_framework": {
                "name": "ebsi",
                "type": "Accreditation",
                "uri": "TIR link towards accreditation"
            }
        }
    ],
    "grants": {
        "authorization_code": {
            "authorization_server": "https://wallet-auth-mock.preprod.kaytrust.id"
        }
    },
    "credential_issuer": "https://issuance.preprod.kaytrust.id/issuer/did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9KbndPZwZdDNWhmLXsumWsx3QjsyPUaom15cgySHS2K27aSdrqBzZ9kSJHWKkDiQQ26gc7zCDVfvrzyuumtFNUBDMPEBqeodyAM6krZSvNDo7zWvt319Lxhd9dTEKMAAfLgbN"
}

The wallet will now request access to the authorisation server, which is configured to request a PID verifiable presentation. After the presentation and internal verification of the presented credential, the authorisation server provides a VP_Token, granting access to the credential issuer endpoint.

Discovery of Pub-EEA Issuing Service Providers

Overview

The service requesting application does not know the Verification Provider, its Access Service or the Evidence Type Classification and discovers these using the OOTS Common Services. 

Discovery of Attestation Type

If the service requesting Wallet application does not know the attestation type, it MAY use the Evidence Broker using the API provided by the OOTS Common Services:

https://oots.pages.code.europa.eu/tdd/apidoc/evidence-broker 

No changes in API or other functionality are required on the side of the Evidence Broker.

Alternatively, the application may use the Semantic Repository using an API to be defined.

Data Service Directory

If the service requesting Wallet application does not know the attestation issuer,  its URL or the attestation type classification, it shall discover this using the API of the OOTS Data Service Directory. 

https://oots.pages.code.europa.eu/tdd/apidoc/data-services-directory

Specifically, it will use an extended version of the following API:

https://oots.pages.code.europa.eu/tdd/apidoc/data-services-directory/find-data-services

The extension is described in the following RFC on the Common Services:   EUDI Wallet Extensions. The extension adds an additional optional query parameter to the DSD Query, named "specification" that will be act as a filter for the access services. Its value is a version of the one of the three specifications and if absent, for backwards compatibility, it will assume the default oots specification e.g. oots-edm:1.0. For the issuing service,  the parameter shall be set in queries and set to the  value "eudi-pubeea-is:1.0".  This will instruct the Data Service Directory to only return data for Pub-EAA issuers.

The DSD response to lookups for the verification services follow the DSD API specification and the full specification provided in the OOTS Technical Design Documents, except that response data is filtered such that only AccessService elements that have their ConformsTo set to the value "eudi-pubeea-is:1.0" are returned.

In the response, the value of the AccessService subelement Identifier shall be set to a URI resolvable on the public Internet that uniquely identifies the attestation issuer and the requested Pub-EAA attestation type.  It shall follow the expected URI pattern described in section 2 above.

Unlike Evidence Exchange or Verification, the schemeID attribute shall not be used.

This Pub-EEA issuing service will request the PID data of the Wallet user and then issue a Pub-EAA of the requested attestation type to the user.     


  • No labels