- From: Hadley Beeman <notifications@github.com>
- Date: Thu, 03 Aug 2023 10:19:42 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 3 August 2023 17:19:48 UTC
Hi, @msporny @dmitrizagidulin @martyr280 @dlongley @brentzundel @Sakurann @iherman @philarcher @peacekeeper @pchampin! We (@rhiaro and I) reviewed this in our W3C TAG virtual face-to-face this week. First of all, we'd like to thank you for the clarity and conciseness of your explainer. Thanks! The architecture which enables use of different cryptosuites depending on needs seems sensible. How does this affect interoperability? Is a verifiable claim from an implementation using one cryptosuite readable by an implementation using another? We noted the contentious issue around requiring interoperability reports for cryptosuite specifications, and wondered what the different sides of the argument are for that. We also see that you're not rolling your own crypto in this architecture and want to applaud that. Sensible choice. Also noting that the specification could be put to general use, rather than being suitable only for VCs. Have you considered how to expand this work for other use cases? And have you thought about preceding work like XML signatures? If so, how does it feed into your thinking now? -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/850#issuecomment-1664352922 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/850/1664352922@github.com>
Received on Thursday, 3 August 2023 17:19:48 UTC