On Thu, Oct 13, 2022 at 9:21 PM Tobias Looker <[email protected]> wrote:
> > 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? > 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: 1. What is in the VC payload that is presented to the verifier? 2. How does the verifier process that payload to verify the above property? For example, in the case where the subject is identified by a concrete key, (1) is a "did:key" or some other concrete representation of the subject public key, and (2) is verifying that the presentation demonstrates possession of the corresponding private key. As an aside: It's not clear to me why a verifier would want to know that a signature exists if they can't tell something about the signer. Rather than "some unspecified person made a signature over this payload", it seems like would at least want to know "an entity with X properties made a signature...". Where X would be something like "corresponding to a DID" or "authorized within some system". Otherwise the signature has no meaning! --Richard > > 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:* 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, > > [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:* 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
