Add SD-JWT VC Profile

[javereec]

PR to resolve #74

[awoie]

Direction generally looks good but imo, the matcher algorithm is missing. You cannot apply JSONPath using PE to the SD-JWT (i.e., issuer-signed JWT plus disclosures). But the wallet can apply the matcher using the JSONPath to the "Unsecured Payload of an SD-JWT VC" (see https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-03.html#section-1.4). After this was added, I'm fine approving it.

You actually can apply a JSONPath to the SD-JWT VC but it would not give you the expected result since it contains all the _sd claims and not the actual disclosures in one JSON object.

[Sakurann]

please also review this PR in HAIP that removes sd-jwt vc profile from HAIP openid/oid4vc-haip-sd-jwt-vc#96

[Sakurann]

But the wallet can apply the matcher using the JSONPath to the "Unsecured Payload of an SD-JWT VC"

it might be beneficial to adopt for sd-jwt vc a similar processing requirements as in 18013-7 for mdocs: ""path is a JSON array where each entry is a JSON String containing a requested data element from the requested document type as follows: $['']['']. For example, to request a data element with an data element identifier family_name from the namespace org.iso.18013.5.1, the following JSON String is used: $['org.iso.18013.5.1']['family_name']." cc @bc-pi @danielfett

[awoie]

But the wallet can apply the matcher using the JSONPath to the "Unsecured Payload of an SD-JWT VC"

it might be beneficial to adopt for sd-jwt vc a similar processing requirements as in 18013-7 for mdocs: ""path is a JSON array where each entry is a JSON String containing a requested data element from the requested document type as follows: [″][″].Forexample,torequestadataelementwithandataelementidentifierfamilynamefromthenamespaceorg.iso.18013.5.1,thefollowingJSONStringisused:['org.iso.18013.5.1']['family_name']." cc @bc-pi @danielfett

That would work too. Or just say that the root of the JSONPath is the Unsecured SD-JWT VC Payload. I'm ok with both options as long it is defined.

[javereec]

@awoie @Sakurann I like the clarity that the unsecured payload brings in terms of finding the disclosures to be added during presentation. I have made some changes, let me know what you think.

[danielfett]

But the wallet can apply the matcher using the JSONPath to the "Unsecured Payload of an SD-JWT VC"

it might be beneficial to adopt for sd-jwt vc a similar processing requirements as in 18013-7 for mdocs: ""path is a JSON array where each entry is a JSON String containing a requested data element from the requested document type as follows: $[''][''].
For example, to request a data element with an data element identifier family_name from the namespace org.iso.18013.5.1, the following JSON String is used: $['org.iso.18013.5.1']['family_name']." cc @bc-pi @danielfett

That definition is quite confusing and took me a while to process (part of which is caused by the use of "JSON" here).
If I understood correctly, the expectation is that the JSONPath matching happens on a structure like the following:

{
"org.iso.18013.5.1": {"family_name": "Doe", "given_name": "John"},
"domestic_namespace": {"foo": "bar"}
}

Is that right?

How would that fit SD-JWT VC?

[bc-pi]

There are a few places in the Introduction, Terminology, and Overview sections that have text along the lines of this:

Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [VC_DATA], ISO mdoc [ISO.18013-5], and AnonCreds [Hyperledger.Indy].

which should probably be updated to also mention SD-JWT VC with this PR that adds a profile for it.

[Sakurann]

@bc-pi can that be a separate PR..?

[jogu]

There are a few places in the Introduction, Terminology, and Overview sections that have text along the lines of this:

Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [VC_DATA], ISO mdoc [ISO.18013-5], and AnonCreds [Hyperledger.Indy].

which should probably be updated to also mention SD-JWT VC with this PR that adds a profile for it.

As per Kristina's comment opened an issue here to track this: #143

[paulbastian]

Approved when my remaining two suggestions are considered

[tplooker]

Approved on the basis we resolve the duplication of supported algorithms as described in #136 separately.

[awoie]

Thanks