Re: How much is it reasonable to generalize from the TruAge implementation?

> 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]
>
>
>
>
>