Current Limitations

These are things that, althogh we recoginize as problem, we would require modifying the Firefox sources beyond components for Self-Sovereign Individual, or changing the standards. We will appreciate any help to fix them.

TabId is unreliable

With browser.ssi, we use TabId to verify whether the tab app matches with authorization states.
However, browser.ssi must rely on the extension app passing in the TabId to get the tab context, which creates some problems.
One of the problems is that the TabId is not something that cannot be guessed like UUID but just an integer, so it can be faked. For example, an tab app the user requests is working with TabId 1, but third party extension can pass through TabId 2 which is valid for the another tab app. This allows for spoofing and can be a security vulnerability.
Another problem is that it is not possible for browser.ssi to distinguish between events that occur inside the browser and requests from tab apps. This becomes a problem when you want to bypass the authorization API because there is no tab context after catching an event from inside the browser.

This problem is tracked as issue #2.

OS password dialog cannot be independently displayed against multiple credentials in a single call

For Mac and Windows, password authorization is done using the password of the OS account that the user is currently logged in as.
If you queue to independently authorize multiple credentials at once in browser.ssi and try to add different captions to each dialog, subsequent dialogs will be displayed with the information from the first dialog.

This problem is tracked as issue #3.