Re: [credential management] Cross-origin credentials (was: Identity Credentials API Extension)

This is an interesting thread, and I think Brad's categorizations of
credential types is illuminating, as is Adrian's discussion of the
status quo. I'm dropping the line-by-line here, so I'm sure I'll miss
some important points (I hope this doesn't mean I'm setting up
strawmen; if something I've left out seems particularly relevant,
please do point it out to me).

It seems natural to me that the credential management API we're in the
process of defining, whatever we choose to call it, will grow to
support the kinds of flows that Adrian is pointing to. I think we
differ a bit on some details, but the general use-case of streamlining
authentication via IdPs is a valuable one. I hope it's been clear from
the beginning that my eventual goal is to offer some kind of
platform-level support for this kind of flow; it's explicit in the use
case document[1], and implicit in the proposal itself[2].

The `FederatedCredential` in the proposal is a first step towards that
platform-level support, with the goal of providing the user agent with
some valuable bits of missing context. As Adrian notes, authentication
via an IdP is implemented as an opaque series of redirects and form
submissions. User agents don't understand it in the same way they
understand passwords, and that makes life difficult for users, both
when signing in to old friends, and when signing up for new
experiences.

Adrian asked "What value does this API add beyond what is already
possible using cookies to remember the federated identity provider
that a user has used in the past?"[3]: one answer is that users clear
their cookies quite often indeed: ~13% of Chrome users who have opted
into sharing usage statistics cleared their cookies in the past
_week_. I suspect that number is higher among users who didn't decide
to share statistics with Google. Relying on cookies as a stable
identifier is, for better or worse, not enough, and Brad's note that a
user agent has the ability to retain authentication information in a
store orthogonal to cookies is on-point[4].

Another answer is that we can reduce the cognitive overhead of IdPs by
mitigating the necessity of a "Nascar" approach to authentication;
since the user agent is in the privileged position of understanding
your habits, it can filter IdPs an RP claims to support in order to
help a user make a reasonable choice (and to help the user remember
her choice next time around). These filters can both remove IdPs with
which a user has no relationship, and expose relationships the user
might not be aware she has (implicit OpenID endpoints, to borrow from
Adrian's example).

The "baby steps" API in the proposal enable these advantages, even if
they don't remove all the complexity of SDKs and redirects from the
server-side. The proposal only proposes "baby steps" because, in part,
of the kinds of complexities that server-side interactions pose both
to providers and user agents. Brad's discussion of this (at the bottom
of point #3 in [4]) is a good example of these considerations; we're
nowhere near addressing them, nor is it a conversation we've really
started.

One thing that's interesting to note about these kinds of
authentication workflows is that they're "cross-origin" only at the
macro level. The kinds of flows I know I want to support support are
same-origin at the micro-level, as each request contains ephemeral
authentication information scoped to the origin to which the request
is made.

That is, when authenticating to Exuberant Example via Fantastic
Federation Inc., a user has an EE cookie that's sent along with
request to EE.com and an FF cookie that's sent along with requests to
FF.com. In the background, those two entities have exchanged a token
which allows EE.com to make requests to FF.com on a user's behalf, and
which allows EE.com to tie the EE.com cookie to FF.com in some
(potentially opaque, origin-scoped, revokable, etc) way[*]. Paving
these existing cowpaths of IdP-based authentication seems like
something that's worth investing time in, and I think we can do so in
ways that encourage accepted best practice (locking things down to
secure contexts, for instance).

I'm less enthusiastic about models in which one or more of these
properties doesn't hold. My take on the proposal Manu, et al have put
forward is that it relies upon non-deniable, non-ephemeral, and
transferable assertions made on the basis of persistent key pairs
which are shared with multiple origins (potentially in plaintext). I
fully admit that I don't have a great depth of knowledge on the
trade-offs that lead to that design, but it isn't one that I find
initially appealing.

-mike

[1]: https://w3c.github.io/webappsec/usecases/credentialmanagement/#federated-identity-provider0
[2]: https://w3c.github.io/webappsec/specs/credentialmanagement/#future-work
[3]: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0147.html
[4]: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0149.html
[*]: Squinting a bit, FIDO has similar properties, in that a device of
some sort can make unique assertions to each origin a user authorizes,
without broadcasting a singular identifier across origins. Perhaps
folks who know more about FIDO than I might have additional insight or
suggestions here.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Monday, 1 June 2015 15:14:19 UTC