Re: Coming back to CREDENTIAL.

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