Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

This is extremely helpful, Anil. Can you provide some perspective on
biometrics?

Some VCs include a biometric and some don't. Is wallet design and
provenance less critical when the VC includes a biometric?

Wallets that are locked by a biometric (as opposed to a passphrase) can be
coercively opened. What are possible mitigations?

- Adrian

On Wed, Mar 23, 2022 at 10:46 AM John, Anil <anil.john@hq.dhs.gov> wrote:

> > But I would like to encourage others who are on this mailing list, who
> did participate in this work to please help in understanding it more.
>
>
>
> The past remains immutable and replaying the grievances or successes from
> the past, without a willingness to listen to first hand accounts (and not
> propaganda) and learn from it, does little to change current reality. I was
> around at that time, and in a role (Running the US Gov’s Trust Framework
> Solutions Program that certified and accredited private sector identity
> services for use by .gov) that gave me front row seat at the game. Don’t
> think that historical knowledge will add any practical benefit to this
> conversation <shrug>
>
>
>
> <break>
>
>
>
> In following the winding roads that this conversation has taken, I wanted
> to put forward some thoughts for consideration to keep it on a productive
> path:
>
>
>
>    - There is a tendency in the Identity community to try to come up with
>    end-to-end approaches instead of trying to put together a mix of approaches
>    that provide a complete solution.
>       - Does it make sense to link the provisioning approach (Issuer – to
>       – Wallet) to the presentation approach (Wallet – to – Verifier / RP) or to
>       address them separately?
>       - Does it make sense to have a consistent provisioning approach for
>       both web and native wallets, and cleanly separate that from how the
>       attributes that are provisioned into the wallet could work with a variety
>       of credential ecosystems that already exist and could exist in the future?
>       Or is that not feasible for some specific, technical reason?
>    - There is also a tendency to silo our thinking within the Identity
>    community (the not invented here syndrome) and ignore work that has been
>    done in other communities that could be applicable to the Identity community
>       - Are there lessons from the payments / EMV Co. standards that
>       could be applied to how we look at wallets and hardware attestations (local
>       secure elements vs remote secure elements (HCE) vs software based storage)
>       that can help us understand the potential threat models and serve as the
>       starting point of what is needed for a “trustworthy” wallet?
>       - How we do strike a balance between “we need a minimum baseline of
>       security / privacy / functionality / ?” and “Achievable only for incredibly
>       well resourced entities who own/control/are resourced for going thru the
>       flaming hoops”? Is levels needed assurance the right filter for this or
>       should it be something else?
>       - Are we thinking strategically about how hardware level
>       attestations, if available broadly and not just from gate-keepers, could *
>       *potentially** remove the need for problematic identity
>       verification techniques?
>
>
>
> I personally believe that the reason that this conversation is happening,
> that it is inflaming passions in some quarters and reactions of “This is
> useless and I want nothing to do with this” in others, is that there is
> finally an acceptance that there is an ecosystem that in the process of
> being matured where the digital wallets are the technical point of
> mediation between issuers and verifiers for individuals, similar to how
> Enterprise’s in the past treated XML Security Gateways and API Gateways for
> Organization – to – Organization interactions.
>
>
>
> And furthermore, there is a concern that while mediation is potentially
> beneficial, it could also be twisted into a point of control at the
> individual level.
>
>
>
> As someone who is not a technology provider, but is looking at this thru
> the eyes of both an Issuer and Verifier and not a Wallet Provider, there is
> a future state for a digital wallet that I am envisioning that needs to
> take into account a variety of things I mention above into consideration.
> This is by no means an abstract discussion for me, so I look forward to
> thoughtful engagement by existing and new informed voices, in helping to
> chart a way thru to a tomorrow that we can all live with.
>
>
>
> 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
>
>
>
> [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]
>
>
>