Re: Verifiable Credentials with PGP

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.

* An external proof value that is detached from the proof itself makes
proof chains hard to process. What proof value should be externalized when
a VC is signed by multiple issuers? And to which proof the value belongs
to? To the one without proofValue property?

* A signature based on a syntax makes a VC fragile as it dictates how a VC
must be serialized. Restricts possible representations of a VC and limits
extensibility, In my experience this approach will lead to proprietary and
even copyrighted solutions.

* JSON-LD processing is not an issue as "well-know" contexts can be
pre-processed in advance and cached. We can also generate specialized code
to process "well-know" contexts. There is many solutions how to deal with
JSON-LD processing performance if it's even a real issue.

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.

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>
>