Thanks Richard, I think this is a great summary. A couple of responses to your questions below
> 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? So the term "BLS" is a little overloaded here unfortunately. In the wider area of pairing cryptography there is the BLS curve (Barreto Lynn Scott) [1] which can be used with a variety of different crypto protocols and scheme, BBS is one such an algorithm, there is also the BLS (Boneh Lynn Shacham) [2] signature scheme that can also use the BLS curve. In the context of BBS the core algorithm is defined agnostic of the curve, essentially you can use any pairing friendly curve, we have so far defined two ciphersuites that both use the BLS curve, the 12-381 construction to be precise [3]. So when you say "BLS Key" in the context of BBS, if you mean the curve then yes both the issuer and holder/prover key pairs have to be based on the underlying curve in use. > 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? Correct the holder/provers key pair they use for sender constraint has to be based on the same curve that the issuer is using to issue the signature with. > 3. This private-key-as-signed-message scheme seems pretty specific to BBS. > Are there other algorithms that have similar abilities? Not really there are quite a few algorithms in the broader blind/group/ZKP signature family that have these supported properties. Many of those Jeremie listed in the BOF are capable, IMO the disconnect is that academia often describes the capability different to how we would e.g instead of saying proof of possession or sender constrained security token, terminology like "linked secret" or "pre-committed messages" is used. > 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. Yes that is correct the verifier of a proof knows how many messages are un-revealed and *potentially* of the "revealed messages" which index each revealed message occupied when originally signed. [1] https://link.springer.com/chapter/10.1007/3-540-36413-7_19 [2] https://www.iacr.org/archive/asiacrypt2001/22480516.pdf [3] https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html#name-bls12-381-ciphersuites Thanks, [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]<mailto:[email protected]> [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> [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> [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> [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 14:29 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. 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, [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]<mailto:[email protected]> [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> [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> [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> [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]<mailto:[email protected]>> Sent: 18 October 2022 03:48 To: Tobias Looker <[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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
