Clarification and discussion regarding flow for signify headers

[lenkan]

Currently, from polaris web https://github.com/WebOfTrust/polaris-web/blob/66ae4932486da12613b800a13f82498dfd063a3e/index.js#L109-L130, I feel we can make some improvements of the user and developer experience when it comes to providing signify headers.

I would like the developer experience to be something like this:

// Web app initiates a request to login. This would be called on clicking a button like "Login with vLEI/Signify".
// This promise resolves when the user has accepted the request, it will reject if the user declines the request.
await requestCredentialLogin({
   schemaId: "ABCD", // SAID of the accepted schema,
   message: "Some informative message from the web app",
   signRequests: ["urls"], // Requests from this origin to these urls will be signed by the extension
})

// Here, the user is "logged in" and the code you write from here on does not need to know how the 
// signing of the request happens. 
// The request will be intercepted by the extension using chrome.webRequest.onBeforeSendHeaders
const response = await fetch("/api/resource"); 

The user experience is something like this:

1. Enter web app
2. Web app sends request to check if logged in, server responds 401
3. User clicks "Login with Signify"
4. User opens extension and reads
5. The site "https://example.com" wants to login with Signify, Accept/Decline
6. User sees success message
7. Web app is in "logged in" state and all requests are now signed by the extension.

Do you have any thoughts on this? I can see in the code that chrome.webRequest.onBeforeSendHeaders is used, but in the manifest it looks like these permissions are not requested.

[rodolfomiranda]

In Chrome and manifest V3, the blocking webRequest intercept feature is no longer allowed. The alternative is to make "synchronous sendMessage calls from the web to the extension providing the externally_connectable permit.

[lenkan]

I see. Thanks @rodolfomiranda for the explanation. I understand now why it is implented like that.

I did not realise it was not longer possible. It is a shame because it would be a nice developer experience I think. FWIW, I saw they recommend using the declarativeNetRequest now, but it does not support dynamically setting headers, you have to pre-declare the headers and values.

[rodolfomiranda]

Exactly. They are moving away for direct blocking actions. although Firefox still support it.
The other method is to used the 'externally_connectable' permission that allow the web page to send a message to the background directly. We are using it in Chrome for the 'auto-signing' requests. Since it's quite a new feature, it has two problems:

• It's not supported by Firefox (discussions in the forums talks about supporting it in the near term)
• in Chrome, the url permission can't be added dynamically as it's possible in other cases. So we had to use the <all_urls> permit that may not pass Chrome Store review

That's was the reason to use the async way of communicating via listeners as first option. We can tight permissions to the main tab and have it available in all browsers.