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

> 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

[A picture containing graphical user interface  Description automatically generated]<https://www.dhs.gov/science-and-technology>[/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395]