- From: Kyle Den Hartog <kyle@pryvit.tech>
- Date: Tue, 14 Nov 2023 14:03:07 +0300
- To: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CA+_U+e1txbmdAZmORwLtTkwHuAQzMqZXtN6nDcE6-s0Gb88ekQ@mail.gmail.com>
> shared definition of what capabilities a digital wallet must have Fundamentally, I do think we have defined these and they're represented within the data model pretty well. Most people agree we should be able to sign credentials to make them verifiable and should represent this via the proof value. What I don't think we have consensus on is that high assurance capabilities (such as some of the ones highlighted by Manu's email) are necessary so consensus hasn't been achieved on these. It's specifically businesses and governments driving these use cases who need to meet regulatory requirements that need these capabilities and need to detect them. For many other use cases these become unnecessary hurdles that just makes it harder for the rest of people to work with these technologies (in the same way adding any new feature to the data model has increased complexity) and likely hurt adoption overall as pointed out in the paper I linked to in my previous email. For example, let's look at one example of how verifiable credentials are being used in web3. At https://disco.xyz they're using VCs as a low stakes attestation that 2 people met in person. If we compare the differences between DHS credential issuance and disco.xyz issuance it points to the vast differences for what verifiable credentials are being used for and why a shared vision is likely going to get halted by a difference in values and technical requirements. If I just want to attest that I've met a person, I don't need to care how they're storing that attestation. For that matter, I don't even care if they keep it. I also don't need to revoke it nor do I need the complexity of caring about what kind of device they're using. And I probably don't want to think about another feature that's required by some regulatory profile of features just to rely on a library that does the basics for me. What use cases like this need is to just be able to send the credential to the counterparty and it's up to them to do what they want with it. This is the same way that a server doesn't need assurances about my browser when they serve me HTML/JS which has been good enough to build the entire web so far. The server just needs to hand the files over and my browser (or maybe my terminal when I curl the URL) will do what it wants with them. This is also why I pointed to the WEI discussions previously is that the similarity in capabilities (but with different files and formats) has been objected to and it wasn't because of the files or the formats. Putting this all together, this difference in needs (and more importantly values) is likely going to lead to the inability in achieving consensus from many vocal users who've already gotten their pitchforks out for WEI and are just starting to calm down. So, I'd make a best guess that this will face a similar reaction as soon as governments and businesses start requiring them to use a particular piece of software with a set of capabilities (that they can't modify) to hold their credentials. So while governments may be interested in this and there may be various people representing businesses here in the community who are interested in this, I'm highlighting that as soon as someone suggests "we want the capability to have assurance that these credentials will be safe on your device" and push for that capability to be added to the web platform it will be a non starter. Especially if the eventual goal is to expose this capability within something like the identity credential web platform API. This is just my assessment though based on my understanding of the broader web platform and verifiable credentials. Maybe people won't respond so viscerally to this when it's to be able to share a driver's license with reddit or twitter to view a NSFW picture, but I have my doubts about that perspective. -Kyle On Tue, Nov 14, 2023 at 12:12 PM John, Anil <anil.john@hq.dhs.gov> wrote: > >Out of curiosity, how are people looking to support “Capability > detection” while still keeping the wallets and web platform open? > > > > My specific point is the following from my original e-mail: > > > > I think it is important if you seek a future of multiple independent, > interoperable and capable digital wallets, the global community (including > both the public and the private sector) put energy into developing a shared > definition of what capabilities a digital wallet must have, how you can > assess and evaluate the quality of those capabilities, and ultimately > support mechanisms and process that use those openly developed criteria to > do certifications and assessments of digital wallets against a set that > shared, open criteria. > > > > What has become clear by the responses is that when folks speak to > “capability detection” it means something different for different people. > There needs to be a priority in the community to **develop a shared > definition of capabilities** that allows for detecting the granular > capabilities of the wallets (TBD) rather than detecting the vendor or > jurisdiction that produced it as a proxy for capabilities, while ensuring > that the openly developed shared criteria (TBD) take into account an > approach that ensures an open, standards-based and competitive ecosystem > with input from relevant stakeholders in both the privacy and security > communities. > > > > This is not happening right now. > > > > The vast majority of the conversations about wallets are about what > protocols and credential formats they support, and not about how the “thing > that actually stores and protects the information in credentials” is > defined. > > > > Because it is not, the conversation of what a good, standards-compliant, > secure and privacy respecting wallet is, is being defined by vendors and > platforms articulating capabilities and features only their particular > wallet product can meet. > > > > Best Regards, > > > > Anil > > > > Anil John > > Technical Director, Silicon Valley Innovation Program > > Science and Technology Directorate > > US Department of Homeland Security > > Washington, DC, USA > > > > Email Response Time – 24 Hours or more; I sometimes send emails outside of > business days/times because it works for me; please do not feel any > obligation to reply to them outside of your normal working patterns. > > > > [image: A picture containing graphical user interface Description > automatically generated] <https://www.dhs.gov/science-and-technology>[image: > /Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395] > > > > >
Attachments
- image/jpeg attachment: image001.jpg
- image/jpeg attachment: image002.jpg
Received on Tuesday, 14 November 2023 11:04:26 UTC