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

> different from the work that needs to be done to understand and implement
the security and privacy properties of the wallet itself.

So you're saying that we should be defining a wallet security and privacy
threat model effectively. I generally agree with this, but I'd argue that
this shouldn't be standardized. Instead, it's implementers specific in the
same way that not every browser implements the same privacy capabilities
[1]. There absolutely will be cases where wallets could be abusing the data
they maintain for their users, in the same way that each browser has its
own definition of what data is acceptable for telemetry. For example, Brave
strips out much of chrome's telemetry system in favor of our own P3A data
[2] which limits our capabilities to cryptographically guarantee we only
receive the data if a sufficient K-anonymity value is met [3]. The same can
be applied for a security model as well.

All very good questions in your previous response as well. Here's how I'd
generally respond to most of them:

In general, I'd say this is the responsibility of the wallet and generally
isn't the concern of an issuer or verifier which I think is where we may
have been misaligned previously. This behaves in the same way that a web
page doesn't take responsibility for making sure Chrome 0-days are not
affecting their users. If chrome has a 0 day, it's chrome's reputation and
responsibility to protect its users. Just as it's Brave's responsibility to
rebase these updates in ASAP as well whereas Electron doesn't take the same
stance so can often be exploited by the chrome 0 days for longer. This is
actually the reason Brave moved away from an Electron based implementation
and simply started building on the chromium source itself. Does any of that
seem misaligned with your thinking still?

Here's a question that I think that may lead you to how I think about this
better. Would you be a proponent of regulations that a user can only use a
browser that has been audited and how nuanced is this auditing? Should
every commit and release of Chrome be audited or is it just periodically
audited in the same way companies do external pentesting audits. Once we
start to apply this concept of auditing to browsers it all of a sudden
stops making much sense in the same way we probably don't want to be doing
this for wallets. If we encounter rampant problems with wallets siphoning
data (in the same way that some browsers siphon more data than others) I
think that's when we cross the bridge of considering regulation to stop the
problem. I suspect in many cases comprehensive data privacy laws will
already apply here though so additional regulation won't be necessary in
many jurisdictions. AFAIK the US federal government is still dragging it's
feet on this so it may require usage of CCPA to enforce this better.

> But W3C VCDM usage is not just related to low assurance use cases but to
all use cases, so limiting the conversation to only securing the payload
and the pipes looks to be something that is very much a gap that exists.

That's largely due to the VCWG being scoped to defining only a data model.
IIRC DIF did have a wallet WG at one point that was working on something
like what you're describing, but I doubt any W3C WG will be able to scope
in what you want to be technically defined here. Additionally, I'd be an
advocate for saying this is not something we should be standardizing in the
same way we don't standardize a browser threat model. Instead it's
implementation specific.

> Given that for even low assurance use cases, you would need **some**
level of confidence that you can have in the wallet that is distinct and
different from the confidence in the pipe and the payload

Who's the "you" here? Is it me with my user hat on or me as a developer of
an issuer/verification service? Mainly asking because as a user I don't
care what someone else does with their attestations I make about them. As a
developer, I also don't care but that's because I don't believe using a
"big desk little person" pattern solves this problem as Dave pointed out
previously.

> To be clear, I am not pushing for anything at this time other than the
need for a discussion to identify what the needs and capabilities **for
wallets** are across the ecosystem AND to understand the options that exist
or need to be exist to meet them

I agree, but I will say this has to be done specifically only from the
interests of the software acting as a semi-fiduciary user agent to the
user. We cannot conflate requirements of issuers/verifiers and infringe
those as requirements of wallets which I think is what has led to the
division to date.

> That would give a solid foundation and the language needed to those
interested in the conversation to have an informed discussion, which could
lead to identifying who needs to do what and/or their willingness or lack
thereof to do it.

Agreed, this is how we'd want to go about achieving it. My scepticism comes
from years of knowing that it's usually not users asking for these things,
but rather issuers/verifiers so that leads me to be skeptical that the time
spent on level setting will lead to any notion of formal consensus and
normative changes within specifications is all.

-Kyle

1: https://privacytests.org/
2: https://github.com/brave/brave-browser/wiki/P3A
3:
https://brave.com/research/star-secret-sharing-for-private-threshold-aggregation-reporting/

On Tue, Nov 14, 2023 at 9:02 PM John, Anil <anil.john@hq.dhs.gov> wrote:

> > 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.
>
>
>
> I guess this is where I am having a disconnect.
>
>
>
> I consider the work done to define how to secure the VCDM (using a variety
> of approaches) and the work being done on how to ensure that protocol
> interactions that move that data (model) around between issuers, holders,
> and verifiers are also secure, to be distinct and different from the work
> that needs to be done to understand and implement the security and privacy
> properties of the wallet itself.
>
>
>
> Some semi-random questions to drill down a bit into this:
>
>    - Is the wallet storing the data locally on the device or is it
>    storing it in the cloud? Does that have any impact on the attack surface
>    exposed by the wallet? If so, how are they being mitigated?
>    - Is wallet simply behaving like a filesystem that allows read/writes
>    by anyone or is it implementing some manner of sealed storage capabilities?
>    - Is the wallet leveraging the cryptographic primitives of the
>    operating system or are those capabilities externalized?
>    - Is the wallet using or able to use hardware storage of the platform
>    or does it leverage a secure hardware storage mechanism in the cloud?
>
>
>
> I absolutely get the https://disco.xyz use case and the need to have a
> nuanced and thoughtful discussion so that we are not applying the same high
> assurance need/bar to all use cases, and I will also agree that many of the
> questions I ask above are related to high assurance use cases.
>
>
>
> But W3C VCDM usage is not just related to low assurance use cases but to
> all use cases, so limiting the conversation to only securing the payload
> and the pipes looks to be something that is very much a gap that exists.
> Given that for even low assurance use cases, you would need **some**
> level of confidence that you can have in the wallet that is distinct and
> different from the confidence in the pipe and the payload.
>
>
>
> >... push for that capability to be added to the web platform it will be a
> non starter
>
>
>
> To be clear, I am not pushing for anything at this time other than the
> need for a discussion to identify what the needs and capabilities **for
> wallets** are across the ecosystem AND to understand the options that
> exist or need to be exist to meet them. That would give a solid foundation
> and the language needed to those interested in the conversation to have an
> informed discussion, which could lead to identifying who needs to do what
> and/or their willingness or lack thereof to do it.
>
>
>
> Best Regards,
>
>
>
> Anil
>
>
>
> 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.
>