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

The EIDAS 2.0 wallets (that are intended to include lots of VCs with PII) that the EU will require its member states to make available to its citizens (that want them), would be certified against a yet-to-be-determined scheme and then ‘notified’, i.e. put on a list of wallets. EIDAS 2.0 will require many financials, health organizations, etc. to accept every such wallet for identification/authentication purposes. Hence, such organizations will at least be required (by law) to determine whether or not a user is using a notified wallet. While this is not a capability of the wallet, it comes close, in the sense that capabilities can be seen as characteristics/properties that a wallet has, and that issuers and/or verifiers (and perhaps holders) would want to be able to assess.

Rieks

From: John, Anil <anil.john@hq.dhs.gov>
Sent: 15 November 2023 18:58
To: W3C Credentials Community Group <public-credentials@w3.org>
Subject: RE: How much is it reasonable to generalize from the TruAge implementation?

I appreciate your thoughtful response. Let me start my response by answering the following question first –

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

The You (Me) here is:

  *   Me as an individual seeking to use a digital wallet with the confidence that it is not a see-thru plastic bag storing credentials that contains personal information that everyone has visibility and access to and can use, abuse and monetize without my consent and knowledge.
  *   Me, representing the perspective of high value credential issuers (immigration, citizenship, residency and employment permissions, cross-border travel) who could suffer reputational harm that impacts online service delivery, if our well protected credentials issued by our infrastructure using well designed and secure protocols into crappy digital wallets results in those credentials (and their associated private information) becoming  openly available.  The maturity level of our ecosystem is not currently at the stage there will be any understanding by the vast majority of our customers of the nuance between what was actually broken – the issuance process/infrastructure, the credential or the digital wallet; the issuer will end up holding the bag here (at least until our ecosystem is a lot more mature), so I am greatly motivated in distinguishing between wallets that are implemented with the proper protections and those that are not … and I do not know what the criteria that I should be using for doing so!
  *   Me, representing the perspective of verifiers of high value credentials – My perspective (which may or may not be shared by many, even within my own organization) is that I am less concerned about the wallet here for one very specific reason in this situation. The types of credentials I need to verify as part of the input to an adjudication process for benefits (immigration, residency, work permit, travel) are NOT bearer credentials – They are credentials that require me to ensure that the carbon-based life-form that is presenting the credential is indeed the specific human to whom that credential was issued by an Issuer that I choose to recognize as being authoritative for that credential (i.e. I will always implement Identity Verification in such cases).

Using the above as context, let me go into some of your other points and questions:

>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

I freely acknowledge that I don’t know what I don’t know. However, one thing that I do know is that it is possible to make a distinction between WHAT and HOW. It may very well be that HOW something is done may be very bespoke to the wallet and therefore cannot be standardized (leaving open that possibility) but I still think that it is possible to determine a set of definitions/language/criteria for WHAT needs to be done. It may not be a standard or even a spec, but it could be a set of criteria or principles or choices made that are *testable and verifiable*. Did you do this? (Even if how one entity met criteria is different from another entity)

> 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 …
> If chrome has a 0 day, it's chrome's reputation and responsibility to protect its users …
> Does any of that seem misaligned with your thinking still?

The thing is I agree with your perspective here from a technical perspective. Where I disagree with is on whom the reputational harm will befall (Issuer) *at the current level of maturing of the ecosystem*. I think this will change as folks become much more familiar and comfortable with the various components they are using, but don’t think we are there yet.

In addition, how can we (as end-users, Issuers and Verifiers) know that the wallet has fulfilled its responsibilities? Is this something that is simply self-asserted or something more?

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.


From: Kyle Den Hartog <kyle@pryvit.tech<mailto:kyle@pryvit.tech>>
Sent: Tuesday, November 14, 2023 7:16 PM
To: John, Anil <anil.john@hq.dhs.gov<mailto:anil.john@hq.dhs.gov>>
Cc: W3C Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: How much is it reasonable to generalize from the TruAge implementation?

CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.

> 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/<https://urldefense.us/v3/__https:/privacytests.org/__;!!BClRuOV5cvtbuNI!Caao82RU0ElUlPRqi5DSxHJEYAeBH8O0e7_s0YeuqncqXch1d3_ve4SnKzqWwcPKyVvOhswNyKYAYDh65C_q$>
2: https://github.com/brave/brave-browser/wiki/P3A<https://urldefense.us/v3/__https:/github.com/brave/brave-browser/wiki/P3A__;!!BClRuOV5cvtbuNI!Caao82RU0ElUlPRqi5DSxHJEYAeBH8O0e7_s0YeuqncqXch1d3_ve4SnKzqWwcPKyVvOhswNyKYAYPNoV1VB$>
3: https://brave.com/research/star-secret-sharing-for-private-threshold-aggregation-reporting/<https://urldefense.us/v3/__https:/brave.com/research/star-secret-sharing-for-private-threshold-aggregation-reporting/__;!!BClRuOV5cvtbuNI!Caao82RU0ElUlPRqi5DSxHJEYAeBH8O0e7_s0YeuqncqXch1d3_ve4SnKzqWwcPKyVvOhswNyKYAYBKWPqHK$>

On Tue, Nov 14, 2023 at 9:02 PM John, Anil <anil.john@hq.dhs.gov<mailto: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<https://urldefense.us/v3/__https:/disco.xyz__;!!BClRuOV5cvtbuNI!Caao82RU0ElUlPRqi5DSxHJEYAeBH8O0e7_s0YeuqncqXch1d3_ve4SnKzqWwcPKyVvOhswNyKYAYMC7Ni0J$> 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.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.