Credential Data Model IDA

[fmarino-ipzs]

The current Digital Credential Data Model, draws from the OpenID Identity Assurance Profile [OIDC.IDA], needs the changes described below:

• The verified_claims parameter be capable of holding an ARRAY of JSON objects, each corresponding to different authentic sources, rather than a single JSON object tied to a singular authentic source. This adjustment is essential to accommodate evidence from multiple data providers, trust frameworks and identity proofing procedures that underpin the issuance.
• the user attributes contained in the verified_claims.claims object require to be duplicated in the top-level of the json, otherwise we have a lack interoperability with RPs that don't support IDA (since SD-JWT VC data model doesn't support IDA).

As a potential solution, we could consider modifying the data model in the following way, providing in the JSON top-level the user claims (that then results duplicated within the verified_claims.claims objects):

{
  "unique_id": "xxxxxxxx-xxxx-xxx",
  "given_name": "Mario",
  "family_name": "Rossi",
  "birth_date": "1980-01-10",
  "email": "verified@email.example.org",
  "birth_place": {
    "country": "IT",
    "locality": "Rome"
  },
  "verified_claims":
    {
      "verification": {
        "trust_framework": "eidas",
        "assurance_level": "high",
        "evidence": [
          {
            "type": "electronic_record",
            "record": {
              "type": "https://eudi.wallet.cie.gov.it",
              "source": {
                "organization_name": "Ministero dell'Interno",
                "organization_id": "m_it",
                "country_code": "IT"
              }
            }
          }
        ],
        "claims": {
          "unique_id": "xxxxxxxx-xxxx-xxx",
          "given_name": "Mario",
          "family_name": "Rossi",
          "birth_date": "1980-01-10",
          "birth_place": {
            "country": "IT",
            "locality": "Rome"
          }
        }
      }
    }
}

This implies that verified_claims is an additional claim given as a JSON object that an RP adopting IDA is able to process and an RP is not interested in the IDA profile may ignore it without breaking changes. The cons of this proposal is that we have the User Claims duplicated in the Credential.

In case we may have user claims coming from different Authentic Sources we can consider having verified_claims as an array of JSON Objects as in the following example

{
  "unique_id": "xxxxxxxx-xxxx-xxx",
  "given_name": "Mario",
  "family_name": "Rossi",
  "birth_date": "1980-01-10",
  "email": "verified@email.example.org",
  "birth_place": {
    "country": "IT",
    "locality": "Rome"
  },
  "verified_claims": [
    {
      "verification": {
        "trust_framework": "eidas",
        "assurance_level": "high",
        "evidence": [
          {
            "type": "electronic_record",
            "record": {
              "type": "https://eudi.wallet.cie.gov.it",
              "source": {
                "organization_name": "Ministero dell'Interno",
                "organization_id": "m_it",
                "country_code": "IT"
              }
            }
          }
        ],
        "claims": {
          "unique_id": "xxxxxxxx-xxxx-xxx",
          "given_name": "Mario",
          "family_name": "Rossi",
          "birth_date": "1980-01-10",
          "birth_place": {
            "country": "IT",
            "locality": "Rome"
          }
        }
      }
    },
    {
    "verification": { ... ,
    "claims": {
      "email": "verified@email.example.org",
      }
    }
    }
  ]
}

[peppelinux]

Additional requirements and implementation considerations include:

• Users specify which attributes they are disclosing by name, rather than by the location of the attribute within the data structure. This approach applies to both nested claims within verified_claims and claims at the top level. This requirement could affect the structure-agnostic nature of sd-jwt payloads: the wallet instance should bring a good UX providing disclosure for attributes by names, and not by location/path/position. Eg: disclosing given_name produces the disclosure of both the top-level claim and the ones in the verified_claims.claims.

• In instances where a claim from one authentic source contradicts a claim from another, it falls to the Verifiable Credential Issuer (VCI) to determine which source has hierarchical precedence. The VCI must then choose which version of the conflicting claim to use.

• If claims from different authentic sources conflict, the VCI is required to select the claim from the hierarchically superior source for inclusion in verified_claims. Any conflicting claims should be omitted from the response to prevent misunderstandings regarding the payload's content. Eg: authentic source A brings given_name as giuseppe, while authentic source B brings given_name as peppe:

  • A has precedence than given_name in top_level is set to giuseppe,
  • authentic source A verified_claims.claims.given_name is set to giuseppe,
  • authentic source B verified_claims.claims.given_name is omitted, not included.

[peppelinux]

Over the past few weeks, my team has addressed the following:

• Low stakeholder interest: We've addressed the lack of interest in the initial proposal by incorporating transparency about data origin, a key requirement in Italy.
• OpenID4IDA limitations: We've acknowledged that OpenID4IDA breaks interoperability due to its data structure and inability to include multiple "authentic sources."

To overcome these limitations, we've decided to:

• Remove OpenID4IDA from issued credentials: This will allow us to move authentic source information into the OpenID4VCI metadata.
• Provide citizens with additional information: This includes displaying the data origin during the credential issuance process, within the consent screen.

Below I share a pull request that introduces this "feature" within the OpenID4VCI metadata (and divides AS metadata from OpenID4VCI metadata as well). A subsequent pull request will modify the PID data model.

#217