Weekly Sync - 16 July 2024

[github-actions[bot]]

Please add agenda items below and give your weekly update in a comment. Thank you!

Agenda

• Request: An interactive grant flow to pair public/private keys (the goal) @sidvishnoi

Discussion:

@sidvishnoi raised an issue concerning the user experience in the process of sharing public keys between the user's browser extension and their wallet. The main problem is that the current method requires users to manually copy and paste their public key from the extension into their wallet, which is not user-friendly.

Context on the current problem:

• The web monetization extension is a client, it acts on the user's behalf. As such, it needs a private/public key pair so that it can authenticate itself (prove it is who it says it is).
• Public keys need to be bound to a URL (usually a wallet address). However, the extension is just a piece of software running in the browser and it doesn't have a URL to link its public key to.
• The proposed solution is to tie that public key to the user's wallet address (which is a URL). That way the extension can make Open Payments requests using your wallet address.
• Now we have a chicken-and-egg problem. The extension can generate a key pair, but requires a way to securely register that key with the wallet. Usually, we secure communications using that key, which it hasn't registered yet.
• Note: The key is used to prove who the client is. The client signs its requests with a private key and registers its public key in a public key registry. Then anyone can decode a message sent by that client using its public key. If they can decode it successfully, then it must have been signed by that specific private key, so you know the message was sent by the client linked to that public key in the registry. Therefore, it is important that the client is correctly linked to its public key and that no bad actor impersonates a client by registering as that client with its own public key. If this were to happen, an unintended client could have access to a user's account.
• @adrianhopebailie: The issue is that we have three parties here:
  1. The user
  2. The browser (extension)
  3. The wallet.
• All entities need to be addressed together to make this secure. The user wants to tell the wallet to trust the browser. We need the browser extension talking to the wallet. This communication channel would require a browser API that doesn't exist. So we can't get around that. We can't use API calls directly to the browser to make sure it's trusted.
• Our current solution is to split this problem into two phases and have a manual step in between:
  • The extension generates a key pair and shows the public key to the user (here the user can trust the extension because it is in their browser and they initiated this process).
  • The user then copies that key, logs into their account, and pastes that public key as a key registered with the same wallet address that was given to the extension. The ASE can trust the user because the user logged in. Then the trusted user can hand over the key they trust securely, but this is a clumsy solution.
• When a user installs the extension for the first time, they see the public key, which they must copy and paste into their wallet to link the key and enable the extension to act on their behalf.

The problem with our current solution:

• Users don't like having a copy/paste step.
• Users find the public key terminology confusing.
• Users don't know where to go in their account to paste this key or which wallet address to link it to.

@sidvishnoi proposed a solution:

• A new button labeled "Connect Keys" (or something similar) can be added to the extension interface.
• When the user clicks this button, the extension will automatically handle the key addition process.
• The key addition process should still occur only upon user interaction to maintain security and user control. The goal is to reduce the amount of user interaction required, making the process more user-friendly.
• The idea is to create an interactive grant flow to add the public key to a wallet address.
• Create a new dependency API call similar to the Outgoing Payments grant, which allows for copying or collecting the key.
• The API should accept the public key and provide an interactive redirect similar to the outgoing payment grant.
• It was assumed this would be possible since GNAP does not require clients to already be authenticated before making their first request to an AS.

Problems with this proposed solution:

• Ultimately this still has security vulnerabilities. At the end of the day the ASE cannot be sure that the correct extension sent the request to register their public key. A bad actor could, at the same time, send a similar request, including their own public key, and we risk the user giving consent because they are also carrying out a legitimate key registration request at the same time.

Proposed alternative solutions:

• We can't just use an Interledger key pair because of the problems with sharing the keys.
• @mkurapov raised the idea of allowing vetted clients to sign requests with an Interledger hosted key.
• @JoblersTune played with the idea of the extension requesting its own wallet address from the wallet provider, automating key registration and linking securely. But this would be very convoluted if possible at all. Not viable.
• @sabineschaller suggested using an Interledger-hosted key registry.
• @AlexLakatos says we should explore locking down a specific API for web monetization for the extension. @adrianhopebailie likes the idea of API for web monetization since it also informs the wallet about the type of transactions that will be taking place.
• OTP based interfaces (a mechanism people already understand)
• @adrianhopebailie suggested simplified instructions and UX design: Instead of asking users to copy a public key we could call it a secret or a code instead. Also we could make the ASE redirect open at the specific wallet address that is being linked to this public key. Also idea of being able to drag and drop the public key instead of copy pasting. @BlairCurrey raises the problem that we're now dictating how wallets implement their user faces.
• @sidvishnoi suggested mitigating the problems of his original proposal by including a nounce to safeguard against CSRF attacks and session hijacking. He also proposed using key phrases.

@matdehaast pointed out that there needs to be a normative approach for handling key registration across different wallet providers, especially for applications that cannot host keys, like mobile apps. This is not a problem unique to web monetization. This would involve standardizing the process and interfaces required for key management, ensuring consistency and security across different platforms. By developing a specification that wallet providers can implement, the ecosystem can provide a unified and secure method for key registration, reducing variability and potential security gaps.

@AlexLakatos raises the problem that the people in this call aren't the target audience and so we are not experts on the UX needs of our audience.

The conclusion is that this requires further discussion.

[BlairCurrey]

• added ilp_pay_time_ms histogram metrics and grafana visualizations
• opened pr to refactor telemetry service interface to make it easy on the caller (handling conversion, hardcoding the source, etc.)

[njlie]

• Catching up from time off on Local Telemetry updates
• Opened PR to check if a grant has sufficient access rights for a request during token introspection

[JoblersTune]

Almost done on adding additional telemetry metrics (tracking number of prepare, fulfill, and reject packets).
Created a new Grafana dashboard to display these metrics.