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


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

<https://www.transmute.industries>