Re: Verifiable Credentials with PGP

Sorry for the delay.

There are several Data Integrity Proof formats that require a JSON-LD
processor prior to issuance and verification,
because the canonized representation of the document is what is protected,
not a specific serialization.

Here are 2 data integrity suites that are similar to the ones proposed
above, but do require JSON-LD processing:

- https://github.com/w3c/vc-jws-2020
- https://or13.github.io/lds-pgp2021/

Inline for the rest:

On Fri, Dec 9, 2022 at 11:34 AM Filip Kolařík <filip26@gmail.com> wrote:

> Thank you Orie for sharing the proposals.
>
> As an engineer who develops and maintains a JSON-LD processor
> <https://github.com/filip26/titanium-json-ld>, and VC issuer/verifier, I
> share mote notes:
>
> * An external proof[value] means that a JSON representing a VC is wrapped
> inside another representation, usually totally different. This requires
> additional pre/post processing and increases an implementation
> complexity/maintainability.
>

https://www.w3.org/TR/vc-data-model/#proofs-signatures

I think you are saying that using off the shelf tooling for JWS / COSE Sign
/ PGP Signatures is extra complexity?

Maybe, but its not complexity this W3C Working Group would be required to
specify or define in our charter deliverables.

This is different from needing to define a mapping for VC-JWT or defining
the "Create Verify Data Algorithm" or Data Integrity Proofs.


>
> * An external proof value that is detached from the proof itself makes
> proof chains hard to process.
>

Typically this is solved by nesting... it's trivial, but if you are using
JOSE, it's also hugely wasteful of space and compute, due to encoding and
decoding base64url.


> What proof value should be externalized when a VC is signed by multiple
> issuers?
>

Support for multiple issuer's is not currently supported by the VCDM.


> And to which proof the value belongs to? To the one without proofValue
> property?
>
>
See answer above.


> * A signature based on a syntax makes a VC fragile as it dictates how a VC
> must be serialized.
>

Yes, this is considered a security feature of signing concrete
serializations, and its inverse is often cited as the source of a lot of
developer pain...

Having worked with both approaches, I prefer the simpler ones, where you
protect a concrete serialization.

I also appreciate diversity and innovation, and I think it's good for us to
cultivate a garden without walls, and that isn't limited to only flowers
liked by particular technology giants.


> Restricts possible representations of a VC and limits extensibility,
>

This is true, YAML, JSON and CBOR all have different features, if you want
to protect a serialization that makes use of integer keys for example, you
might not want to use JSON.


> In my experience this approach will lead to proprietary and even
> copyrighted solutions.
>
>
I expect copyright applies consistently to all serializations, but perhaps
there are formats that tend to be more aggressively targeted.


> * JSON-LD processing is not an issue as "well-know" contexts can be
> pre-processed in advance and cached.
>

Yes, but... No matter how many times we tell people this, they still don't
all hear us.

It's the "alg: none" of JSON-LD.


> We can also generate specialized code to process "well-know" contexts.
>

Yes, but getting everyone to implement code consistently is outside of the
responsibility of the VGWG.


> There is many solutions how to deal with JSON-LD processing performance if
> it's even a real issue.
>
>
It's a real issue, there is a simple reproduction:

const sleep = async (seconds) =>{
  console.time('URDNA2015 canonize with @vocab')
  const collection = {
    "@context": {'@vocab' : 'https://outer.example#'},
    "items": new Array(seconds-2).fill({ name: 'itemsL1', items: new
Array(seconds-2).fill({ name: 'itemsL2' }) })
  };
  await require('jsonld').canonize(collection, {
    algorithm: 'URDNA2015',
    format: 'application/n-quads',
  });
  console.timeEnd('URDNA2015 canonize with @vocab')
}

(async ()=>{
  await sleep(10)
})()


❯ node ./sleep.js
URDNA2015 canonize with @vocab: 10.543s

On an Apple M1 Max, 64 GB Memory.

Expecting this to take even longer with additional context complexity.

I was trying to figure out how to extend open-source library Iron VC
> <https://github.com/filip26/iron-verifiable-credentials> of an external
> proof support but given to the issues above I'm giving up for now as I
> don't see the added value.
>
>
In general, many signature schemes support attached and
detached signatures,
Data Integrity Proofs rely on detached signatures...
JWT / CWT and the simple PGP demo I showed use attached.

Given that JWT already does not require canonization, and supports
protecting JSON, the current work item (VC-JWT) is strictly speaking less
efficient than using a vanilla JWT implementation.

... The current VC-JWT mapping is also less efficient than the vc-jws and
vc-cose proposal.

What are the benefits that VC-JWT provides over using a vanilla JWT?

If we don't have good answers for this, we should not be creating a new
flavor of JWT.

The same applies to the other formats, such as data integrity proofs.

Best regards,
> Filip
>
>
>
>
>
> On Fri, Dec 9, 2022 at 2:27 PM Orie Steele <orie@transmute.industries>
> wrote:
>
>> Friends,
>>
>> Building on the 2 previous proposals I have sent to the list,
>> I'm back once again to introduce yet another way to secure the W3C
>> Verifiable Credentials Data Model.
>>
>> This time with PGP:
>>
>> https://transmute-industries.github.io/vc-pgp
>>
>> Similar to previous 2 proposals:
>>
>> - https://transmute-industries.github.io/vc-jws
>> - https://transmute-industries.github.io/vc-cose
>>
>> All 3 of these approaches treat a credential as a content type:
>> application/credential+json
>>
>> And then secure that content by applying an external proof.
>>
>> Notice that all three approaches define a way to resolve the public key
>> that verifies this external proof,
>> and all three approaches avoid tampering with or transforming the
>> credential JSON itself as part of the issuance and verification process.
>>
>> All three approaches do not perform any JSON-LD processing as part of
>> issuance and verification.
>>
>> All three approaches could be used to secure other content types such as
>> `application/credential+cbor`
>>
>> If the working group defined that content type.
>>
>> Simplicity is a feature.
>>
>> The 2 existing proof formats that are defined to secure Verifiable
>> Credentials (Data Integrity Proofs and VC-JWT)
>> both perform preprocessing and postprocessing on the data model that is
>> computationally inefficient and can lead
>> to issuer's and verifiers storing different representation of the
>> `credential` that had been made verifiable.
>>
>> These 3 alternatives do not have that issue, and can lead to safer APIs,
>> by keeping the securing proofs and data model separated cleanly.
>>
>> Regards,
>>
>> OS
>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>