Add optional `credentialSubject` property to `CredentialRequestMessage`

[arnoweiss]

What's missing?

Clients (potential Holders) may want to have very specific claims signed. The schema is implicitly known via the credentialType. The updated message could look like this:

{
  "@context": [
    "https://w3id.org/dspace-dcp/v1.0/dcp.jsonld"
  ],
  "type": "CredentialRequestMessage",
  "holderPid": "holderPid",
  "credentials": [
    {
      "credentialType": "MembershipCredential",
      "format": "vcdm11_jwt",
      "credentialSubject": 
        {
          "id": "did:web:holder.com",
          "joinedDataspace": "2025-04-01",
          "specificId": "dataspace-identifier-1234"
        }
    },
    {
      "credentialType": "Iso9001Credential",
      "format": "vcdm20_jose"
    }
  ]
}

Why should it be in the spec?

If a client is interested in only being issued a specific value for a claim, he has currently no means of conveying that information.

Where should this be added?

schemas, spec text

More context

No response

[mkollenstart]

I think we have to be careful with the meaning of such a property, as it might introduce confusion.

Since the issuer is responsible for the claims that it issues to the holder, it must have a clear picture of the holder and which claims it is able to make of the holder. If the holder is providing the credential subject the issuer still needs to make sure that all claims the holder is asking for are indeed claims it can issue. A case where the holder wants a credential with a subset of the claims the issuer is able to issue can be made, but the question is whether a credentialSubject property is the most suitable.

Possible examples that might lead to confusion with respect to this property:

• A holder does not know in advance wheter a holder-provided credentialSubject is required, optional or prohibited. So it might need to send multiple requests, depending on how the issuer handles the presence of the property.
• What responses can the issuer give in the case of errors, both in the structure of the credential subject (probably a bad request) or in the content of the credential subject.
• Is the issuer allowed to completely ignore the credentialSubject property and issue a credential that does not exactly match the property (e.g. adding fields, modifying fields, deleting fields)

Some of these aspects might be mitigated by extending the metadata of the issuer, so that it can indicate for each of the credentials it issues whether it expects the property. But this might not cover everyting.