Re: DIF VC-JWTs look like Linked Data Proof Verifiable Credentials

I don't think it's failing..? Do you see a problem anywhere?

Markus

On 02.03.22 05:05, Kim Hamilton wrote:
> Btw, is the DanubeTech implementation failing? This may be blocking 
> the ability to submit test reports to that suite
>
> On Tue, Mar 1, 2022 at 1:42 PM Kim Hamilton <kimdhamilton@gmail.com> 
> wrote:
>
>     That's right; I do think did-jwt-vc can be made conformant, but
>     there are some repo/work item ownership issues to sort out.
>     Perhaps we (Centre) can help with that after we figure out who
>     else is interested in actively contributing to that repo going
>     forward.
>
>     On Mon, Feb 28, 2022 at 10:38 AM Charles E. Lehner
>     <charles.lehner@spruceid.com> wrote:
>
>         Hi,
>
>         JwtProof2020 is described as "for internal use" in DIF's
>         did-jwt-vc library:
>         https://github.com/decentralized-identity/did-jwt-vc#notes-on-verification-and-proof-properties
>         > The JwtProof2020 is a synthetic proof type, usable for
>         differentiating credentials by type. It is not a registered
>         W3C VC Data Model algorithm and should not be treated as such.
>
>         I saw a VC with this format in a demo recently, which I think
>         suggests it may be leaking into non-internal use.
>
>         I don't see a specification for it, or an IRI for the proof
>         type. The implementation in DIF's did-jwt-vc repository
>         produces it here:
>         https://github.com/decentralized-identity/did-jwt-vc/blob/94fdd6f280579cc2b0b9a0125855ee13916b6b52/src/converters.ts#L173-L187
>         https://github.com/decentralized-identity/did-jwt-vc/blob/94fdd6f280579cc2b0b9a0125855ee13916b6b52/src/converters.ts#L417-L431
>         There does not seem to be a verifier implemented there, only
>         the conversion from JWT-VC into VC with proof object of this
>         type (with conversion of some properties).
>
>         I think JwtProof2020 looks useful as way to convert a VC-JWT
>         into an equivalent VC-with-proof-object. Maybe this could
>         enable using VC-JWTs in APIs that require a
>         VC-with-proof-object; then APIs would not need polymorphism
>         like was proposed in https://github.com/w3c-ccg/vc-api/pull/208 .
>         Maybe this format could encapsulate the conversion process
>         between JOSE claims and VC fields such as is specified in the
>         VC Data Model: https://www.w3.org/TR/vc-data-model/#jwt-encoding
>         But it would need to be determined how to verify this proof
>         type, including ensuring that the properties outside the JWT
>         correspond to the JWT payload.
>
>         There is some more discussion here:
>         https://github.com/centrehq/verite/issues/373
>
>         Regards,
>         Charles Lehner
>
>         On Thu, 24 Feb 2022 08:08:19 -0600
>         Orie Steele <orie@transmute.industries> wrote:
>
>         > Hey Folks,
>         >
>         > As we gear up for VCDM2.0 there are a number of VC-JWT
>         > implementations that we are tracking and attempting to show
>         > interoperability across.
>         >
>         > One of the oldest VC-JWT implementations is hosted at DIF,
>         but it
>         > produces VC-JWTs that are not compact JWTs ... they look
>         more like
>         > Linked Data Proof VCs.
>         >
>         > As far as I know, no other VC-JWT implementation supports this
>         > format, aka "JwtProof2020".
>         >
>         > Here is a link to an issue with an example:
>         >
>         https://github.com/centrehq/verite/issues/373#issuecomment-1049888568
>         >
>         > If you have a few minutes, I would love some review of what
>         the DIF
>         > implementation is doing, and how we can either push it all
>         the way
>         > into the LD Proof camp, or all the way into the VC-JWT camp.
>         >
>         > Regards,
>         >
>         > OS
>         >
>