Re: Coming back to CREDENTIAL.

On Mon, Aug 10, 2015 at 3:01 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> That is one concern, and whether this is solving it is the right way.
>

What would you like to see?


> Another concern I have is whether federation is the only thing a site
> may wish to store in the credentials store. The API is focused around
> credentials, but the real use case seems to be storing something in
> the credentials storage area to survive cookies.
>

Yes... kinda? That's certainly the underlying primitive that's being
exposed, but I think wrapping that primitive in a "credential"-UI and
nomenclature is valuable in terms of helping users understand the risks.

I know there's interest in a more general "durable" and "synced" storage
mechanism. The privacy implications of those kinds of APIs worry me, and
I'm intentionally staying away from them in this document.

(It seems if desired some smuggling of such data can already be done
> through the FederatedCredential object.)
>

I'm not sure it's desirable, but it is certainly possible (with the caveat
that the user would be asked for permission to save credentials for the
site); sites can store a flat string as the ID or name, or a URL with
encoded data as the federation.

-mike