sd-jwt vc profile for oid4vc

[tlodderstedt]

No description provided.

[TakahikoKawasaki]

"claims" or "credentialSubject"

Either of the following changes should be made for consistency.

1. Change the claims parameter in Credential Issuer Metadata to credentialSubject.
2. Change the credentialSubject parameter in Authorization Details and Credential Request to claims.

Additional Claims Specified by Credential Request

• credentialSubject: OPTIONAL. A JSON object as defined in (#authorization_vc_sd-jwt). This object determines the optional claims to be added to the credential to be issued.

If this were a functionality to allow wallets to request more claims than the set of claims implied by the type, it would mean that wallets can obtain more claims than ones authorized by the user. It should not happen.

Because a credential offer contains neither claims nor credentialSubject (which implies that a fixed set of claims is determined based on type), the purpose of the credentialSubject in a credential request should be only to narrow down the set of claims.

So, either of the following changes should be made.

1. Rephrase the description about the credentialSubject in Credential Request.
2. Remove the credentialSubject parameter from Credential Request.

Description of Credential Response

The value of the credential claim in the Credential Response MUST be a SD-JWT VC. Credentials of this format are already a sequence of base64url-encoded values separated by period characters and MUST NOT be re-encoded.

To be exact, the SD-JWT format contains ~ in addition to base64url characters and periods. Trying to repeat to describe technical details that are written in other specifications could cause this kind of mistakes. The description here does not have to mention details about the SD-JWT format. It would be enough to say, for example, like below.

Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

Finally, a typo: "a SD-JWT VC" -> "an SD-JWT VC"

[peppelinux]

There are some considerations made by service designers and accessibility domain experts that I would like to share to you.

these are not relevant for the scopes of this PR, so this proposal should be converted in a issue if you agree.

There are cases where a credential issuer would offer periodic updates about its issued credentials, cases where the issuer should communicate the recent news related to the use of the credential to the end user and owner of that credential

this could be implemented as web uri, the wallet instance periodically gets updates by hitting this refs.
The content type could be application/json if html could not be handly

[tlodderstedt]

"claims" or "credentialSubject"

Either of the following changes should be made for consistency.

1. Change the claims parameter in Credential Issuer Metadata to credentialSubject.
2. Change the credentialSubject parameter in Authorization Details and Credential Request to claims.

changed it to claims - credentialSubject is not used by SD-JWT VCs.

Additional Claims Specified by Credential Request

• credentialSubject: OPTIONAL. A JSON object as defined in (#authorization_vc_sd-jwt). This object determines the optional claims to be added to the credential to be issued.

If this were a functionality to allow wallets to request more claims than the set of claims implied by the type, it would mean that wallets can obtain more claims than ones authorized by the user. It should not happen.

The set of claims MUST be a sub set of the authorized claims.

Because a credential offer contains neither claims nor credentialSubject (which implies that a fixed set of claims is determined based on type), the purpose of the credentialSubject in a credential request should be only to narrow down the set of claims.

I agree. The question is whether it would make sense to add claims to the credential offer so the issuer could tell the wallet what optional claims are available. WDYT?

So, either of the following changes should be made.

1. Rephrase the description about the credentialSubject in Credential Request.
2. Remove the credentialSubject parameter from Credential Request.

Description of Credential Response

The value of the credential claim in the Credential Response MUST be a SD-JWT VC. Credentials of this format are already a sequence of base64url-encoded values separated by period characters and MUST NOT be re-encoded.

To be exact, the SD-JWT format contains ~ in addition to base64url characters and periods. Trying to repeat to describe technical details that are written in other specifications could cause this kind of mistakes. The description here does not have to mention details about the SD-JWT format. It would be enough to say, for example, like below.

Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

I incorporated the text you proposed.

Finally, a typo: "a SD-JWT VC" -> "an SD-JWT VC"

fixed

[tlodderstedt]

There are some considerations made by service designers and accessibility domain experts that I would like to share to you.

these are not relevant for the scopes of this PR, so this proposal should be converted in a issue if you agree.

There are cases where a credential issuer would offer periodic updates about its issued credentials, cases where the issuer should communicate the recent news related to the use of the credential to the end user and owner of that credential

this could be implemented as web uri, the wallet instance periodically gets updates by hitting this refs. The content type could be application/json if html could not be handly

as you already noted, this topic is out of scope of this PR. please file an issue on that topic

[Sakurann]

I think a parameter in issuer metadata is missing..?

[Sakurann]

Also why is this approach better than adding new parameters in each of the sub sections in section 4 that already defines extensions for OpenID4VCI? With the current structure, the implementer needs to look into two places to see parameters for the Credential Offer for example. If the entire profile is about SD-JWT VC, it should be in one place, no..?

[tlodderstedt]

Need to add identifier for presentation request.

[Sakurann]

thank you!

[selfissued]

LGTM