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

See also:

https://github.com/decentralized-identity/crypto-wg/blob/main/work_items/json_web_proof.md
<https://github.com/decentralized-identity/crypto-wg/blob/main/work_items/json_web_proof.md>

Apparently DIF crypto wg is attempting to define a more generic proof
format for JSON that can handle multi message signatures already.

I suggest we get everyone in the same room...

OS

On Sat, Aug 21, 2021 at 10:38 AM Tomislav Markovski <tomislav@trinsic.id>
wrote:

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


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

<https://www.transmute.industries>