[Discuss] Solution scope

[timcappalli]

Surfaced as a core discussion topic on the first call (2023-10-04).

• Bigger picture of the API: presentation, issuance, web wallet interactions, etc
• help from client for wallet selection, role of UA and platforms, cross-device

[timcappalli]

Support for web-based wallets

@msporny said:
"One common use case that we've supported in the Credentials CG work, and CHAPI (Credential Handler API), for a while now is the ability to invoke web-based wallets to respond to a request. There is a lot of focus on high-assurance use cases these days (government-issued digital identity tied to hardware security keys on mobile phones and app attestations). This raises the bar for what a "digital wallet" is to a degree that is much higher than a number of other use cases in the VC ecosystem (education VCs, pseudonymous age-over assertions, pseudonymous digital coupons, etc.). It is also possible for a web-based wallet to deliver VCs that are signed by HSM-based keys. For these reasons, CHAPI supports the invocation of both web-based digital wallets and native digital wallets (as evidenced by multiple implementations in the latest JFF Plugfest 3).

Whatever this work ends up becoming, there needs to be a consideration for both web-based wallets and native wallets through the same interface."

[marcoscaceres]

Discussion from Payment Handler from Mozilla might be relevant here mozilla/standards-positions#23

Challenges with showing web applications in "trusted UI"...

[msporny]

Challenges with showing web applications in "trusted UI"...

Yes, there are parallels with this work and the W3C WPWG payment handler work.

Note that the current Chrome direction seems like it will invoke a native wallet to do the final credential selection, effectively making that application go full screen. I see no reason why one couldn't do the same for a web-based wallet.

That is -- what is the difference between a full-screen native app doing the selection and finishing the interaction and a full-screen web-based app doing the selection and finishing the interaction?

We have many examples of web-based wallets based on previous interop fests and not including web-based wallets is most likely going to leave a large chunk of the ecosystem behind and thus lead to adoption failure (in the same way some of these decisions have led to adoption failure of payment handler).

There are important "trusted UI" discussions to be had here, but following the path that payment handler took is most likely going to lead to adoption failure again (for a variety of reasons). The ecosystem will just route around this API using window.open() solutions (CHAPI) or QR Codes (OID4) if it doesn't address credential/wallet selection for both web-based and native apps.

[aniltj]

re: Support for web-based wallets

Is the question being asked too narrow? Without getting into the weeds, if the scope of this identity-credential work is to provide for an open and standardized mechanism built into a browser that allows a wallet in the 3 Party (Issuer-Holder-Verifer) model to act as the source of credentials that could be presented to a verifier/website, the design needs to be sufficiently flexible to accommodate a variety of wallet types.

In the work we are doing in this space as both Issuers of high value credentials (U.S. Permanent Resident Card, U.S. Employment Authorization Document, U.S. Certificate of Naturalization etc. by the U.S. Citizenship and Immigration Services and cross-border travel related credentials from U.S. Customs and Border Protection) and as Verifiers (Information stored in wallets that allow for the adjudication of immigration and employment benefits in the US as well as for travel/entry into the US), we are fully expecting and anticipating (and in some cases evaluating) wallets " ... implemented as portable hardware devices, secure web applications, native mobile applications, plug-ins to browsers, extensions to cross-platform password/credential managers, and more".

We are actively paying attention to this work to seek to understand its "open-ness", privacy, security and interoperability implications, to determine if the rails that you are all crafting here can be used to move the credentials we are authoritative for globally, and have a need to verify at web, kiosk, mobile and in-person infrastructure across both the public and private sector.