Thank you @johnwilander for pointing us at the work of this group.
Our motivating use case is:
The user is logged in to Image Publisher with domain name image-publisher.example and is now visiting viewer.example, which allows users to view images from multiple image publishers using the accounts they have with those publishers. The user taps/clicks on a link to an image from image-publisher.example in order to view it at full resolution, which requires authenticated access via cookies. The onclick event handler in the viewer.example application calls the Storage Access API to request cookie access needed to authenticate the user cross-site to image-publisher.example. The user has not used viewer.example before and thus gets prompted to allow or disallow storage access, decides to allow storage access, and the browser retrieves the full image from image-publisher.example, rendered to the user via an <img> tag (or <canvas>, or similar) in the viewer.example page.
This use case is further described in this 3 minute read.
Differences from current storage-access use cases
In current storage-access use cases, the publisher's code (in an iframe) is asking permission for the browser to send cookies to it (the publisher); whereas here the application page is asking permission for the browser to send cookies to the publisher. The application doesn't need access to the cookies, just that they be sent to the publisher to establish the identity of the user.
API
(staying as closely as possible to the existing example but acknowledging that it might be a different API)
Here the code belongs to the viewing application; the document is the viewer itself, rather than an embedded iframe from the publisher.
var promise = document.hasStorageAccess("publisher.example");
promise.then(
function (hasAccess) {
showImage();
},
function (reason) {
// now we know the browser isn't going to send cookies even if it has them
var promise = document.requestStorageAccess("publisher.example");
promise.then(
function () {
showImage();
},
function () {
// Storage access was denied.
}
);
}
);
function showImage(){
// Here's where we might establish whether the user is logged in to publisher.example
// and if not, send them over there first, before trying this:
theImage.src = "https://publisher.example/image.jpg";
// (and react to this failing, if it fails)
}
Thank you @johnwilander for pointing us at the work of this group.
Our motivating use case is:
The user is logged in to Image Publisher with domain name
image-publisher.exampleand is now visitingviewer.example, which allows users to view images from multiple image publishers using the accounts they have with those publishers. The user taps/clicks on a link to an image fromimage-publisher.examplein order to view it at full resolution, which requires authenticated access via cookies. The onclick event handler in theviewer.exampleapplication calls the Storage Access API to request cookie access needed to authenticate the user cross-site toimage-publisher.example. The user has not usedviewer.examplebefore and thus gets prompted to allow or disallow storage access, decides to allow storage access, and the browser retrieves the full image from image-publisher.example, rendered to the user via an<img>tag (or<canvas>, or similar) in the viewer.example page.This use case is further described in this 3 minute read.
Differences from current storage-access use cases
In current storage-access use cases, the publisher's code (in an iframe) is asking permission for the browser to send cookies to it (the publisher); whereas here the application page is asking permission for the browser to send cookies to the publisher. The application doesn't need access to the cookies, just that they be sent to the publisher to establish the identity of the user.
API
(staying as closely as possible to the existing example but acknowledging that it might be a different API)
Here the code belongs to the viewing application; the
documentis the viewer itself, rather than an embedded iframe from the publisher.