> If the signed statement is "Whoever presents this is over 18", then I agree > there's no linkability risk. This is what I mean by a bearer token. If the > signed statement is "Person X is over 18", with the implication that the > recipient is supposed to verify that they are talking to person X before > inferring that the communicant is over 18, then the issuer and the verifier > need to have a consistent idea of who Person X is. It is not clear to me > that it is possible to do this unlinkably. Obvious approaches like "holder > of a private key" or "subject of a DID" provide easy correlators (the public > key or the DID).
Sorry I'm not sure I follow you here. If you can bind an issued credential to a public key in a way where the public key isn't revealed in the generated proof how does that not provide the cryptographic assurances of credential presentation using DID based binding without the correlation risk? 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: 14 October 2022 08:59 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 Thu, Oct 13, 2022 at 3:00 PM Tobias Looker <[email protected]> wrote: > My most significant concern is that it's still not clear to me that the > scheme here actually achieves the unlinkability it claims. If the issued > objects are not to be bearer tokens, they need to be sender constrained, > which means there needs to be a notion of "sender" that is intelligible to > both the issuer and the verifier. It is not obvious to me that there is any > cryptographic scheme that both provides this critical security property and > provides unlinkability. I admit that this might be because I don't > understand the nuances of the cryptography being applied here, but in any > case, there is a missing layer of description here that would outline the > overall cryptographic approach in a way that a generally crypto-savvy person > could understand. Without that, I can't support chartering a working group, > since it's not clear that it can actually achieve its stated goals. There are a couple of things to unpack/highlight w.r.t this, I can answer for BBS as an algorithm but multiple others algorithms considered in scope for JWP I believe have similar properties. 1. Proofs generated by BBS do not behave like bearer tokens. A "proof" which is the cryptographic structure generated by the prover using the signature from the issuer/signer represents a "proof of knowledge of signature", which proves to a verifying party that whoever generated the proof was in possession of a signature from the issuer. So if the signature as issued by the issuer is considered secret to the prover then only the prover is able to generate valid proofs. 2. If possession of the signature alone is insufficient as a sender/prover constraint then BBS allows for one of the messages that is signed by the issuer to be a public key supplied by the prover. Then when a proof is generated for such a signature, the prover must have possession of both the signature AND corresponding private key. The proof generated and sent to the verifier does not reveal the public key, but it is transperant to the verifier that the proof generated involved the prover knowing both the signature and required private key. You're talking about the signature. It's totally plausible to me that you can generate ZKPs on signatures with the properties you describe. I'm more concerned about the signed payload that comprises the rest of the JWP. If the signed statement is "Whoever presents this is over 18", then I agree there's no linkability risk. This is what I mean by a bearer token. If the signed statement is "Person X is over 18", with the implication that the recipient is supposed to verify that they are talking to person X before inferring that the communicant is over 18, then the issuer and the verifier need to have a consistent idea of who Person X is. It is not clear to me that it is possible to do this unlinkably. Obvious approaches like "holder of a private key" or "subject of a DID" provide easy correlators (the public key or the DID). Now, maybe the answer is that this WG shouldn't care about this, it's the business of the payload not the proof container to ensure that the payload isn't linkable. But if the utility is limited to bearer tokens, then any question of supporting VC is off the table, since a VC always has a "Person X". > Speaking of goals, the proposed scope seems very specific to the Verifiable > Credentials use case. This is very different from JWS and JWE, which are > generic cryptographic functions applicable to many use cases. To some degree > this is inherent, in that unlinkability doesn't make sense unless you have > the multiple legs of the VC interaction pattern that you don't want linked. > But the problem could be phrased more generally, in terms of the issuer, > presenter, and verifier roles and their expected capabilities. Before > chartering work here, the group needs to decide whether this work is > VC-specific or not, reflect that in the charter, and if generic, provide the > conceptual framework. The details of this framework can be worked out in the > WG, but the charter needs to contain at least an outline. While I believe the application of JWP for VC's is important I dont believe it is the only usecase (or set of usecases) for JWP and I dont think the work is being positioned overly coupled to the VC use case. JWP's design intent is to be a general purpose cryptographic representation format. +1, I just think we need to capture what that general purpose is. (It's clearly not "general purpose" in the sense that a "general purpose computer" is.) Signing and encryption provide integrity and confidentiality protection between a sender and a receiver. What's the similarly concise definition for JWP? --Richard 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: jose <[email protected]<mailto:[email protected]>> on behalf of Richard Barnes <[email protected]<mailto:[email protected]>> Sent: 13 October 2022 03:26 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [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. Hi all, Unfortunately, I won't be able to make the BoF today due to some conflicts. So here are some comments ahead of the BoF. tl;dr: There are still some serious issues. My most significant concern is that it's still not clear to me that the scheme here actually achieves the unlinkability it claims. If the issued objects are not to be bearer tokens, they need to be sender constrained, which means there needs to be a notion of "sender" that is intelligible to both the issuer and the verifier. It is not obvious to me that there is any cryptographic scheme that both provides this critical security property and provides unlinkability. I admit that this might be because I don't understand the nuances of the cryptography being applied here, but in any case, there is a missing layer of description here that would outline the overall cryptographic approach in a way that a generally crypto-savvy person could understand. Without that, I can't support chartering a working group, since it's not clear that it can actually achieve its stated goals. Speaking of goals, the proposed scope seems very specific to the Verifiable Credentials use case. This is very different from JWS and JWE, which are generic cryptographic functions applicable to many use cases. To some degree this is inherent, in that unlinkability doesn't make sense unless you have the multiple legs of the VC interaction pattern that you don't want linked. But the problem could be phrased more generally, in terms of the issuer, presenter, and verifier roles and their expected capabilities. Before chartering work here, the group needs to decide whether this work is VC-specific or not, reflect that in the charter, and if generic, provide the conceptual framework. The details of this framework can be worked out in the WG, but the charter needs to contain at least an outline. As I think I said at the last BoF, this work would be more compelling if it could be focused solely on unlinkability, instead of both unlinkability and selective disclosure. As SD-JWT demonstrates, the two properties are not inherently linked, and unlinkability is complicated enough to merit its own mechanisms. Even if selective disclosure is baked into the signature scheme (as with BBS IIUC), you could define this in terms of how the inputs are provided in a JWS. Hope this helps, and good luck with the BoF! --Richard
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
