Re: Coming back to CREDENTIAL.

On 09/22/2015 08:20 AM, Mike West wrote:
> I've taken a stab at this mechanism in
> https://github.com/w3c/webappsec/commit/9af0a18577bf8a10d2d9db55134d7b18d77715aa.
> WDYT?

That works for me. Thanks, Mike.

>
> -mike
>
> --
> Mike West <mkwst@google.com <mailto: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.)
>
> On Tue, Sep 15, 2015 at 10:36 AM, Mike West <mkwst@google.com
> <mailto:mkwst@google.com>> wrote:
>
>     On Mon, Sep 14, 2015 at 4:50 PM, Dave Longley
>     <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
>
>             I think that binding the registration to the type of
>             credential for
>             which the registration is relevant seems pretty reasonable.
>             Since the
>             protocol attribute we're talking about is a
>             `FederatedCredential`
>             concept, I'd suggest that it ought to be controlled via
>             something tied
>             to `FederatedCredential`. Introducing a new credential type
>             that would
>             be stored alongside a `LocalCredential` doesn't really match
>             my mental
>             model; that is, we're not storing a new credential, we're
>             recording the
>             fact that this origin may be offered as a synthetic
>             `FederatedCredential` when signing into a separate origin.
>
>             Some method hanging off of the `FederatedCredential`
>             prototype seems
>             like a reasonable way of making that claim.
>
>
>         Hmm, I'm worried that the outcome of that design may not be very
>         "user centric". If I try to log into a website using federated
>         login, I'd prefer to see a list of my identities come up in an
>         account chooser vs. a list of services. Would there be proper
>         integration/linking between `LocalCredentials` stored for my IdP
>         and registration values to allow me to make selections like
>         that? It seems like the model needs to link these things more
>         tightly.
>
>
>     In the current model, each origin (potentially) has
>     `PasswordCredential` and `FederatedCredential` objects that
>     represent an account on that origin. That is, `https://example.com/`
>     <https://example.com/> might have a `PasswordCredential` containing
>     ("mikewest", "hunter2"), and a `FederatedCredential` containing
>     ("not mikewest", "https://facebook.com/"). The latter denotes that I
>     wish to use Facebook to sign into `https://example.com/`
>     <https://example.com/>, but doesn't require that I store anything at
>     all for the `https://facebook.com/` <https://facebook.com/> origin.
>
>     What I'm suggesting is that `https://example.com/`
>     <https://example.com/> could also have a mechanism by which it
>     declares itself to be an IDP which supports the "foobar" protocol.
>     That in itself is _not_ a credential, but a property of the origin,
>     which I think might be reasonably modeled as a static method on
>     `FederatedCredential`.
>
>     That property can be used by the algorithm in
>     https://w3c.github.io/webappsec/specs/credentialmanagement/#synthesis to
>     offer a user the ability to sign into
>     `https://some-other-origin.com/` <https://some-other-origin.com/> as
>     follows:
>
>     1. `https://some-other-origin.com/` <https://some-other-origin.com/>
>     asks for a credential, and specifies support for the "foobar"
>     protocol (e.g. `navigator.credentials.get({ 'federated': {
>     'protocols': [ 'foobar' ] } });`).
>
>     2. The user agent looks around, and doesn't find any credentials for
>     `https://some-other-origin.com/` <https://some-other-origin.com/>
>     directly. So it branches out, and looks for IDPs which support "foobar".
>
>     3. Hey, look at that! `https://example.com/` <https://example.com/>
>     supports this exciting protocol! The user agent synthesizes two
>     `FederatedCredential` objects for `https://some-other-origin.com/`
>     <https://some-other-origin.com/>, containing ("mikewest",
>     "https://example.com/") and ("not mikewest", "https://example.com/").
>
>     4. The user is offered the two synthesized credentials as possibilities.
>
>         I'm imagining scenarios where I have two or more accounts at
>         idp.com <http://idp.com>. Suppose:
>
>         1. Sue visits `idp.com <http://idp.com>` and logs in as `sue@home`.
>
>         2. `idp.com <http://idp.com>` calls
>         FederatedCredential.register([protocols]), followed by
>         `navigator.credentials.store(new LocalCredential(...))` for
>         `sue@home`.
>
>         3. Later, Sue visits `idp.com <http://idp.com>` and logs in as
>         `sue@work`.
>
>         4. `idp.com <http://idp.com>` calls
>         FederatedCredential.register([protocols]), followed by
>         `navigator.credentials.store(new LocalCredential(...))` for
>         `sue@work`.
>
>         5. Sue visits `rp.com <http://rp.com>` and `rp.com
>         <http://rp.com>` asks for federated login and the browser
>         displays some kind of credential selection UI.
>
>         What does Sue see? Does she see a list of services with `idp.com
>         <http://idp.com>`? Or does she see `sue@home` and `sue@work`?
>
>
>     Up to the user agent, but I'd suggest that the latter is pretty
>     reasonable.
>
>         In the Credentials CG work, we're aiming for a very "user
>         centric" system. As part of that, we'd like IdPs to register an
>         `IdentityCredential`, and then, whenever you visit another site,
>         that site can ask for an `IdentityCredential` which you are then
>         able to choose in a list. (We also want to allow you to pick and
>         choose the attributes to send along with that identity
>         credential, but that's not germane to this particular issue, I
>         don't think).
>
>
>     You would almost certainly want to define your `IdentityCredential`,
>     and implement a similar registration method. The more I think about
>     it, the more tightly I see this as being bound to a credential type.
>     You wouldn't want to reuse Facebook's IDP registration for
>     `IdentityCredential` requests... the registrations should be separate.
>
>         That's a reasonable concern. I just want to make sure that
>         experimentation with new protocols isn't going to be hampered in
>         any way.
>
>
>     Happily, JavaScript has terrible type checking, so it would be tough
>     to stop this kind of experimentation even if we really wanted to. :)
>
>         Understood. However, the spec currently gives some direction on
>         writing extensions that gives the impression that it should be
>         as simple as extending the `FederatedCredential` interface with
>         new properties with declarative-style information. Clearly more
>         will be required for some extensions.
>
>         Therefore, I think the Future Work section should also make some
>         mention of this need following the "The natural way to expose
>         this information..." For example, another sentence could be
>         added to the effect of:
>
>         "It is expected that some extensions, particularly those reliant
>         upon third party interactions, will have requirements that can't
>         be met via declarative extension points. This specification
>         attempts to leave room for them to define specific control flow
>         mechanisms on top of the existing asynchronous, Promise-based
>         system."
>
>
>     https://github.com/w3c/webappsec/commit/0c20d113ca22a42bd01c26d2bdc0f2a1cbb58112
>     work for you?
>
>     -mike
>
>


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Tuesday, 22 September 2015 13:40:29 UTC