Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add custom schemes alternative analysis #37

Merged
merged 14 commits into from
Nov 1, 2023
Merged

Add custom schemes alternative analysis #37

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
c43afa7
Add custom schemes alternative analysis
RByers Oct 29, 2023
baa2478
Add CHAPI reference
RByers Oct 29, 2023
319c858
Update custom-schemes.md
RByers Oct 31, 2023
e237c28
Update custom-schemes.md
RByers Oct 31, 2023
c09a841
Update custom-schemes.md
RByers Oct 31, 2023
eb7d49f
Update README.md
RByers Oct 31, 2023
8dd9991
Update README.md
RByers Oct 31, 2023
8d0dcbb
Update custom-schemes.md
RByers Oct 31, 2023
e391bd2
Update custom-schemes.md
RByers Oct 31, 2023
e81e549
Update custom-schemes.md
RByers Oct 31, 2023
df763fe
Update custom-schemes.md
RByers Oct 31, 2023
15e95f2
custom-schemes: Mention web wallets
RByers Oct 31, 2023
fcc80ae
custom-schemes: expand on android privacy
RByers Nov 1, 2023
6baddda
Update custom-schemes.md
RByers Nov 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,13 +1,18 @@
# Proposals related to identity credentials

This repo is being used to work on, and hopefully converge, proposals
related to identity credentials on the web:
This repo is being used to work on, and hopefully converge on, proposals
related to the invocation of digital identity wallets from the web:

* [Identity Credential](identity-credential-proposal.md)
* [Digital Credential](digital-credential-proposal.md)
* [navigator.identity.get()](navigator-identity-proposal.md)
* [Mobile Document Request API](mobile-document-request-api-proposal.md)

## Alternatives being developed elsewhere

* Analysis of [custom URL schemes](custom-schemes.md)
* [CHAPI](https://chapi.io/) - a browser [API](https://dbpedia.org/resource/API) ([API spec](https://w3c-ccg.github.io/credential-handler-api/)) and [polyfill](https://dbpedia.org/resource/Polyfill_(programming)) ([polyfill spec](https://github.com/credential-handler/credential-handler-polyfill)) focusing on wallet selection (rather than credential selection) and enabling both storage and presentation of credentials from both native and web wallets.

RByers marked this conversation as resolved.
Show resolved Hide resolved
# Related meetings / resources

## Meetings
Expand Down
41 changes: 41 additions & 0 deletions custom-schemes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Concerns with custom schemes for identity presentment

Existing specifications like [OpenID4VP](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-wallet-invocation) and [ISO 18013-7](https://www.iso.org/standard/82772.html) currently define the use of custom URL schemes (eg. `openid4vp:` and `mdoc:`) to enable verifier websites to invoke holder (wallet) applications. This approach works in some scenarios, but has a number of problems we aim to solve by designing a browser API which can replace the use of custom URL schemes in these specifications. This DRAFT document aims to outline the questions and concerns with the use of custom URL schemes for identity presentment in order to provide more detail on potential benefits of a dedicated browser API.

1. Can wallets reliably determine their invoker?

- Android and iOS offer no facility to determine the web origin which triggered a navigation to a custom URL scheme. 
- This seems to increase the opportunity for attacks such as replay attacks, man-in-the-middle attacks and phishing. It also seems to limit the opportunity for abuse detection and prevention.
Comment on lines +5 to +8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

android and iOS might not allow it, but that's why protocols like OID4VP/18013-7 talk about client_id_schemes and verifier authentication which allows the wallet to reliably determine the invoker.

- A browser API can securely pass the requesting origin on to the wallet so that the wallet can know with confidence what origin the user was on when the request was initiated.
RByers marked this conversation as resolved.
Show resolved Hide resolved

2. Can wallets limit requests to secure contexts?

- If a user uses a website via http (not https) and it invokes a custom scheme, it's possible that an attacker with access to the network could eavesdrop on or even modify the request (such as by replacing the verifier's public key with their own). 
- A browser API could take the position that it will function only within the context of a secure context (https).

3. What is the user experience when multiple wallet apps are installed?

- When multiple Android applications register for the same custom URL scheme, the operating system presents the user with a picker every time that scheme is invoked. Even if the verifier provides the user with appropriate context, a user may have trouble remembering which application has which credentials and so be more likely to cancel or fail the request.
- On iOS, when multiple applications are installed that register for the same custom URL scheme, the behavior is [undefined](https://stackoverflow.com/questions/13130442/multiple-apps-with-the-same-url-scheme-ios). At present, one indeterminate wallet will be invoked without any indication that other wallets were available.

4. What is the user experience when no wallet app is installed or when the user cancels wallet invocation?

- Browsers generally silently ignore navigation to URL schemes with no handler installed. This likely means a website cannot distinguish between nothing happening while waiting for a wallet to process a request and nothing happening because no wallet app is installed. 
- Additionally browsers on Android and iOS often offer the user the choice of whether or not to invoke an application for a custom URL scheme navigation (even if there is only one such app). The user canceling at this stage is also indistinguishable from no valid application being installed.
- A browser-based API could show the user some meaningful error message when no relevant wallets are installed.
RByers marked this conversation as resolved.
Show resolved Hide resolved

5. What is the user experience on a desktop operating system?

- Most wallet applications exist only as mobile applications, and users are generally reluctant if not unable (due to enterprise security settings, for instance) to install native applications on desktop operating systems. What fallback will flows relying on custom URL schemes provide for users of desktop operating systems?
- A browser-based API can potentially provide low-friction integration between a desktop browser and a wallet application running on a mobile phone or a website that provides an in-browser wallet experience on the same device.

6. What are the privacy implications of a wallet accepting custom schemes?

- [Android aims](https://developer.android.com/training/package-visibility) to keep the list of installed applications private from other applications, but this capability is reduced for applications which handle arbitrary intents like custom URL schemes. By registering to support custom URL schemes, a wallet application may effectively be leaking PII (such as the user's likely citizenship status or state of residency) to other applications on the device.
- A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Converting one of my comments into a suggestion here:

Suggested change
- A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage.
- A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage.
- A browser API could potentially keep private (from the relying verifier or issuer) the specific wallet the user selects to complete a request. This may be impossible or challenging when using other mechanisms (e.g., a custom URL scheme that includes an invitation to use a protocol that requires a wallet to directly communicate with the relying verifier or issuer).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was wondering about saying something like that, but I didn't see how it would be materially different. Both setups involve some arbitrary data transfer protocol from the wallet back to the verifier. That protocol could be designed to either rely on wallet keys (or other form of wallet identification) or not, right? Direct communication isn't, I don't think, any more or less identifiable (just like web servers can't necessarily identify a browser unless the browser advertises itself somehow either directly or indirectly via it's precise behavior).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was wondering about saying something like that, but I didn't see how it would be materially different. Both setups involve some arbitrary data transfer protocol from the wallet back to the verifier. That protocol could be designed to either rely on wallet keys (or other form of wallet identification) or not, right? Direct communication isn't, I don't think, any more or less identifiable (just like web servers can't necessarily identify a browser unless the browser advertises itself somehow either directly or indirectly via it's precise behavior).

Yeah, I think that's right, but I was thinking about this less from the perspective of different protocol designers that equally consider this privacy characteristic -- and more from the perspective of wallet providers that are looking to implement existing protocols on offer.

I think there's an advantage to say that a browser API could provide this sort of privacy "by default", simply because of the architectural pattern that places the browser as a mediator between the RP and the wallet. Other protocols on offer that lack this architecture, especially those that do not consider this sort of privacy in their design, may incidentally have elements that make it an active challenge to try to provide it.

Some of this has come up before with protocols that require direct communication from Web wallet backend services because RPs are not CORS-enabled, leading, perhaps, to more easily identifying the wallet services chosen by the user -- or more challenges to wallet providers to help avoid this. These kinds of concerns and challenges can potentially be avoided entirely by wallet providers based on a browser-as-mediator architecture.

But I take the point that other protocols can attempt to build in this sort of privacy as well if they want to.


7. How can users be assured that they have control over where their personal information is shared?

- A buggy or poorly designed wallet application may store or transmit sensitive information about the user (such as which website(s) the user was visiting and when) without necessarily ensuring the user has provided informed consent. Malicious websites may exploit bugs in wallets to cause them to leak information without requiring any consent from the user. Wallets and credentials may come from any source, but users will expect their operating systems and browsers to protect their privacy from buggy or malicious wallet applications.

Due to these concerns, Google Chrome has [proposed](https://groups.google.com/a/chromium.org/g/blink-dev/c/wcCrcMTELS0/m/ZSPxAT0LAgAJ) blocking website access to specific high-risk custom URL schemes, and instead invoking wallets via a browser-mediated API. Anyone interested in contributing to the design of such an API is encouraged to join the W3C's [Web Incubator Community Group](https://www.w3.org/community/wicg/) and contribute to the [Identity Credential proposal](https://github.com/WICG/identity-credential/). While websites will likely always be able to communicate directly with wallet applications in some fashion, it is the group's hope that a browser-based API can be designed which is a better option for wallets and verifiers, and which also provides users with confidence in having their sensitive identity information potentially exposed to websites they visit.