> 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. > 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. 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]> on behalf of Richard Barnes <[email protected]> Sent: 13 October 2022 03:26 To: [email protected] <[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
