Forward Declared Storage Access API proposal #524
Conversation
| - Considering prior user decisions for access requests. | ||
| - Disallowing repeated access prompts. | ||
| - Auto-approving access (without a prompt) if the browser has sufficient signals about a positive relationship, such as a high site-engagement score. | ||
| - Change Chromium's default behavior. |
There was a problem hiding this comment.
Both Goals and Non-Goals feel like they're from the existing SAA proposal? :)
There was a problem hiding this comment.
Yep, although goals should likely reflect the desire to handle this particular use pattern specifically. We're not looking to mess with existing SAA meaning or heuristics, just calling patterns.
| - https://github.com/privacycg/storage-access/issues/83 | ||
|
|
||
| ## Usage | ||
| If a website will redirect to an identity provider, with the knowledge that is will later load that identity provider as third-party content that requires access to its first-party storage, the Forward Declared Storage Access API provides a mechanism for the identity provider to request that access while it is accessed in a first-party context. Both the website and the IDP must call an API to unblock this scenario. |
There was a problem hiding this comment.
| If a website will redirect to an identity provider, with the knowledge that is will later load that identity provider as third-party content that requires access to its first-party storage, the Forward Declared Storage Access API provides a mechanism for the identity provider to request that access while it is accessed in a first-party context. Both the website and the IDP must call an API to unblock this scenario. | |
| If a website will redirect to an identity provider, with the knowledge that it will later load that identity provider as third-party content that requires access to its first-party storage, the Forward Declared Storage Access API provides a mechanism for the identity provider to request that access while it is accessed in a first-party context. Both the website and the IDP must call an API to unblock this scenario. |
| }; | ||
| ``` | ||
|
|
||
| #### document.allowStorageAccessOnSite(Url) |
There was a problem hiding this comment.
I think this should be called allowStorageAccessRequestOnSite or something like that, since we only want to allow the request.
Coming up with precise but concise names for these is hard :|
| var redirectUri = new URL(params.get("redirect_uri")); | ||
|
|
||
| if(document.hasStorageAccessForSite(redirectUri.origin)){ | ||
| return; // No need to prompt. |
There was a problem hiding this comment.
Doesn't this return prevent the redirect below? :)
| } | ||
|
|
||
| document.requestStorageAccessForSite(redirectUri.origin); | ||
| window.location.href = redirectUri + authenticationParameters; |
There was a problem hiding this comment.
I think that this call to requestStorageAccessForSite would need to await a successful resolution before performing the redirect
There was a problem hiding this comment.
Yeah, I'm not fully sure if it does return a promise or not. Non modal doesn't seem to work here, so a promise that resolves per storage access/60 is maybe best option?
| - Immediately prior to the redirect, example.site will indicate that it expects federatedid.site to request Storage Access, by calling document.allowStorageAccessOnSite("federatedid.site") | ||
| - After the user authenticates at federatedid.site, federatedid.site will request Storage Access for later, when it is embedded within example.site, by calling document.requestStorageAccessForSite("example.site") | ||
| - The user will observe the prompt, and either accept or reject the prompt. No promise is provided to federatedid.site to detect how the user has answered. | ||
| - If federatedid.site does not immediately redirect to example.site, after showing the prompt, the permission will not be granted between the two sites. |
There was a problem hiding this comment.
We need to define "immediately" here or drop this requirement
There was a problem hiding this comment.
Browser defined with a general expectation of five seconds?
Co-authored-by: Lorenz Nickel <[email protected]>
Co-authored-by: Lorenz Nickel <[email protected]>
Co-authored-by: Lorenz Nickel <[email protected]>
Co-authored-by: Lorenz Nickel <[email protected]>
|
Update from @erik-anderson: there's still ongoing discussion about this. Will see about reviewing and potentially landing this PR. |
@Brandr0id for initial review, then Firefox/WebKit folks and Identity folks.