Re: Coming back to CREDENTIAL.

On Mon, Aug 10, 2015 at 3:09 PM, Mike West <mkwst@google.com> wrote:
> 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?

Well, e.g., I've been wondering if folding this into autocomplete
could work. It already has a bunch of things that enable automation of
identity creation. We could add some more stuff to make federation
simpler.


>> 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.

It's not entirely clear to me the federation abstraction works if the
browser cannot even guarantee to the user that the UI is actually
about a federation and not some other type of tracking data. Having
said that, the same probably goes for form autofilling to some extent.


-- 
https://annevankesteren.nl/

Received on Monday, 10 August 2015 13:29:35 UTC