Re: Coming back to CREDENTIAL.

I've taken a stab at this mechanism in
https://github.com/w3c/webappsec/commit/9af0a18577bf8a10d2d9db55134d7b18d77715aa.
WDYT?

-mike

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

On Tue, Sep 15, 2015 at 10:36 AM, Mike West <mkwst@google.com> wrote:

> On Mon, Sep 14, 2015 at 4:50 PM, Dave Longley <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.
>> Suppose:
>>
>> 1. Sue visits `idp.com` and logs in as `sue@home`.
>>
>> 2. `idp.com` calls FederatedCredential.register([protocols]), followed
>> by `navigator.credentials.store(new LocalCredential(...))` for `sue@home
>> `.
>>
>> 3. Later, Sue visits `idp.com` and logs in as `sue@work`.
>>
>> 4. `idp.com` calls FederatedCredential.register([protocols]), followed
>> by `navigator.credentials.store(new LocalCredential(...))` for `sue@work
>> `.
>>
>> 5. Sue visits `rp.com` and `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`? 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
>
>