Adapt PID rulebook to latest SD-JWT VC

[danielfett]

The current description of the usage of SD-JWT in the PID rulebook is not sufficient to result in PID attestations that are compatible to existing conventions and standards like JWTs and SD-JWT VC in particular. The changes proposed here adapt the PID rulebook to be compatible with SD-JWT VC and to work in the direction proposed in SD-JWT VC DM.

The goal is also to make the best usage of SD-JWT VC Type Metadata, even though not all parts of that have made it into SD-JWT VC yet. This allows for automated discovery and processing of type metadata, like schemas (e.g., for relying parties) and rendering information

[peppelinux]

only editorials by my side, some further readings makes me more sensible from the reader perspective. I consider this approved even If I'm requesting these trivial editorials

[c2bo]

I don't think I have any power to approve here but looks good to me

[awoie]

Looks great to me.

[awoie]

IMO, this looks good and fills an important gap in the specification. I really appreciate this addition.

[ssanchocanela]

Here I suggest to add this a note: PID rulebook has been adapted to be compatible with SD-JWT VC and to work in the direction proposed in SD-JWT VC DM.

[babisRoutis]

birth_place and birth_city are both mapped to place_of_birth/locality

Is this correct?

[skounis]

Have we truly identified a use case that necessitates the birth_city field when we already have birth_place?

Are there legal documents that simultaneously capture both the city and another place, and if so, is the place in this case more or less generic than the city (part of the city or region the city belongs to)?

If not, it appears that the birth_city field is redundant since birth_place could adequately contain its value.

Removing the birth_city field aligns this table with IANA's place_of_birth definition (locality).

• IANA JWT Claims
• OpenID Connect Identity Assurance Claims

[c2bo]

That would require changes to 5.1.1.2 first which seems to be outside of the scope of this PR (but I do believe would be a good idea)

[danielfett]

I agree and would support a separate PR for that.

[joelposti]

The proposed claim set does not seem to include a claim that would specify the namespace/credential type eu.europa.ec.eudi.pid.1 in an issuer-agnostic way. Lack of such a claim makes it difficult for an RP to make a request where they say that they want a presentation of certain claims from a PID of any member state.

Consider the following presentation definition with which an RP requests given_name from a PID of any member state. The following request will not work without a credential_type or similar claim.

{
  "id": "foobar",
  "vp_formats": {
    "vc+sd-jwt": {
      "sd-jwt_alg_values": [
        "ES256"
      ],
      "kb-jwt_alg_values": [
        "ES256"
      ]
    }
  },
  "input_descriptors": [
    {
      "id": "given_name",
      "constraints": {
        "fields": [
          {
            "path": [
              "$.credential_type"
            ],
            "filter": {
              "const": "eu.europa.ec.eudi.pid.1"
            }
          },
          {
            "path": [
              "$.given_name"
            ],
            "filter": {
              "type": "string"
            }
          }
        ]
      }
    }
  ]
}

Also, the claim set does not include issuing_country which prevents an RP from requesting a PID from a specific member state. Vct might not work for this purpose because a PID Provider might need to add a version number to the vct value. Consider the following scenario:

1. A PID Provider issues PIDs with vct value https://memberstate.example/credential/pid and vct#integrity claim having the SHA-384 digest of the metadata document.
2. The metadata document contais a typo in one claims[].display['de-DE'].label field. The PID Provider cannot fix this typo by modifying the metadata document because then the SHA-384 digest of the metadata document would change breaking the metadata integrity for all PIDs the Provider has so far issued.
3. To fix the typo the PID Provider needs to create a new metadata document and needs to start issuing PIDs with a new different vct value https://memberstate.example/credential/pid/1.1 and a new vct#integrity value.
4. The new PIDs issued in step 3 are not accepted by RPs because in their presentation definitions they select PIDs having vct value https://memberstate.example/credential/pid specifically.

If the RPs instead selected using credential_type and issuing_country, which do not change between metadata document versions, the old and new PIDs would both be accepted by RPs in step 4. Below is a presentation definition with which an RP requests given_name from a PID of a specific member state. The request will not work without credential_type and issuing_country claims.

{
  "id": "foobar",
  "vp_formats": {
    "vc+sd-jwt": {
      "sd-jwt_alg_values": [
        "ES256"
      ],
      "kb-jwt_alg_values": [
        "ES256"
      ]
    }
  },
  "input_descriptors": [
    {
      "id": "given_name",
      "constraints": {
        "fields": [
          {
            "path": [
              "$.credential_type"
            ],
            "filter": {
              "const": "eu.europa.ec.eudi.pid.1"
            }
          },
          {
            "path": [
              "$.issuing_country"
            ],
            "filter": {
              "const": "DE"
            }
          },
          {
            "path": [
              "$.given_name"
            ],
            "filter": {
              "type": "string"
            }
          }
        ]
      }
    }
  ]
}