Auto Signin feature for extended sessions

[HunnySajid]

In Signify browser extension, the credential/aid selection process is a bit different than Nord Vlei extension.

Nord Vlei workflow
By default, nord vlei does not show any credentials but it only renders credentials for selection if there is any outstanding request.

After a request is made from polaris web (and allowed to proceed instead of declined on extension)

Signify Work Flow
In Signify extension, A signin pair is created for every unique origin / domain and selected credential. You can think of it as a signin pair that exists in any password manager such as 1Password.

User is prompted via content script to select any existing pair or select new credential / aid from extension. If they select a new one, a new signin pair is created.

Signify extension has a feature named AUTO SIGNIN. If a selected signin pair has auto signin flag as true then upon selection session is created and subsequent requests are signed. Otherwise, the selected credential is a one-time operation and it does not create a session on extension side. This is to make sure that the users grant permission to sign subsequent requests by turning AUTO SIGNIN flag.

For this to work, credential selection should return the signed headers AuthorizeResult would be changed to something like:

{
"credential": {<details>},
"headers": {<signed-header-details>
}

Because if auto signin was false, no session would be created between webapp and extension so no subsequent requests would be signed. So we need signed-headers right in the response of this call.

@lenkan let us know what do you think or if these are any queries.

[lenkan]

Thanks! We will have a look and get back, but probably not before Tuesday.

cc @daviddm

[rodolfomiranda]

I think that the user need to clearly understand if she's granting the web to sign just one request, or is granting a session of x minutes to sign as many request as the web want without prompting the user.

[lenkan]

I agree. But that is up to the UX of the extension no? It should clearly state what you are authorizing. For example, if extension A is granting a session of X minutes, it should say that.

Maybe this could be customizable in the options object for authorize as well, then it is up to the extension whether or not they implement support for those options. E.g.

await client.authorize({ session: { expireInSeconds: 30000 })

Or

await client.authorize({ session: { maxRequests: 1 })

Or

await client.authorize({ session: { filterRequest: { path:"/foobar"} })

Just brainstorming here.

[rodolfomiranda]

Yes, agree. It's up to the UX extension. Your proposal makes sense, it's a good approach to unified method.

[daviddm]

I'm gonna make a brief explanation of how we've done it @HunnySajid.

• The web app needs to make a sign-in request, this request will have to manually be granted in the extension each time.
• After a successful sign-in the web app can request as many signed headers as it wants as long as the extensions session storage is the same. It will force a new manual grant if you refresh the page or visit it at a later time.
• If the web app wants to do any other operation, there is a manual approval step for each operation.

Our thought is that if you have signed in to any web app, the web app should be able to request signed headers until you revoke the grant(logout). So by doing it this way we don't have to send signed headers in the response when signing in.

My thinking is that the request for credentials(the sign-in request) should only return the credentials. And if we want to limit signed headers request down the line, that we should do it with some other mechanism.

I do not think we should return the signed headers in the authorize request. It is ultimately up to the implementation of the extension whether or not that also allows signed header requests.

So my understanding is that the 'auto sign-in' functionality and our default behaviour are very close in end-user result?
Does that make sense?

[rodolfomiranda]

I think it's possible to detach the authorize from the sign headers. We had them in the reply method because the initial use case of the extension was to receive just a single sign header that can be submitted to a backend as an authentication mechanism (like passkey)