Give advice on processing SD-JWTs for verifiers

[danielfett]

In this discussion, the question around merging SD claims with non-SD claims came up:
https://mailarchive.ietf.org/arch/msg/oauth/4jtL1vXWsYcyU99Gfe7n8jcONoA/

I think it makes sense to discuss this in the spec, whether it ends up as normative text or not.

[christianpaquin]

FYI, that's what I currently do as a placeholder behavior in my implementation, the disclosed claims are added in a disclosedClaims object in the returned JWT. It might not be right thing to do in all situations, but I think it would be useful to at least define one mechanism to do something like that (perhaps even encoding the claims directly in the JWT root). A verifier('s policy) only expects a JWT with some claims; it might not care if they are encoded directly or selectively disclosed from a hash based encoding (or derived from another claim in more advanced systems). Surfacing the calculated claims in the JWT offers the ability for libraries to perform this transformation, and leaving the RP's business logic close to intact.

[Sakurann]

from the mailing list, how "merging" might look like in the vc-data-model example (also related to Issue #59)

Take an SD-JWT as below:

     "vc": {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://www.w3.org/2018/credentials/examples/v1"
       ],
       "type": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
       ]
     },
     "sd_digests": {
       "vc":{
           "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
           "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
           "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
        }
     }
   }

And merge it into

     "vc": {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://www.w3.org/2018/credentials/examples/v1"
       ],
       "type": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
       ],
         "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
         "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
         "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
     }

[peppelinux]

@Sakurann I'd prefer the adoption of the claim sd_digests

the hashed claims values are not the claims values and I think it's important giving, in a way or another, a clear type for each value, the container sd_digests and sd_releases do a good job for that.

in alternative I wonder if we may adopt a VC scheme defining a new type like

       "type": [
         "VerifiableSelectiveDisclosableCredential",
         "UniversityDegreeCredential"
       ],

and VerifiableSelectiveDisclosableCredential comes with its own schema where the digests would have their place without any other specification

[Muthurajj]

We have to merge the context and type in the claims ?

[Sakurann]

no, there is only one @context and type claims in this SD-JWT-VC/SD-JWT-R

[Muthurajj]

I have mailed you doubts regarding VC can you pls respond ?

[Sakurann]

sorry, don't think we've received them?

[Muthurajj]

1.Can we generate VC using SD-JWT?

2.What is the verification_process and sub that you have mentioned in example yml file

3.If we can generate VC what should we change?

4. How to generate context and type like you have mentioned in document example 4?

5.Openid connect include in this library?

[Muthurajj]

I am new to python pls help me

[Sakurann]

1.Can we generate VC using SD-JWT?
-> yes. we are in the process of defining how

2.What is the verification_process and sub that you have mentioned in example yml file
-> verification_process might be ekyc-ida claim, sub is a registered JWT claim

3.If we can generate VC what should we change?
-> being discussed, please see example 4 for the current approach

4. How to generate context and type like you have mentioned in document example 4?
   -> that is a vc-data-model issue

6.Openid connect include in this library?
-> not sure I understand the question, but no, SD-JWT code has nothing to do with OIDC

Can you please open a new issue with your questions? this issue is not a place to discuss it.

[Muthurajj]

thank you so much

1.Can we generate VC using SD-JWT? -> yes. we are in the process of defining how

2.What is the verification_process and sub that you have mentioned in example yml file -> verification_process might be ekyc-ida claim, sub is a registered JWT claim

3.If we can generate VC what should we change? -> being discussed, please see example 4 for the current approach

4. How to generate context and type like you have mentioned in document example 4?
   -> that is a vc-data-model issue

6.Openid connect include in this library? -> not sure I understand the question, but no, SD-JWT code has nothing to do with OIDC

Can you please open a new issue with your questions? this issue is not a place to discuss it.

[danielfett]

Addressed in PR #146

[danielfett]

The PR has been merged.