Re: [WORK ITEM PROPOSAL] Additional schemes for BBS+ sigs for non-LD data and processors

Great feedback, thanks Orie. Please ignore my scribbles on vc model schemas, I was merely playing with VS Code intellisense, they are not indicative of any standardization or usage intent 🙂

It's clear form your comments there's an opportunity to enhance JOSE with support for multimessage signing. I'm not an expert on JOSE, so again, take my examples in the document as experimental, but I am hoping to get more of this type of feedback that will steer the direction of the effort under this work item.
It's interesting you pointed to the JCS suite, as we're using it too<https://github.com/trinsic-id/okapi/blob/a7e78bc47f0127c9d3906141d83000cadd058cd0/native/src/ldproofs/mod.rs#L33> when preparing signatures on the edge for authorization with ZCAPs. The reason we opted for this specific suite is the simple way to produce the signature, as there's no stable tooling for Rust to support creation of LD processing suites. This is another aspect that I'm hoping to have more conversation on how it can be introduced in the ecosystem: the ability to use BBS ZKP with simpler algorithms to help broaden the adoption of BBS and VCs in general for use with edge devices, IoT, etc.
________________________________
From: Orie Steele <orie@transmute.industries>
Sent: Friday, August 20, 2021 22:31
To: Tomislav Markovski <tomislav@trinsic.id>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: [WORK ITEM PROPOSAL] Additional schemes for BBS+ sigs for non-LD data and processors

This is cool, I am excited to see more multi message signatures suites.

There have been previous "Linked Data Suites" that don't use URDNA2015, for example:  https://w3c-ccg.github.io/ld-cryptosuite-registry/#jcs-ed25519-signature-2020


There are a couple things the spec says that I don't fully agree with, and the "W3C VC Data Model" examples in particular are a bit worrisome...

I see the use of `$schema` instead of the defined terms for that, such as: https://w3c.github.io/vc-data-model/#data-schemas


And I hate to be that guy, yet again... but:

https://w3c.github.io/vc-data-model/#contexts


> Verifiable credentials<https://w3c.github.io/vc-data-model/#dfn-verifiable-credentials> and verifiable presentations<https://w3c.github.io/vc-data-model/#dfn-verifiable-presentations> MUST include a @context property<https://w3c.github.io/vc-data-model/#dfn-property>.

That being said, I like the push for a multi message signature format that can work with JWT a lot... JOSE in general needs more support for this kind of thing.

The JWT examples are triggering, but that's not really your fault :)

I don't like that the JWT representation of VCs allows so much optionality for where things may be present... inside or outside, iss vs issuer, nbf vs issuanceDate... and I do love that despite not being required to, you have included `kid`... how else would you know which key the issuer used!?! btw you will still need to resolve this key somehow, which will involve hitting a cache or a network... JSON-LD has a standard way of doing this called a documentLoader... JOSE does not define something similar and neither does the VC Data Model... DID Core does, it's called de-referencing... but you need a DID URL to use it... which is why `kid` is so important.

Overall I think this is excellent, and it's going to be 100% necessary to advance JOSE based multi message signature schemes, we will need something like the approach you have taken... we can't just keep base64url encoding json strings and calling it a day...

Excited to see this work evolve particularly as it builds on the same underlying bbs with bls12381 signature suite that is used with existing LD Proofs.

I'd be interested in doing an implementation of this, especially since i just did an implementation of the linked data version last weekend:

https://github.com/transmute-industries/verifiable-data/tree/main/packages/bbs-bls12381-signature-2020


Replacing n-quads with an array of json path key values is pretty easy... and if you preserve `@context` in the JWT variant you can retrain semantic interoperability (and VC Data Model conformance)... you can even issue the JWT and the LD Proof from the same key at the same time... here is an example:

https://github.com/transmute-industries/verifiable-data/tree/main/packages/vc.js#create-verifiable-credential


OS


On Fri, Aug 20, 2021 at 11:53 AM Tomislav Markovski <tomislav@trinsic.id<mailto:tomislav@trinsic.id>> wrote:
Hello,

Cross-posting a work item proposal here, as per the instructions. Issue is already open at https://github.com/w3c-ccg/community/issues/204


New Work Item Proposal

We'd like to bring a proposal for extending BBS Signature schemes that explore their usability with non-Linked Data processing systems.

Include Link to Abstract or Draft

Experimental Doc / POC<https://trinsic-id.github.io/json-bbs-signatures/>

This is a working document only. If this item is adopted, we expected the final work to span multiple specs.

List Owners

Tomislav Markovski @tmarkovski<https://github.com/tmarkovski> (Trinsic)
Jakob Povšič @jkbpvsc<https://github.com/jkbpvsc> (GlobaliD)

Work Item Questions

  1.  Explain what you are trying to do using no jargon or acronyms.

Explore and develop additional schemes for BBS+ signatures that work with any JSON data. We intend this effort to have multiple deliverables in terms of specifications and reference implementations.

  1.  How is it done today, and what are the limits of the current practice?

BBS+ signatures today are defined as a Linked Data Suite<https://w3c-ccg.github.io/ldp-bbs2020/>. Their generation relies on using JSON-LD processors and works with JSON-LD compliant documents. Few limitations of this approach are:

  *   Requirement that verifiable data be always described as valid JSON-LD document, adding overhead and friction to systems
  *   Low availability of LD tools and libraries limit the platform use of BBS sigs
  *   Challenges to use BBS correctly with JOSE formatted signatures
  *   Reliance on connectivity for document resolution (limits offline usability)
  *   Potential data leaks with URDNA2015 algorithm in selective disclosure use cases

  1.  What is new in your approach and why do you think it will be successful?

The premise in the proposed approach is the use of a normalization algorithm based on JSON Pointer addressing for object normalization. This will allow any JSON data to be used with BBS signatures. This approach uses simple tools and algorithms that do not require LD compliance, although JSON-LD can be used just as easy.

  1.  How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)

We'd like to invite participants from different backgrounds and skillsets to contribute and ideate on this approach. We believe this community is best suited to expand the use of BBS signatures more broadly in the context of verifiable data.

  1.  What actions are you taking to make this work item accessible to a non-technical audience?

We've written a draft document that can serve as a starting point to understand the concept for non-technical audience. We'd like this effort to be a point of discussion for the viability of this approach at different levels. The opportunities with using BBS more broadly impact product designs and business decisions more broadly, and we're hoping all of these will be discussed as part of this work item development.



Tomislav Markovski
CTO @ Trinsic
trinsic.id<https://trinsic.id>


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

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>