search

Sphereon-Opensource / SIOP-OID4VP

Self Issued OpenID Provider v2 (SIOP) with optional OpenID for Verifiable Presentations (OpenID4VP)
76 stars 25 forks source link

PEX and jwt-vc general question #45

Open jfromaniello opened 2 years ago

jfromaniello commented 2 years ago

It seems that the current behavior for the PEX implementation is to wrap jwt-vcs and execute the filter on the wrapped version.

It is not clear to me from the spec if this should be the case.

For instance, this example seems to target the jwt-decoded version of a jwt-vc:

Screen Shot 2022-11-04 at 10 17 14

Anyways, I am just looking for your thoughts on this.

Thank you very much

nklomp commented 2 years ago

Good one.

Just to give you some insight/background first. Current PEX implementation supports V1 and partial V2 of the spec. But v2 support is not complete, as the spec was only ratified yesterday. So we have waited for this to happen, before we would finish V2 support. Otherwise we would be continuously updating our implementation. Work on completing V2 will go hand in hand with some refactoring that we wanted to do anyway.

We do indeed create an internal representation of JWT VCs. In case of a JWT VC we should however ensure for the JSON path matching that we are aware of the required vc field. I am currently not sure whether we are indeed doing that. @sksadjad @ksadjad could you comment on that?

The above example would for sure work, because it lists paths for both LDP and JWT, but if it would only contain the path for JWTs our PEX lib for sure should match it for a JWT VC and not for an LDP VC.

nklomp commented 2 years ago

And to add, since you posted this in our SIOP repo. We are currently working on an updated SIOPv2 version that is more in line with latest SIOPv2 specs, but also aligns with the JWT VC Interop Profile for instance. Work on that can be found in the https://github.com/Sphereon-Opensource/did-auth-siop/tree/release/v2.0.0 branch.

nklomp commented 2 years ago

Actually something I will bring up in the DIF WG:

It is debatable whether the .vc examples for JWTs should be in there to begin with. If you look at the W3C VC Datamodel basically the vc in a JWT is the credential, whilst the JWT itself makes it a VC (so adds the proofs). Then it has clear rules on encoding/decoding. That is what we are doing. So basically our internal representation is similar to a LDP/JSONLD VC, with certain JWT claims like nbf, exp mapped onto the respective properties in the Credential (issuanceDate/expirationDate).

So if everyone follows these encoding/decoding rules to the letter, then JSON path matching should not include the .vc path.

jfromaniello commented 2 years ago

Perfect! yes I am aware of the v2 branch and that's what I am using for my tests.