Supporting bound BBS signature usecases

[tplooker]

As has been discussed before in related communities, the loose intended definition of bound BBS signatures refers to a signature that features a binding to a secret key (private key) possessed by the holder, which is required to be known by the holder in order to derive a proof using the signature. Effectively it is the introduction of a proof of key possession factor to a BBS signature which increases the assurances a relying party or verifier has when presented with a derived proof.

Mechanically this "feature" could be realised in multiple ways which affect the scope of this draft:

1. Would be to leverage the blind sign functionality and treat the bound secret key as a blinded message.
2. Would be to doing something more opinionated at the level of this draft introducing the concept of bound signatures and potentially removing the more flexible blind sign functionality.

[BasileiosKal]

IMO if the main use case for blind signatures is for holder binding it may be better to move the blind signature functionality on a extension of the spec to keep the core spec as simple as possible (which IMO will be appreciated by the IETF). Holder binding could be achieved with similar but much simpler mechanisms.

[andrewwhitehead]

I would definitely be open to making the blind signature support an optional extension. For me it also raises questions about supporting deterministic signatures.

[brentzundel]

Since the underlying algorithm already natively supports the signing of blinded attributes which may be used for binding the signed data to a holder, it doesn't make sense to me to pursue alternative mechanisms for doing so.

[tplooker]

Without a proposal for holder binding done in a more opinionated way, I can see this perspective, however I do think there are simpler options so will put together something more concrete to help inform this discussion.

[quartzjer]

potentially removing the more flexible blind sign functionality.

This would invalidate private linking use-cases, where the holder wants to link different credentials together from multiple issuers without revealing the linkage to them, and can selectively disclose any linkages during presentation as needed. This looks like binding but is subtly different as both may need to exist separately in such use-cases.

Also, blind signing is useful as a private witness where the issuer can sign something the holder wants witnessed without having to reveal the contents.

[tplooker]

This would invalidate private linking use-cases, where the holder wants to link different credentials together from multiple issuers without revealing the linkage to them, and can selectively disclose any linkages during presentation as needed. This looks like binding but is subtly different as both may need to exist separately in such use-cases.

@quartzjer do you mean general private linking use-cases? like any attribute in common across credential / signatures? As i dont think this invalidates those usecases?

Also, blind signing is useful as a private witness where the issuer can sign something the holder wants witnessed without having to reveal the contents.

Agree with this, but IMO this is really just stating the most general class of usecases that blind sign solves for, is there anything more concrete we could discuss?

To be clear im not saying arbitrary blind sign functionality is not useful, just questioning whether we need to standardize that now, vs via an extension later. Because it significantly complicates the current draft. Essentially all the blind sign functionality defines is a pre-protocol for how a holder constructs a commitment representing a set of blinded messages and an issuer verifies this before including it in their issued signature.

[andrewwhitehead]

I think it's also fair to say that even if blind signing is removed from the core spec, we would ensure that it was not made impossible, and the functionality would likely remain in existing implementations.

[tplooker]

+1 @andrewwhitehead exactly

[quartzjer]

do you mean general private linking use-cases?

I was speaking to linking of multiple different credentials (by using the same link secret, blinded to multiple issuers).

I think it's also fair to say that even if blind signing is removed from the core spec, we would ensure that it was not made impossible, and the functionality would likely remain in existing implementations.

Ahh yes, this I completely understand and agree with, it can definitely be an extension since it is pretty self-isolated.

[tplooker]

I was speaking to linking of multiple different credentials (by using the same link secret, blinded to multiple issuers).

Ok great the proposal made in this issue would not eliminate that capability. As said above we are really just talking about the pre-protocol around blinding messages for an issuer to sign.

[tplooker]

Related to #37

[christianpaquin]

Rehydrating this discussion for a fresh new year :) As discussed on today's meeting, this group should make a recommendation on how to achieve user/holder binding in a uniform way to support credential profiles in various groups of interest (e.g., JWP, VC, anoncred). Sounds like next step involves creating a skeleton plan of what's needed to achieve this: update blind sig spec, and explain how to use it to bind a user-controlled secret to a BBS sig.

(tagging meeting attendees, FYI; @brentzundel , @BasileiosKal, @andrewwhitehead, @tmarkovski)

[OR13]

I am here to confirm that the current IETF drafts have no support for holder binding, and not timeline for adding it.

Is this correct?

The reason ask is the VCWG will not be commenting on anything that is not supported by the CFRG drafts, and as an editor of https://github.com/w3c/vc-di-bbs

I will be pushing to remove any mention of "linked secrets / holder binding" starting right now, based on my current understanding of the supported features in the draft.

[tmarkovski]

This is my understanding, yes. The Blind Signatures extension is not a CFRG draft and I don't believe a timeline has been set.

[BasileiosKal]

Yeap! That's my understanding as well! Holder binding will be out of scope for the current core CFRG draft.

That said, there is definitely interest in the WG to create separate documents describing that functionality (either updating the Blind Signatures document or creating a separate one just for Holder Binding).

As far as timelines go, there is non. However, i think the hope is that after the next IETF, the core draft will be stable enough so we can start working on those extensions (that will hopefully also be submitted to the CFRG).

[christianpaquin]

I'd be interested in seeing progress before the next IETF meeting. Even in draft form, a proposal we feel comfortable with could help shape things for potential integrators. I'm not a BLS/pairing expert, so it's not something I can lead, but I'd be interested in prototyping a proposal.

[BasileiosKal]

FYI: posted a draft document on Holder binding in #262

[tplooker]

Closing as duplicate of #262, where we can continue the conversation.