Re: Coming back to CREDENTIAL.

On 09/08/2015 03:50 AM, Mike West wrote:
> On Mon, Sep 7, 2015 at 6:41 PM, Dave Longley <dlongley@digitalbazaar.com
> <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     > Perhaps a static method on `FederatedCredential`
>     > (`FederatedCredential::registerAsProvider()`?) would be better from a
>     > conceptual standpoint.
>
>     Or maybe two credentials should be stored at the IdP, one
>     PasswordCredential and one that conceptually performs the registration
>     as an IdP.
>
>
> 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.

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`?

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

It seems to me that any sort of federated login should work in a similar 
fashion, which tells me that there's some required level of integration 
between registration, the credential used at the IdP to perform 
authentication, and the ability to choose that credential based on a 
relying party's query.

> I'd like to avoid IDPs registering
> `openid connect` and `openid` and `openidconnect`, but I think they'd
> have to if we allow RPs to choose their own protocol names.

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.

>
>     >     9. IDP.com calls `navigator.credentials.transmit({ Bob's selection })`.
>     > ...
>     > Step 9 in particular needs to be worked out, but
>     > I'm quite explicitly punting that discussion to v2 in this document. :)
>
>     I'm not sure if punting here is a good idea. It certainly should be
>     noted in the document, somewhere, that an important part of any flow
>     that needs to get user input from another site will need a way to
>     "complete the flow" and hand control back/notify the original calling
>     script.
>
>
> The "Future Work" section does allude to these kinds of flows, and the
> structure of the API makes it clear that the site is going to have to
> deal with waiting for asynchronous events. What else would you like the
> spec to say in this regard?
>
>     My concern with punting on this is that we're missing a key
>     component required for extensibility that involves third party sites.
>
>
> My concern with not punting is that this functionality isn't required
> for anything that's currently specified, so it would have no normative
> value. As written, the spec doesn't limit the behaviors which may be
> required for these kinds of cross-origin operations. Extensions will be
> free to do whatever makes sense for their specific needs. You could
> imagine this as an explicit JavaScript operation, you could also imagine
> the user agent offering an internal redirection endpoint which triggered
> some behavior, or something else entirely. Either way, that's the job of
> the extension, not this spec.
>
> Broadly, we've designed a nicely asynchronous, Promise-based system in
> the explicit hope of leaving these kinds of doors open. If you think
> that we've inadvertently closed off some extension opportunities, I'm
> happy to reevaluate. If those opportunities remain open, then I'd prefer
> to leave them open rather than locking in a design for something we
> haven't put enough though into yet.

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


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

Received on Monday, 14 September 2015 14:50:49 UTC