Tobias was kind enough to talk this through with me, and indeed we were
talking past each other! I learned a couple of major things about how
folks are envisioning using BBS (and presumably other similar things) in
this domain, so under the theory that these might be new to others as well,
I thought I would recap the discussion here.
First, the general shape of BBS is as follows:
* An issuer produces a signature over a list of messages
* Someone who knows (a) the full list of messages and (b) the signature can
select a subset of the messages to reveal to a verifier and construct a
zero-knowledge proof of the following:
* The prover knows a challenge provided the verifier
* The prover knows the full list of messages
* The prover knows a signature by the issuer's key pair over the full
list of messages
* The messages revealed to the verifier are a subset of the messages
covered by the signature
The question I had is how this scheme can lead to the signed object being
sender-constrained, in the sense that the prover can only construct a valid
proof if it holds a given private key.
The BBS construction itself provides a degree of sender-constrained-ness,
if you assume that the signature is private to the issuer and the prover.
In that case, the proof generated by the prover proves possession of the
signature, which is known only to the issuer and the prover. This still
allows the issuer to construct a valid proof, though.
You can get a more traditional notion of sender constraint, where the
private value is only ever held by the prover, by exploiting an additional
feature of BBS. The messages signed by the issuer must be converted to EC
points before being incorporated into the signature. For messages known to
the issuer, the issuer does the conversion. The issuer can also accept
points that have been converted by someone else, in which case the signed
message is unknown to the issuer. Conveniently, the "convert message to
point" function is the same as the "convert private key to public key"
function for BLS keys used by BBS. So you can have a scheme like the
following:
- When the prover requests a signature from the issuer, it includes (a) its
public key, and (b) a BLS signature that proves that it controls the
corresponding private key
- The issuer verifies the proof-of-possession signature, and if valid,
includes the public key (an EC point) among the points representing
messages covered by the resulting signature
The issuer thus includes the **prover's private key** as one of the signed
messages, without having to know it. Because the prover has to know all of
the signed messages in order to generate a valid proof, it can only
generate a valid proof if it knows the private key that was "signed" by the
issuer.
Given all that, I am now convinced that BBS allows you to make tokens that
are sender-constrained without allowing linkability! Many thanks to Tobias
for walking me through this. Hopefully my recap isn't badly wrong :)
All that does lead me to a couple of follow-up comments/questions related
to WG scoping and formation:
1. The above "general shape of BBS" seems like a nice, concise summary of
the thing that JWP is trying to capture, analogous to signature/encryption
for JWS/JWE. It would be good to capture something like this in the
charter, including the issuer-prover-verifier taxonomy.
2. It seems like the tight integration here means that you can only get the
private-to-the-prover-alone flavor of sender constraint if the prover's key
is a BLS key. Is that correct?
3. This private-key-as-signed-message scheme seems pretty specific to BBS.
Are there other algorithms that have similar abilities?
4. In BBS, does the proof reveal the indices of the revealed messages in
the overall list? That seems like it could have some impact on linkability.
Cheers,
--Richard
On Mon, Oct 17, 2022 at 4:48 PM Tobias Looker <[email protected]>
wrote:
> I think we are talking past each other. What I tried to explain previously
> is that the way an algorithm like BBS achieves cryptographic holder/prover
> binding doesn't reveal an identifier like a DID or a public key to the
> verifier, removing this vector of correlation while still providing the
> same assurance.
>
> Thanks,
>
> [image: Mattr website]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
>
>
>
> *Tobias Looker*
>
> MATTR
> CTO
>
> +64 (0) 27 378 0461
> [email protected]
>
> [image: Mattr website]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>
>
> [image: Mattr on LinkedIn]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>
>
> [image: Mattr on Twitter]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>
>
> [image: Mattr on Github]
> <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
> ------------------------------
> *From:* Richard Barnes <[email protected]>
> *Sent:* 18 October 2022 03:48
> *To:* Tobias Looker <[email protected]>
> *Cc:* [email protected] <[email protected]>
> *Subject:* Re: [jose] Some JWP comments
>
> EXTERNAL EMAIL: This email originated outside of our organisation. Do not
> click links or open attachments unless you recognise the sender and know
> the content is safe.
>
>
>
> On Sun, Oct 16, 2022 at 6:01 PM Tobias Looker <[email protected]>
> wrote:
>
> > The verifier of a VC needs to know that the entity presenting the
> credential is the same as the subject that the issuer issued the credential
> to. Can you provide an example of how the verifier is assured of that
> without revealing a public key or a DID or some constant, correlatable
> identifier? Specifically:
>
> To the contrary can you expand on how revealing a DID or public key to the
> verifier alone provides this assurance?
>
>
> If the DID or public key is constant for a given signature, and I reveal
> that to two verifiers, that seems like it allows the verifiers to link the
> credentials pretty trivially, right? Just by checking that the same DID or
> the same public key was presented in two interactions. And this is true
> even if the signature on the credential is different in the two
> interactions.
>
> In other words, suppose the VC signature covers (attributes, DID/Pubkey);
> then two presentation interactions would present:
>
> A: subset(attributes), DID/Pubkey, ZKP1 of signature over (attributes,
> DID/Pubkey), proof of possession of DID/Pubkey
> B: subset(attributes), DID/Pubkey, ZKP2 of signature over (attributes,
> DID/Pubkey), proof of possession of DID/Pubkey
>
> It seems to me that all of the elements in those presentations can vary
> **except for the DID/Pubkey**. Because that's how the subject is
> represented, so it can't vary between issuance and presentation. And
> because you have that constant correlator, the interactions are linkable,
> even though everything else is randomized.
>
> (You could do something like having a bucket of DIDs/Pubkeys that are
> selectively disclosed in different interactions. But this doesn't help:
> You only get a fixed number per credential, and you have to burn one per
> presentation, so you eventually have to go back to the issuer and refresh.
> And has been discussed elsewhere on this list, if you can go back to the
> issuer and refresh, you don't need the fancy ZKP signatures.)
>
> --RLB
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
