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

On Wed, Nov 15, 2023 at 10:00 AM John, Anil <anil.john@hq.dhs.gov> wrote:

> 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, 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).
>
>
Aren't you precluding guardianship with this requirement?

--------------
Alan Karp


On Wed, Nov 15, 2023 at 10:00 AM John, Anil <anil.john@hq.dhs.gov> wrote:

> 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>
> *Sent:* Tuesday, November 14, 2023 7:16 PM
> *To:* John, Anil <anil.john@hq.dhs.gov>
> *Cc:* W3C Credentials Community Group <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> 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.
>
>