Re: Coming back to CREDENTIAL.

On Mon, Sep 7, 2015 at 6:41 PM, Dave Longley <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.


> > Yes, pretty much. I think we'll need to lock down the protocol names in
> > some way (e.g. is "OpenID Connect" the same as "OpenID" and "openid" and
> > "openidconnect" and etc?). Maybe an enum backed by a registry?
>
> I don't know if enums and registries are necessary as they can make it
> harder to experiment. Other specs do just fine with strings (eg:
> WebCrypto uses strings for AlgorithmIdentifier names); I don't think we
> need to make it any more complex than that.
>

The difference here is that both sides of the negotiation need to use the
same names. WebCrypto can get away with strings because the user agent only
supports certain protocols, and will simply do nothing if incorrect
protocol names are used. We don't have that kind of guarantee when both the
RP and IDP are responsible for choosing the same name for the protocol they
both support. 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.

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

-mike