search

w3c-ccg / community

COMMUNITY: W3C Credentials Community Group Community Repo
https://w3c-ccg.github.io/community
Other
41 stars 6 forks source link

BBS+ signature scheme for LDP using JSON Pointer Normalization #204

Closed tmarkovski closed 3 years ago

tmarkovski commented 3 years ago

New Work Item Proposal

We'd like to bring a proposal for BBS+ signature scheme for Linked Data Proofs based on simple proof generation algorithm using JSON Pointer Normalization.

Include Link to Abstract or Draft

POC Document

List Owners

Tomislav Markovski @tmarkovski (Trinsic) Jakob Povšič @jkbpvsc (GlobaliD)

Work Item Questions

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

This proposal describes a BBS signature suite for Linked Data Proofs using JSON Pointer Normalization to generate verifiable data. The main goal of this signature suite is to define additional BBS signature scheme that utilize simpler algorithms compared to existing ones. This is useful in situations where JSON-LD processors or suites are unavailable.

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

    Existing BBS+ Signatures 2020 scheme uses JSON-LD processors and data canonicalization using URDNA2015 in contrast to this suite which uses simpler normalization algorithm based on JSON Pointer document flattening. This normalization algorithm can utilize selective disclosure and ZKP features defines in the BBS spec.

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

The core principal in the proposed approach is the use of a simple algorithms for signature generation. It uses normalization algorithm based on JSON Pointer addressing for creating deterministic verifiable object state.

  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.

dlongley commented 3 years ago

Whenever some new work is going to be done in an area that very closely duplicates work elsewhere, I'm curious about the reasons why. I see you've provided a list here as an answer to Work Item question 2. Can you provide a few more details about some of these items?

Low availability of LD tools and libraries limit the platform use of BBS sigs

It would be good to know which platforms have support for JSON pointer/any other proposed replacement technologies that also lack the required LD tools/libraries. Can you mention which specific platforms these are and, for each one, which tooling is present for JSON pointer/etc and which LD tooling/libraries are required but missing?

Reliance on connectivity for document resolution (limits offline usability)

Does the current LD-based BBS+ signatures work item require connectivity? If not, what does this refer to?

Potential data leaks with URDNA2015 algorithm in selective disclosure use cases

Are there no potential data leaks with the JSON pointer/alternative approach? How do you know? Why would adopting an entirely different approach be better than patching potential problems with the existing approach?

tmarkovski commented 3 years ago

Whenever some new work is going to be done in an area that very closely duplicates work elsewhere, I'm curious about the reasons why.

I wouldn't consider this a duplicate, but rather an extension, certainly not a replacement. I think the main objective is the ability to work with verifiable data in a more flexible way, without requiring semantics introduced by JSON-LD.

I see you've provided a list here as an answer to Work Item question 2. Can you provide a few more details about some of these items?

Low availability of LD tools and libraries limit the platform use of BBS sigs

Mainly mobile platforms are lacking support for JSON-LD processors. Swift/ObjC are most notable. This also has to do with the BBS Suite availability for various platforms, but also, very significantly, with the complexity of the suite, compared to JSON Pointer processing.

It would be good to know which platforms have support for JSON pointer/any other proposed replacement technologies that also lack the required LD tools/libraries. Can you mention which specific platforms these are and, for each one, which tooling is present for JSON pointer/etc and which LD tooling/libraries are required but missing?

JSON Pointer processing is a fairly straightforward algorithm. The tools are available for all languages from multiple libraries, but also writing one is fairly trivial.

Does the current LD-based BBS+ signatures work item require connectivity? If not, what does this refer to?

No, it does not. This has to do more with practical applications of LD based signature suites, which rely on fetching remote documents to perform the processing (though caching can be used, but the reliance on online data source is still there by design).

Are there no potential data leaks with the JSON pointer/alternative approach? How do you know?

There aren't known leaks of the same nature as there are in URDNA2015. JSON Pointer does not produce "side effect" information in a ZKP context, as it doesn't calculate output data order based on input information. There may be other leaks, I definitely cannot predict this.

Why would adopting an entirely different approach be better than patching potential problems with the existing approach?

The data leak is just one (secondary) argument for this approach. The main argument for this work is expanding the use of BBS signatures beyond JSON-LD.

OR13 commented 3 years ago

The main argument for this work is expanding the use of BBS signatures beyond JSON-LD.

I would not position it that way, since thats already possible with https://github.com/mattrglobal/bbs-signatures.

No, it does not. This has to do more with practical applications of LD based signature suites, which rely on fetching remote documents to perform the processing (though caching can be used, but the reliance on online data source is still there by design).

There is no difference here really... You will need to resolve public key material to use any verification system... your system might not support semantic web standards, but it still needs the network when the cache is stale.

JSON Pointer processing is a fairly straightforward algorithm. The tools are available for all languages from multiple libraries, but also writing one is fairly trivial.

This is the big value add.

It's a simpler canonicalization algorithm, and an entry point for other multi message signature schemes with JOSE.

Mainly mobile platforms are lacking support for JSON-LD processors. Swift/ObjC are most notable.

It's hard to argue with facts like this.

I probably would not have worded the proposal or the spec the way you have, especially after spending so much time trying to harmonize JOSE with JSON-LD...

This isn't about "non-LD"... its about multi message ZKP support for JOSE.

You could do JSON-LD compatible VC-JWT with this spec and be 100% VC Data Model conformant... assuming that the JOSE changes necessary to call this a "JWT" are accepted / registered properly... you could also do a custom JWS that has nothing to do with VC Data Model or JSON-LD...

Now to the question of the work item... I am happy to help support this.

I think eventually we need to update:

https://www.iana.org/assignments/jose/jose.xhtml

Which means eventually we probably want a document that looks like this:

https://www.rfc-editor.org/rfc/rfc8812.html

dlongley commented 3 years ago

@tmarkovski, @OR13,

Mainly mobile platforms are lacking support for JSON-LD processors. Swift/ObjC are most notable.

It's hard to argue with facts like this.

Is it? I would have thought the Rust LD tools could be used there:

https://sprucesystems.medium.com/introducing-didkit-an-identity-toolkit-e0dfa292f53d https://spruceid.dev/docs/didkit/ https://spruceid.dev/docs/didkit/concepts/

Apparently, they are already doing LD signature suites, etc. in Native iOS and so on. What do you guys think, does this cover the ObjC case?

dlongley commented 3 years ago

@tmarkovski,

I wouldn't consider this a duplicate, but rather an extension, certainly not a replacement. I think the main objective is the ability to work with verifiable data in a more flexible way, without requiring semantics introduced by JSON-LD.

Ok, but we should be careful not to split the ecosystem -- that would be my concern.

Does the current LD-based BBS+ signatures work item require connectivity? If not, what does this refer to?

No, it does not. This has to do more with practical applications of LD based signature suites, which rely on fetching remote documents to perform the processing (though caching can be used, but the reliance on online data source is still there by design).

LD-based signature suites do not require any remote document processing. You can use a document loader that loads entirely local or static documents, including key material as you see fit.

Are there no potential data leaks with the JSON pointer/alternative approach? How do you know?

There aren't known leaks of the same nature as there are in URDNA2015. JSON Pointer does not produce "side effect" information in a ZKP context, as it doesn't calculate output data order based on input information. There may be other leaks, I definitely cannot predict this.

Well, "no known leaks" is not the same thing as "there cannot be leaks". The JSON pointer approach is new, right? If so, I'd expect very few people to have looked into it yet. In fact, just glancing at it now, it seems it already would leak information in a way that would be unavoidable without remodeling one's data in perhaps non-idiomatic ways. As an example, consider this data:

{
  "children": ["Pat", "Chris", "Jordan"]
}

Here, with the JSON pointer approach, in order to reveal item "Chris", you must also reveal its position in the list. This reveals that there are other items. With a data model that is graph-based, this information would be stored as either a set or a linked list, allowing the position information to be omitted during selective disclosure.

I would expect there to be similar problems with data like this:

{
  "name": "Pat",
  "friend": {
    "name": "Chris",
    "friend": {
      "name": "Jordan"
    }
  }
}

With the JSON pointer approach, one cannot disclose that Chris is friends with Jordan without also revealing that Pat is friends with Chris. Again, a graph model would allow this information to be disclosed separately. This is one of the strengths of the graph model and, my understanding is, it was one reason why the current BBS+ approach leveraged it for selective disclosure. So, it may be that the thing that was identified as adding "overhead and friction" could also be considered a key feature in enabling better selective disclosure in some cases.

It seems that there could be information leaks with the JSON pointer approach that depend on how data is modeled. If it turns out that all JSON data needs to be modeled in a flat structure in order to be safe for disclosure with the JSON pointer approach, then I'd be concerned that a new mechanism to reintroduce graph-like links would be proposed to compensate for the limitation -- and then we'd need another technology that could be viewed as duplicative. This is important to consider.

Regarding the known leaks with URDNA2015, my understanding is that they are based on blank node identifier labels -- and that there is a known and fairly simple remedy for all classes of that problem that is being implemented (the remedy in short is: HMAC the labels). A remedy will need to be created/expressed for the above problem with the JSON pointer approach. Further analysis of either approach may reveal other leaks that will need attending to, but it is known that the main thing URDNA2015 does is label blank nodes, so if that is solved, it does limit where the leaks could be.

OR13 commented 3 years ago

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

apparently DIF Crypto WG already started work on this.

relevant PRs:

quartzjer commented 3 years ago

Thanks for making the connection @OR13!

I'm very excited to collaborate together on this effort, there's about 6 months of history behind the JSON Web Proof development with some discussions in the OpenID Connect A/B Working Group and SIOP special topics calls, but having new/more perspectives is exactly on goal for the work item in the DIF crypto working group.

Please feel fee to make use of the issues on the official repo: https://github.com/json-web-proofs/json-web-proofs and we'll be setting up bi-weekly work item calls very soon.

tmarkovski commented 3 years ago

Thanks for the investigative work @OR13! It seems the JOSE related work of my proposal can be done alongside the JWP efforts. I'll bring my ideas on BBS with JOSE to the JWP/crypto-wg team. @quartzjer I'm super excited about this, I hope I can shed more light on potential use cases for JWP.

That said, I think I can re-scope this proposal to focus on LDP BBS+ Signatures using JSON Pointer normalization to support additional use cases, similar in nature and intention to Jcs signature scheme. I think there are valid uses for both signature schemes. @dlongley Your concern on ecosystem fragmentation is valid. I do, however, believe that this (extending BBS with additional suites) may have the opposite effect and direct more adoption towards the ecosystem. The reason I think this, is because I don't think having Jcs Signatures fragmented the systems - in fact, it allowed my company's applications to adopt VC's and ZCaps, because of it. I think the ecosystem is anchored around the semantic web data model, and less around the proof formats or their methods of generation. With BBS sigs potential standardization, I think it's important that we continue to innovate in the area of multi-message proofs, and hopefully bring more meaningful synchronization between LDP and JOSE.

@dlongley I think you make some great points on the JSON Pointer algorithm, and I'd like to continue this conversation. I'll do that in a separate comment.

vsnt commented 3 years ago

I have added this work item to the 9/21 CCG call agenda to review+discuss with the community. Would the owners please attend this meeting. Thank you. https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0074.html

tmarkovski commented 3 years ago

We'll be on, thanks @vsnt

vsnt commented 3 years ago

Per discussion at the 9/21 CCG call, this work item has entered the 7 day review period. If anyone has concerns about this becoming a work item, it should be raised prior to EOD Sept 29, 2021. If no concerns are raised, this will move to a work item at that time.

tmarkovski commented 3 years ago

@vsnt, we're ready to move forward with the work required for this work item. There haven't been any objections or concerns about this. We will be working on two separate deliverables for this

What is the process for this at this point? Should we create couple of repos for these work items within the ccg organization, or should we work on these separately and transfer them over when the specs are ready for review. If option 1, repos can be named ldp-bbs2021 and ldp-jcp

vsnt commented 3 years ago

@tmarkovski I've created the work item repo for you here: https://github.com/w3c-ccg/BBS-LDP-JSON-Pointer-Normalization. LMK if you want to change the name or need an additional repo.

Closing this item.