- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Mon, 29 Aug 2022 17:01:47 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <DM8PR02MB8181D22E93555041B4FBA76FCD769@DM8PR02MB8181.namprd02.prod.outlook.com>
I am all for having a proposed specification… HOWEVER, given that the links below refer to a specification being done by the DIF – an organization that operates under its own IP policy – I don’t understand how members of the W3C’s VCCG can (a) participate or contribute and (b) how the work could be adopted by the VCCG (except by reference). Leonard From: Manu Sporny <msporny@digitalbazaar.com> Date: Monday, August 29, 2022 at 9:16 AM To: W3C Credentials CG <public-credentials@w3.org> Subject: Re: Initial did:key interoperability test suite launched EXTERNAL: Use caution when clicking on links or opening attachments. On Mon, Aug 29, 2022 at 12:42 AM Markus Sabadello <markus@danubetech.com> wrote: > And regarding "a generalized plan for Create, Update, and Deactivate", we have been working on a specification for this as well: +1 to having a specification to do this. IMHO, it's going to be fundamental for the next iteration of the DID WG. Given Google, Apple, and Mozilla's previous objections, we'll have to be able to demonstrate DID Method interoperability and having a client interface for executing all of the DID Operations will be key to showing multiple interoperable implementations per DID Method. -- manu -- Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bntmucIH3eTxE6ZFAEQ4XIovswQLbG5uyX2MS7S8G9k%3D&reserved=0 Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jlJ6vHMv2hjICV7wYiPQiEvZEI1bE1UM2M9%2BuHMYBQ4%3D&reserved=0 On Mon, Aug 29, 2022 at 12:42 AM Markus Sabadello <markus@danubetech.com> wrote: > > And regarding "a generalized plan for Create, Update, and Deactivate", we have been working on a specification for this as well: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fidentity.foundation%2Fdid-registration%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5Ac1yFi%2FIyTAMV9Ck8OaAlJ4T53rMSJo5NQcI2uJDVM%3D&reserved=0 > > The idea is similar as with DID Resolution, i.e. define abstract interfaces with inputs and outputs, and then implement them using concrete bindings (e.g. over local API call, or HTTP, DIDComm, etc.) > > We have implemented this in the "Universal Registrar" project: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdecentralized-identity%2Funiversal-registrar&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ivsjO52HA74BETx9aEACiGy%2Fq0j6UGXljNI8Dd3pzLU%3D&reserved=0 > > And I know others in the community (Veramo, ACA-py, etc.) are also working on generalized create/update/deactivate APIs. > > It would be great to get additional community input for this work! > > Markus > > ----- Manu Sporny wrote ----- > From: Manu Sporny <msporny@digitalbazaar.com> > Date: 27.08.2022 16:28 > To: Joel Thorstensson <oed@3box.io> > Cc: W3C Credentials CG <public-credentials@w3.org> > Subject: Re: Initial did:key interoperability test suite launched > > > On Fri, Aug 26, 2022 at 1:57 PM Joel Thorstensson <oed@3box.io> wrote: > > Why does the test suite rely use http? > > > The best alternative we could think of would: > > * Ask every developer to create and maintain a docker image for their > did:key resolution library. > > * Create a complex test environment that would be specific to DID > Methods where the test suite downloads every implementation docker > image and runs it against the test suite, collating the output, and > producing a report, which would not be adequate for seeing if the DID > Resolver is actually modifying/munging the output of the DID Method > implementation... so we'd have to have a separate DID Resolver test > suite for each DID Method anyway. > > IOW, it would require almost the same amount of effort from the > developer for something that doesn't meet our community testing > requirements for production-grade library implementations. > > > Does this mean that I need to run and maintain a server to prove that my implementation conforms to the spec? > > > It means that /someone/ will need to run and maintain that server (or > pay you to do it), yes. For-profit enterprises that need to prove the > production-readiness of their systems will have a strong incentive to > do this for you if they use your library. At this point in history, > the cost of running such a system is no longer an issue -- Linode has > shared CPU plans that start at $5/month, which is a rounding error for > most any organization. > > The other benefit we get with an HTTP API-based testing methodology is > getting a jump-start on a DID Resolution test suite as well as a > scalable mechanism for testing DID Method specifications... we're > demonstrating DID Method READ right now... with a generalized plan for > Create, Update, and Deactivate on the way. If we're able to pull the > latter off, we'll be able to demonstrate interop across multiple DID > Methods, which is the next step in our community's evolution -- > globally standardized DID Methods with real demonstrable proof of > interoperability. > > Did that answer your question, Joel? > > -- manu > > -- > Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bntmucIH3eTxE6ZFAEQ4XIovswQLbG5uyX2MS7S8G9k%3D&reserved=0 > Founder/CEO - Digital Bazaar, Inc. > News: Digital Bazaar Announces New Case Studies (2021) > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jlJ6vHMv2hjICV7wYiPQiEvZEI1bE1UM2M9%2BuHMYBQ4%3D&reserved=0 > > -- Manu Sporny - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bntmucIH3eTxE6ZFAEQ4XIovswQLbG5uyX2MS7S8G9k%3D&reserved=0 Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.digitalbazaar.com%2F&data=05%7C01%7Clrosenth%40adobe.com%7C1e8b41c2acfd464d22a508da89c0b1e8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637973757978032744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jlJ6vHMv2hjICV7wYiPQiEvZEI1bE1UM2M9%2BuHMYBQ4%3D&reserved=0
Received on Monday, 29 August 2022 17:02:02 UTC