Re: Splitting "Credential Management"?

Thanks for your comments, Dominic!

On Fri, Mar 17, 2017 at 6:27 PM, Dominic Battre <battre@google.com> wrote:

> - I think that https://w3c.github.io/webappsec-credential-
> management/base.html#algorithm-request is not fully done. Imagine that
> you request navigator.get({"password": true, "federated": ...}). In this
> case, retriever is set twice (for password and federated - in arbitrary
> order) but executed only once.
>

It's set twice only if it's the same (in which case the second set is a
no-op). We could certainly skip the set in the latter case, but that seems
just as expensive as setting it. Perhaps more so, from a textual
perspective.


> I think that it is not clear yet how |options| are selected to be passed
> to [[Retrieve]](options, mediation).
>

|options| is passed into the "Request a `Credential`" algorithm as an
argument, and then fed to `[[Retrieve]]` in step 11.


> - I wonder whether we should define some merge step where multiple
> different types of credentials can be requested and the browser needs to
> present the user which one to pick. I wonder, whether for this purpose we
> should also have two separate algorithms for passwords and federated
> credentials.
>

The current setup addresses this by assuming that credentials that can be
selected together share a `[[Retrieve]]` internal method (e.g.
`PasswordCredential` and `FederatedCredential` alias
`SiteBoundCredential`'s implementation).

It's not clear to me what a generic merge step might look like. Do you have
an idea?


> - https://w3c.github.io/webappsec-credential-
> management/base.html#abstract-opdef-credential-store-
> retrieve-a-list-of-credentials states "This accepts an arbitrary filter,
> and returns a Sequence<Credential> of those credentials that match the
> filter." but returning a sequence of credentials is not reflected in
> https://w3c.github.io/webappsec-credential-management/sitebound.html
>

Hrm. Yeah, I guess `sequence<Credential>` might be too IDL-bound for the
algorithm. A `list` might be more accurate. Step 4 of
https://w3c.github.io/webappsec-credential-management/sitebound.html#request-credential
assumes that it's getting a list back, for example.

- As discussed some time ago, maybe we should get rid of
> SiteBoundCredential and move name and iconURL into PasswordCredential and
> FederatedCredential.
>

`SiteBoundCredential` is pretty convenient as a container for the
`[[Request]]` and `[[Store]]` methods that `PasswordCredential` and
`FederatedCredential` alias.

That said, we could achieve the same effect by defining a single algorithm
and aliasing it in both interface objects. I wouldn't be terribly sad if we
got rid of `SiteBoundCredential` entirely... but then what do we name the
document? :)

-mike