credentialSubject consistency and meaning

[Pedro Felix]

Regarding the credentialSubject property that appears inside authorization_details (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.1.4) and on a credential request (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.1.5) for format jwt_vc_json:

1. This property does not appear on the equivalent sections for jwt_vc_json-ld and ldp_vc (https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.1.5 and https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-e.1.1.5, however it does appear in the non-normative examples. Is this absence on purpose? If so, what is the rationale for this distinction between formats? Also, if so, the non-normative examples should probably be updated to remove its usage.
2. How should an issuer process the credentialSubject in RAR and in the credential request? The spec states determines the optional claims to be added to the credential to be issued . Are these extra claims that can be optionally added to the VC, in addition to the ones inferred from the requested types? Also, how should the value (empty object in the non-normative examples) be interpreted by the issuer?

IMO, the spec should provide more information on the semantics of credentialSubject, when present on a request. As an implementer, it is not clear to me how to handle it.

[Kristina Yasuda]

on 1. I think we are both looking at ver-11, which was published Feb 3rd and your issue is March 10th. for all three VC formats, the text does define credentialSubject by defining that credential_definition object that includes credentialSubject. so no distinction between credential formats. I also believe the latest editors draft -13 (openid.bitbucket.io URL below) is more clear in this regard.

on 2. what is meant by determines the optional claims to be added to the credential to be issued is that a nested structure like the one here might be issued. empty {} mut be interpreted as there is no deeper level of nesting for that claim.

hope this is clearer

since VCI is not in the Implementer’s draft state yet, would highly recommend looking at https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-vc-secured-using-data-integ

‌

[Kristina Yasuda]

please review PR #528

[Pedro Felix]

On 1.

• I’m probably missing something, however both https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#name-authorization-details-3 and https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.3.5 point to section https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#issuer_initiated_issuance_ldp_vc, which defines credential_definition as containing @context and types, but not credentialSubject. However PR #528 seems to fix that, thanks!

On 2.

• Am I correct in assuming that the issue may ignore all the claims requested via credentialSubject since they are optional? If so, should this be explicitly stated in the document?
• Should there be a schema for credentialSubject or can we assume that the schema defined on https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.1.2 (metadata usage of credentialSubject) also applies to the other usages of credentialSubject (authorization_details and credential request)?

‌

[Kristina Yasuda]

Am I correct in assuming that the issue may ignore all the claims requested via credentialSubject since they are optional? If so, should this be explicitly stated in the document?

I would say that, yes, in the end of the day it is the Issuer’s decision what to issue in the credential based on the request from the Wallet. I am not sure if OIDC says anything in that regard regarding the claims OP puts in the ID token - I quickly checked but could not find anything.

Should there be a schema for credentialSubject or can we assume that the schema defined on https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#section-e.1.1.2 (metadata usage of credentialSubject) also applies to the other usages of credentialSubject (authorization_details and credential request)?

Yes, assumption is that the structure in the Credential Issuer metadata applies universally - probably good to say so explicitly..

[Kristina Yasuda]

PR merged