- edited description
credentialSubject consistency and meaning
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
:
- This property does not appear on the equivalent sections for
jwt_vc_json-ld
andldp_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. - How should an issuer process the
credentialSubject
in RAR and in the credential request? The spec statesdetermines 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.
Comments (6)
-
reporter -
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 thatcredential_definition
object that includescredentialSubject
. 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
-
please review PR #528
-
reporter 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
andtypes
, but notcredentialSubject
. 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 ofcredentialSubject
) also applies to the other usages ofcredentialSubject
(authorization_details
and credential request)?
- 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
-
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 ofcredentialSubject
) also applies to the other usages ofcredentialSubject
(authorization_details
and credential request)?Yes, assumption is that the structure in the Credential Issuer metadata applies universally - probably good to say so explicitly..
-
- changed status to resolved
PR merged
- Log in to comment