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 11 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 reader public key with their own). 
RByers marked this conversation as resolved.
Show resolved Hide resolved
- 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

... or a web-based wallet, which provide a more seamless experience in many use cases that don't require HSMs, device-lockdown, etc. #33 (comment)

I will also note that there are now governments pointing out the need/desire for web-based wallets/solutions: #33 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, definitely! So you suggest expanding this point (or adding an additional point) to ask about integration with web-based wallets? I know I need to dig into this more, but I haven't gone over the implications too much yet. Does the browser API offer similar advantages over, say, registerProtocolHandler working with web wallets in response to custom scheme navigations?

Copy link
Contributor

@msporny msporny Oct 29, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Yes, definitely! So you suggest expanding this point (or adding an additional point) to ask about integration with web-based wallets?

Yes, please. A separate bullet point would probably be best, something along the lines of:

  • A browser-based API can also potentially provide a low-friction integration between a desktop browser and a website that provides an in-browser wallet experience on the same device.

Does the browser API offer similar advantages over, say, registerProtocolHandler working with web wallets in response to custom scheme navigations?

Yes. We've gone to great lengths in CHAPI to provide wallet selection between both native and web-based wallets in the same UX. Excluding native wallets, or excluding web-based wallets always resulted in gnashing of teeth among the wallet providers that were left out, and at the end of the day, when control is handed over to the wallets, the UX looks/feels very much the same (get consent for the sharing of certain data).

Another thing to consider is requiring/forcing someone to always switch devices between desktop and mobile when using the Web is a pretty annoying UX pattern. You do (arguably) want something like that for high assurance use cases. However, I expect always requiring mobile phone interaction to result in: "I'll do this later", or "Ugh, my phone is upstairs/downstairs/charging" usability issues when a web-based wallet is just as capable and a more convenient experience for most of the common interactions we expect to be associated with the Verifiable Credentials ecosystem (read: not high assurance use cases).

Also keep in mind that mobile devices aren't the only secure ways of signing information -- Web apps + external authenticators exist and should be taken into consideration. We perform all sorts of really high assurance use cases with that tooling (or less capable tooling) available to us today.

Copy link
Member Author

Choose a reason for hiding this comment

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

A browser-based API can also potentially provide a low-friction integration between a desktop browser and a website that provides an in-browser wallet experience on the same device.

Added along with the existing bullet.

Yes. We've gone to great lengths in CHAPI to provide wallet selection between both native and web-based wallets in the same UX. Excluding native wallets, or excluding web-based wallets always resulted in gnashing of teeth among the wallet providers that were left out, and at the end of the day, when control is handed over to the wallets, the UX looks/feels very much the same (get consent for the sharing of certain data).

Thanks, filed #38 to track.

Also keep in mind that mobile devices aren't the only secure ways of signing information -- Web apps + external authenticators exist and should be taken into consideration. We perform all sorts of really high assurance use cases with that tooling (or less capable tooling) available to us today.

Yeah it's a good point. Since that would still need some wallet-defined UI I think that's probably just an extension of the web wallet case, right? A web wallet that happens to use some variant of WebAuthn (whether internal or external authenticator) to provide a strong device-bound assertion?


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

- In general, Android works to keep the list of installed applications private from other applications. However, applications registering to handle custom URL schemes effectively make their package name visible to other applications. By registering to support custom URL schemes, a wallet application may be leaking PII (such as the user's likely citizenship status or state of residency) to any other application 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.