credential_identifiers

[TakahikoKawasaki]

The OID4VCI draft states authorization_details[*] in a token response may contain a credential_identifiers array. The following is an example from the spec.

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
  "token_type": "bearer",
  "expires_in": 86400,
  "c_nonce": "tZignsnFbp",
  "c_nonce_expires_in": 86400,
  "authorization_details": [
    {
      "type": "openid_credential",
      "credential_configuration_id": "UniversityDegreeCredential",
      "credential_identifiers": [ "CivilEngineeringDegree-2023", "ElectricalEngineeringDegree-2023" ]
    }
  ]
}

According to the explanation, the identifiers in the credential_identifiers array do NOT represent requested credentials but do represent just credential variants with a pre-configured set of claims.

Therefore, when a RAR object like below comes, which is an example listed in "E.2.3. Authorization Details", the mechanism of credential_identifiers does not contribute to simlifying a credential request.

[
    {
        "type":"openid_credential",
        "credential_configuration_id": "org.iso.18013.5.1.mDL",
        "claims": {
            "org.iso.18013.5.1": {
                "given_name": {},
                "family_name": {},
                "birth_date": {}
            },
            "org.iso.18013.5.1.aamva": {
                "organ_donor": {}
            }
        }
    }
]

To simplify the corresponding credential request, a token response should contain an identifier that represents the exact set of the requested claims. The following is a conceptual token response to achieve the goal - the credential_identifier property is added in the RAR object.

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
  "token_type": "bearer",
  "expires_in": 86400,
  "c_nonce": "tZignsnFbp",
  "c_nonce_expires_in": 86400,
  "authorization_details": [
    {
      "type":"openid_credential",
      "credential_configuration_id": "org.iso.18013.5.1.mDL",
      "claims": {
        "org.iso.18013.5.1": {
          "given_name": {},
          "family_name": {},
          "birth_date": {}
        },
        "org.iso.18013.5.1.aamva": {
          "organ_donor": {}
        }
      },
      "credential_identifier": "bd091534ed016c9c681c68e6f793a50527c3213c4121d8e0f22b97adcf90e17b"
    }
  ]
}

BTW, the current draft imposes the following restriction.

Note: Credential Instance identifier(s) cannot be used when scope parameter is used in the Authorization Request to request issuance of a Credential.

Technically speaking, the credential_identifers mechanism cannot coexist with the issuer_state parameter, either.

However, the reason why this restriction is needed is that credential_identifiers is placed INSIDE the authorization_details object. Placing the information OUTSIDE, like the following conceptual example, would enable the credential_identifiers mechanism to coexist with scope and issuer_state.

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
  "token_type": "bearer",
  "expires_in": 86400,
  "c_nonce": "tZignsnFbp",
  "c_nonce_expires_in": 86400,
  "credential_identifiers": {
    "bd091534ed016c9c681c68e6f793a50527c3213c4121d8e0f22b97adcf90e17b": {
      "type":"openid_credential",
      "credential_configuration_id": "org.iso.18013.5.1.mDL",
      "claims": {
        "org.iso.18013.5.1": {
          "given_name": {},
          "family_name": {},
          "birth_date": {}
        },
        "org.iso.18013.5.1.aamva": {
          "organ_donor": {}
        }
      }
    }
  }
}

A token response is not a suitable place to put information about credential variants with a pre-configured claim set, like CivilEngineeringDegree-2023 and ElectricalEngineeringDegree-2023. Such static information should be placed in the credential issuer metadata. The following is a conceptual example.

"credential_configurations": {
  "base_configuration_1": {
    "...": "...",
    "claims": {
      "family_name": {},
      "given_name": {},
      "birthdate": {}
    }
  }
},
"credential_configuration_variants": {
  "birthdate_only": {
    "base_configuration": "base_configuration_1",
    "claims": {
      "birthdate": {}
    }
  }
}

The summary is as follows.

1. Remove credential_identifiers from authorization_details[*] in a token response.
2. Add credential_identifiers (or something equivalent) as a top-level property in a token response.
3. Change the meaning of the string elements in credential_identifiers from "identifiers of pre-configured claim sets" to "identifiers of requested claim sets".
4. Secure a place to publish information about pre-configured claim sets in the credential issuer metadata.

[babisRoutis]

@TakahikoKawasaki I think that point (3) is not correct.

To my understanding, credential_identifiers can be used to

• either represent a specific (and pre-configured) subset of claims, or
• specify a different claim (of the same credential type/configuration)

An example of the later case is to, assuming a credential "Birth Certificate", be able to request (using credential_identifiers) which is the subject of the credential (my son's, mine etc). My point is that credential_identifiers is not always a configurable value and in some cases needs to be evaluated dynamically.

[Sakurann]

BTW, the current draft imposes the following restriction.

Note: Credential Instance identifier(s) cannot be used when scope parameter is used in the Authorization Request to request issuance of a Credential.

Technically speaking, the credential_identifers mechanism cannot coexist with the issuer_state parameter, either.

However, the reason why this restriction is needed is that credential_identifiers is placed INSIDE the authorization_details object. Placing the information OUTSIDE, like the following conceptual example, would enable the credential_identifiers mechanism to coexist with scope and issuer_state.

yes, that's why I also filed #132. I support a top-level identifier parameter.

[tlodderstedt]

I do not support the top level credential identifier for credentials requested with authorization details. Reason: every credential identifier represents a concrete credential dataset authorized by the respective authorization detail. This link would not exist any longer if the identifier is moved out of the authorization detail.

[Sakurann]

let me clarify my comment. I see the need for a top-level identifier parameter that can be used with scopes (and not RAR) but I think that is better achieved by enabling credential_configuration_id to be used in the credential request, as opposed to making top-level existing credential_identifiers parameter that is meant to be used with RAR (and not scopes).

I think there might be several misunderstandings in the original issue.

According to the explanation, the identifiers in the credential_identifiers array do NOT represent requested credentials but do represent just credential variants with a pre-configured set of claims. ... To simplify the corresponding credential request, a token response should contain an identifier that represents the exact set of the requested claims.

This is not prohibited. Issuer can return one entry in authorizaiton_details.credential_identifier array that represents exactly what was requested and can be used to simplify the credential request. This should probably be clarified in the definition of authorizaiton_details.credential_identifier in the Token Request.

A token response is not a suitable place to put information about credential variants with a pre-configured claim set, like CivilEngineeringDegree-2023 and ElectricalEngineeringDegree-2023. Such static information should be placed in the credential issuer metadata. The following is a conceptual example.

This mechanism was introduced to issue not pre-configured/not static claim sets, that are represented by the same credential_configuration_id in the issuer metadata.

However, the reason why this restriction is needed is that credential_identifiers is placed INSIDE the authorization_details object. Placing the information OUTSIDE, like the following conceptual example, would enable the credential_identifiers mechanism to coexist with scope and issuer_state.

If one of the motivations for this proposal is to enable the credential_identifiers mechanism to coexist with scope and issuer_state., would really appreciate feedbak on the proposal in the first paragraph of this comment and this issue #132. cc @TakahikoKawasaki

[Sakurann]

should be resolved by the PRs addressing #294 (including #346)