High-Level PID flow¶

The Fig. 2 shows a general architecture and highlights the main operations involved in the issuance of a PID.

Below a detailed description for each step represented in the previous picture:

0. Wallet Instance Setup: the first time the Wallet Instance is started a preliminary setup phase MUST be carried out. It consists of the release of a verifiable proof issued by the Attestation Service provided by the Wallet Provider that asserts the genuineness, the authenticity and the compliance with a trust framework of the Wallet Instance. The verifiable proof binds a public key corresponding to a local private key generated by the Wallet Instance.

1. Obtaining the trusted PID Provider: the Wallet Instance discovers the trusted PID Provider using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), and then inspects the metadata looking for the availability of the PID credential.

2. Obtaining of PID Provider Metadata: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs.

3. PID Request: following the Authorization Code Flow in [OIDC4VCI. Draft 13] the Wallet Instance requests a PID to the PID Provider. A fresh key pair that is generated by the Wallet Instance for the purpose of the sender-constrained Access Token will be used by the PID Provider for the Holder Key Binding of the PID.

4. User Authentication: the PID Provider authenticates the User with LoA High, acting as an IAM Proxy to the National eID system.

5. PID Issuance: once the User authentication with LoA High happens, the User gives their consent, and the PID Provider releases a PID bound to the key material held by the requesting Wallet Instance.

In the following sections the steps from 1 to 5 are further expanded into more technical details.

High-Level (Q)EAA flow¶

The Fig. 3 shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, following the assumptions listed below:

• the User has a valid PID stored in their own Wallet Instance;

• the (Q)EAA requires a high security implementation profile.

Below the description of the most relevant operations involved in the (Q)EAA issuance:

1. Obtaining the trusted (Q)EAA Issuer: the Wallet Instance discovers the trusted (Q)EAA Issuer ufing the Federaiton API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata looking for the credential capabilities.

2. Obtaining of (Q)EAA Provider Metadata: the Wallet Instance establishes the trust to the (Q)EAA Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs.

3. (Q)EAA Request: according to the Authorization Code Flow in [OIDC4VCI. Draft 13] the Wallet Instance requests a (Q)EAA to the (Q)EAA Provider. A fresh key pair that is generated by the Wallet Instance for the sender-constrained Access Token TO be used by (Q)EAA Provider for the key binding of the (Q)EAA. The (Q)EAA Provider checks the Wallet Instance by means of the Wallet Instance Attestation and the Trust Chain related to the Wallet Provider.

4. User Authentication: the (Q)EAA Provider, acting as a Verifier (Relying Party), authenticates the User evaluating the presentation of the PID.

5. (Q)EAA Issuance: Once the User has been authenticated with a valid PID, the User gives their consent, then the (Q)EAA Provider releases a (Q)EAA bound to the key material held by the requesting Wallet Instance.

Detailed Flow¶

The PID/(Q)EAA Issuance phase is based on the Authorization Code Flow with Pushed Authorization Requests (PAR) [RFC 9126] and PKCE (Proof Key for Code Exchange, RFC 7636) as recommended in [OIDC4VCI. Draft 13. Section 3.4]. A Wallet Initiated Flow is involved and the User receives the PID/(Q)EAA directly in response to the Credential Request (Immediate Flow).

Steps 1-4 (Discovery): The User selects the PID/(Q)EAA Provider, and the Wallet Instance obtains the Metadata for the selected PID/(Q)EAA Provider.

Steps 5-6 (PAR Request): The Wallet Instance creates a fresh PKCE code verifier, and state parameter for the Pushed Authorization Request. The Wallet Instance sends these parameters along in a Pushed Authorization Request using the OIDC request parameter (hereafter Request Object) (see RFC 9126 Section 3) to the PID/(Q)EAA Provider PAR endpoint to prevent Request URI swapping attack (see RFC 9126). The Wallet Instance MUST create the code_verifier with enough entropy random string using the unreserved characters with a minimum length of 43 characters and a maximum length of 128 characters, making it impractical for an attacker to guess its value. The value MUST be generated following the recommendation in Section 4.1 of RFC 7636. The Wallet Instance signs this request using the private key that is created during the setup phase to obtain the Wallet Instance Attestation. The related public key that is attested by the Wallet Provider is inside the Wallet Instance Attestation cnf claim.. An OAuth2 client authentication method is involved, since in this flow the Pushed Authorization Endpoint is a protected endpoint. The client authentication is based on the model defined in [RFC 7521] using the Wallet Instance Attestation JWS inside the client_assertion parameter. The authorization_details [RAR RFC 9396] parameter is extended to allow Wallet Instance to specify the types of credentials when requesting authorization for the PID/(Q)EAA issuance. The PID/(Q)EAA Provider performs the following checks upon the receipt of the PAR request:

1. It MUST validate the signature of the Request Object using the algorithm specified in the alg header parameter (RFC 9126, RFC 9101) and the public key that can be retrieved from the Wallet Instance Attestation (cnf) identified using the kid header of the Request Object.

2. It MUST check that the used algorithm for signing the request in the alg header is among the appropriate once reported in Section Cryptographic Algorithms.

3. It MUST check that the client_id in the request body of the PAR request matches the client_id claim in the Request Object.

4. It MUST check that the iss claim in the Request Object matches the client_id claim in the Request Object (RFC 9126, RFC 9101).

5. It MUST check that the aud claim in the Request Object is equal to the identifier of PID/(Q)EAA Provider (RFC 9126, RFC 9101).

6. It MUST reject the PAR request, if it contains the request_uri parameter (RFC 9126).

7. It MUST check that the Request Object contains all the mandatory parameters and their values are validated according to what we defined in Table of the HTTP parameters [derived from RFC 9126].

8. It MUST check that the Request Object is not expired by checking the exp claim (RFC 9126).

9. It MUST check that the Request Object was issued at a time acceptable by the PID/(Q)EAA Provider by checking the iat claim. For example, basing on the security policies of the PID/(Q)EAA Provider, it might reject the request if the iat claim is too far away from the current time (RFC 9126).

10. It MUST check that the jti claim in the Request Object has not been used before by the Wallet Instance identified by the client_id. This allows the PID/(Q)EAA Provider to mitigate replay attacks (RFC 7519).

Below a non-normative example of the PAR.

POST /as/par HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KIC Jpc3MiOiAiczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo gInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNkJoZFJrcXQz IiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1...
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
&client_assertion=$WalletInstanceAttestation$

The JWS header of Request Object is represented below:

{
  "alg": "ES256",
  "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc",
}

The JWS payload of the Request Object is represented below:

{
"iss":"$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$",
"aud":"https://pid-provider.example.org",
"exp":1672422065,
"iat": 1672418465,
"jti":"ac80df576e7109686717bf50b869e882",
"response_type":"code",
"client_id":"$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$",
"state":"fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd",
"code_challenge":"E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
"code_challenge_method":"S256",
"authorization_details":[
{
    "type":"openid_credential",
    "format": "vc+sd-jwt",
    "credential_definition": {
        "type": "PersonIdentificationData"
    }
}
],
"redirect_uri":"eudiw://start.wallet.example.org",
"client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation",
}

Step 7 (PAR Response): The PID/(Q)EAA Provider MUST issue the request_uri one-time use and bind it to the client identifier (client_id) that is provided in the Request Object. Furthermore, the entropy of the request_uri MUST be sufficiently large. The adequate shortness of the validity and the entropy of the request_uri depends on the risk calculation based on the value of the resource being protected. The validity time SHOULD be less than a minute, and the request_uri MUST include a cryptographic random value of 128 bits or more (RFC 9101). The entire request_uri SHOULD NOT exceed 512 ASCII characters due to the following two main reasons (RFC 9101):

1. Many phones on the market still do not accept large payloads. The restriction is typically either 512 or 1024 ASCII characters.

2. On a slow connection such as a 2G mobile connection, a large URL would cause a slow response; therefore, the use of such is not advisable from the user-experience point of view.

The PID/(Q)EAA Provider returns the issued request_uri to the Wallet Instance.

HTTP/1.1 201 Created
Cache-Control: no-cache, no-store
Content-Type: application/json

{
    "request_uri":"urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
    "expires_in": 60
}

Steps 8-9 (Authorization Request): The Wallet Instance sends an authorization request to the PID/(Q)EAA Provider Authorization Endpoint. Since parts of this Authorization Request content, e.g., the code_challenge parameter value, are unique to a particular Authorization Request, the Wallet Instance MUST only use a request_uri value once (RFC 9126); The PID/(Q)EAA Provider performs the following checks upon the receipt of the Authorization Request:

1. It MUST treat request_uri values as one-time use and MUST reject an expired request. However, it MAY allow for duplicate requests due to a user reloading/refreshing their user-agent (derived from RFC 9126).

2. It MUST identify the request as a result of the submitted PAR (derived from RFC 9126).

3. It MUST reject all the Authorization Requests that do not contain the request_uri parameter as the PAR is the only way to pass the Authorization Request from the Wallet Instance (derived from RFC 9126).

GET /authorize?client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: pid-provider.example.org

Steps 10-11 (Authorization Response): The PID/(Q)EAA Provider sends an authorization code together with state and iss parameters to the Wallet Instance. The Wallet Instance performs the following checks on the Authorization Response:

1. It MUST check the Authorization Response contains all the defined parameters according to Table of the HTTP Response parameters.

2. It MUST check the returned value by the PID/(Q)EAA Provider for state parameter is equal to the value sent by Wallet Instance in the Request Object (RFC 6749).

3. It MUST check that the URL of PID/(Q)EAA Provider in iss parameter is equal to the URL identifier of intended PID/(Q)EAA Provider that the Wallet Instance start the communication with (RFC 9027).

HTTP/1.1 302 Found
Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org

Steps 12-13 (DPoP Proof for Token Endpoint): The Wallet Instance MUST create a new key pair for the DPoP and a fresh DPoP Proof JWT following the instruction provided in Section 4 of (RFC 9449) for the token request to the PID/(Q)EAA Provider. The DPoP Proof JWT is signed using the created private key for DPoP by Wallet Instance. DPoP provides a way to bind the Access Token to a certain sender (Wallet Instance) (RFC 9449). This mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP Proof JWT.

Step 14 (Token Request): The Wallet Instance sends a token request to the PID/(Q)EAA Provider Token Endpoint using the authorization code, code_verifier, DPoP Proof JWT and private_key_jwt parameters (client_assertion_type and client_assertion). The client_assertion is signed using the private key that is created during the setup phase to obtain the Wallet Instance Attestation. The related public key that is attested by the Wallet Provider is provided within the Wallet Instance Attestation (cnf claim). The PID/(Q)EAA Provider performs the following checks on the Token Request:

1. It MUST authenticate the Wallet Instance based on the private_key_jwt Client Authentication method OpenID.Core#TokenRequest.

2. It MUST ensure that the Authorization code is issued to the authenticated Wallet Instance (RFC 6749).

3. It MUST ensure the Authorization code is valid and has not been previously used (RFC 6749).

4. It MUST ensure the redirect_uri is identical to the value that was initially included in the Request Object OpenID.Core#TokenRequest.

5. It MUST validate the DPoP Proof JWT following the steps in Section 4.3 of (RFC 9449).

POST /token HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
    VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
    nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE
    QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj
    oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia
    WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg
    4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$
&grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=eudiw://start.wallet.example.org
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJIUzI1NiI

Step 15 (Token Response): The PID/(Q)EAA Provider validates the request and if it is successful, it issues an Access Token (bound to the DPoP key) and a fresh c_nonce.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
"access_token": "Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU",
"token_type": "DPoP",
"expires_in": 2677,
"c_nonce": "tZign[...]snFbp",
"c_nonce_expires_in": 86400
}

Steps 16-17 (DPoP Proof for Credential Endpoint): The Wallet Instance creates a proof of possession with the DPoP key following the steps in Section 7.2.1 of OPENID4VCI and the c_nonce obtained in Step 15 and it creates a DPoP Proof JWT based on Section 4 of (RFC 9449) for the request to the PID/(Q)EAA credential issuance endpoint. The jwk value in the proof parameter MUST be equal to the public key generated for the DPoP.

Step 18 (Credential Request): The Wallet Instance requests a PID/(Q)EAA issuance to the PID/(Q)EAA credential endpoint. The request MUST contain the Access Token, the DPoP Proof JWT, and the credential type, the proof (proof of possession of the key) and the format parameters.

POST /credential HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik
    VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR
    nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R
    1JEQSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIj
    oiR0VUIiwiaHR1IjoiaHR0cHM6Ly9yZXNvdXJjZS5leGFtcGxlLm9yZy9wcm90ZWN0Z
    WRyZXNvdXJjZSIsImlhdCI6MTU2MjI2MjYxOCwiYXRoIjoiZlVIeU8ycjJaM0RaNTNF
    c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E
    OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA

credential_definition=%7B%22type%22:%5B%22PersonIdentificationData%22%5D%7D
&format=vc+sd-jwt
&proof=%7B%22proof_type%22:%22...-ace0-9c5210e16c32%22%7D

A non-normative example of proof parameter is given below:

{
"proof_type": "jwt",
"jwt": "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYm …"
}

Where the decoded content of the JWT is represented below:

{
  "alg": "ES256",
  "typ": "openid4vci-proof+jwt",
  "jwk": {
    "kty": "EC",
    "x": "l8tFrhx-34tV3hRICRDY9zCkDlpBhF42UQUfWVAWBFs",
    "y": "9VE4jf_Ok_o64zbTTlcuNJajHmt6v9TDVrU0CdvGRDA",
    "crv": "P-256"
  }

}

{
"iss": "0b434530-e151-4c40-98b7-74c75a5ef760",
"aud": "https://pid-provider.example.org",
"iat": 1504699136,
"nonce": "tZign...snFbp"
}

Steps 19-21 (Credential Response): The PID/(Q)EAA Provider MUST validate the DPoP JWT Proof based on the steps defined in Section 4.3 of (RFC 9449) and whether the Access Token is valid and suitable for the requested PID/(Q)EAA. It also MUST validate the proof of possession for the key material the new credential SHALL be bound to following the steps in Section 7.2.2 of OPENID4VCI. If all checks succeed, the PID/(Q)EAA Provider creates a new credential bound to the key material and provide it to the Wallet Instance. The Wallet Instance MUST perform the following checks before proceeding with the secure storage of the PID/(Q)EAA credential:

1. It MUST check that the PID Credential Response contains all the mandatory parameters and values are validated according to Table of the credential response parameters.

2. It MUST check the PID integrity by verifying the signature using the algorithm specified in the alg header parameter of SD-JWT (PID/(Q)EAA Data Model) and the public key that is identified using using the kid header of the SD-JWT.

3. It MUST check that the received PID credential (in credential claim) contains all the mandatory parameters defined in PID/(Q)EAA Data Model.

4. It MUST process and verify the PID that is in SD-JWT VC following the steps in Section 6 of SD.JWT#Verification.

5. It MUST verify the Trust Chain in the header of SD-JWT VC to verify that the PID Provider is trusted.

If the checks defined above are successful the Wallet Instance proceeds with the secure storage of the PID credential.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
"format": "vc+sd-jwt"
"credential" : "LUpixVCWJk0eOt4CXQe1NXK[...]WZwmhmn9OQp6YxX0a2L",
"c_nonce": "fGFF7[...]UkhLa",
"c_nonce_expires_in": 86400
}

Pushed Authorization Request Endpoint¶

Authorization endpoint¶

The authorization endpoint is used to interact with the PID/(Q)EAA Issuer and obtain an authorization grant. The authorization server MUST first verify the identity of the User that own the credential.

Token endpoint¶

The token endpoint is used by the Wallet Instance to obtain an Access Token by presenting its authorization grant, as defined in RFC 6749.

Credential endpoint¶

The Credential Endpoint issues a credential as approved by the End-User upon presentation of a valid Access Token representing this approval, as defined in OPENID4VCI.

HTTP/1.1 200 OK
Content-Type: application/entity-statement+jwt

{

  "alg": "RS256",
  "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
  "typ": "entity-statement+jwt"

}
.
{
  "exp": "1649610249",
  "iat": "1649437449",
  "iss": "https://pid-provider.example.org",
  "sub": "https://pid-provider.example.org",
  "jwks": {
    "keys": [{
      "kty": "RSA",
      "use": "sig",
      "n": "1Ta-sE …",
      "e": "AQAB",
      "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
    }]
  },
  "metadata": {
    "openid_credential_issuer": {
      "credential_issuer": "https://pid-provider.example.org",
      "authorization_endpoint": "https://pid-provider.example.org/connect/authorize",
      "token_endpoint": "https://pid-provider.example.org/connect/token",
      "pushed_authorization_request_endpoint": "https://pid-provider.example.org/connect/par",
      "dpop_signing_alg_values_supported": ["RS256", "RS512", "ES256", "ES512"],
      "credential_endpoint": "https://pid-provider.example.org/credential",
       "jwks": {
         "keys": [
         {
            "crv": "P-256",
            "kty": "EC",
            "x": "newK5qDYMekrCPPO-yEYTdJVWJMTzasMavt2vm1Mb-A",
            "y": "VizXaLO6dzeesZPxfpGZabTK3cTXtBUbIiQpmiYRtSE",
            "kid": "ff0bded045fe63fe5d1d64dd83b567e0"
          }]
        }
      "credentials_supported": [
        {
          "format": "vc+sd-jwt",
          "id": "eudiw.pid.it",
          "cryptographic_binding_methods_supported": ["jwk"],
          "cryptographic_suites_supported": ["RS256", "RS512", "ES256", "ES512"],
          "display": [{
              "name": "PID Provider Italiano di esempio",
              "locale": "it-IT",
              "logo": {
                "url": "https://pid-provider example.org/public/logo.svg",
                "alt_text": "logo di questo PID Provider"
              },
              "background_color": "#12107c",
              "text_color": "#FFFFFF"
            },
            {
              "name": "Example Italian PID Provider",
              "locale": "en-US",
              "logo": {
                "url": "https://pid-provider.example.org/public/logo.svg",
                "alt_text": "The logo of this PID Provider"
              },
              "background_color": "#12107c",
              "text_color": "#FFFFFF"
            }
          ],
          "credential_definition": {
            "type": ["PersonIdentificationData"],
            "credentialSubject": {
              "given_name": {
                "mandatory": true,
                "display": [{
                    "name": "Current First Name",
                    "locale": "en-US"
                  },
                  {
                    "name": "Nome",
                    "locale": "it-IT"
                  }
                ]
              },
              "family_name": {
                "mandatory": true,
                "display": [{
                    "name": "Current Family Name",
                    "locale": "en-US"
                  },
                  {
                    "name": "Cognome",
                    "locale": "it-IT"
                  }
                ]
              },
              "birthdate": {
                "mandatory": true,
                "display": [{
                    "name": "Date of Birth",
                    "locale": "en-US"
                  },
                  {
                    "name": "Data di Nascita",
                    "locale": "it-IT"
                  }
                ]
              },
              "place_of_birth": {
                "mandatory": true,
                "display": [{
                    "name": "Place of Birth",
                    "locale": "en-US"
                  },
                  {
                    "name": "Luogo di Nascita",
                    "locale": "it-IT"
                  }
                ]
              },
              "unique_id": {
                "mandatory": true,
                "display": [{
                    "name": "Unique Identifier",
                    "locale": "en-US"
                  },
                  {
                    "name": "Identificativo univoco",
                    "locale": "it-IT"
                  }
                ]
              },
              "tax_id_code": {
                "mandatory": true,
                "display": [{
                    "name": "Tax Id Number",
                    "locale": "en-US"
                  },
                  {
                    "name": "Codice Fiscale",
                    "locale": "it-IT"
                  }
                ]
              }
            }
          }
        }
      ]
    },

    "federation_entity": {
      "organization_name": "Pid Provider Organization Example",
      "homepage_uri": "https://pid-provider.example.org",
      "policy_uri": "https://pid-provider.example.org/privacy_policy",
      "tos_uri": "https://pid-provider.example.org/info_policy",
      "logo_uri": "https://pid-provider.example.org/logo.svg"
    },

    "openid_relying_party": {
      <This is the metadata of the PID Provider acting as a Relying Party in the national digital identity framework (CIE/SPID). See spid-cie-oidc-docs for details.>
    }
  }
}