Re: Splitting "Credential Management"?

-mike

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

> "Without User Mediation"Hi.
>
> On Fri, Mar 17, 2017 at 6:43 PM, Mike West <mkwst@google.com> wrote:
>
>> 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/webappse
>>> c-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 was more concerned about the case navigator.credentials.get({ typeA:
> ..., typeB: ...}), where typeA and typeB are compatible (the website can
> accept either and the UI could also be meaningful) but have a different
> [[Retrieve]] algorithm. E.g. typeA could be passwords and typeB could be a
> next generation way of getting IDP credentials.
>

Right. That's actually the case that we have today with
`PasswordCredential` and `FederatedCredential`. The current sketch handles
this by requiring that credentials that can be requested together also be
defined together in such a way that they share a `[[Retrieve]]` algorithm.
`PasswordCredential` and `FederatedCredential` both alias
`SiteBoundCredential`'s `[[Retrieve]]` algorithm, for example, and it
handles the entire request.

Given the unknown UI requirements of new credential types, it seems to me
that this kind of tight binding is useful. I agree that, longer term, we'll
likely want something more flexible, but it's not clear to me what that
might be.

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.
>>
>
> So if I call navigator.credentials.get({password: true, unmediated:
> false}), you would call [Retrieve]]({password: true, unmediated: true},
> "Without User Mediation")? I was expecting [Retrieve]](true, "Without User
> Mediation"}.
>

Correct. We pass in the whole options object, because it's possible for the
algorithm to handle more than one credential type. As discussed above,
https://w3c.github.io/webappsec-credential-management/sitebound.html#request-credential
does exactly this.

It's not clear to me what a generic merge step might look like. Do you have
>> an idea?
>>
>
> I was thinking of something like:
>
> - Ask all credential interfaces whether they are matching the current
> filter.
>

Ask the interfaces? Or walk through the credential store and examine all
the credential objects?

There's some complexity here, because it seems like more interesting
credential types will have different requirements for UI and
origin-boundness. For phone numbers or SMS or etc, I can imagine you might
want to display a picker even if no explicit `Credential` exists for an
origin?

The "requires user mediation" flag might also need to turn into a set of
credential types for an origin. Handing over a password automatically
certainly doesn't mean that we should hand over phone numbers, for instance.


> - If all matching credentials are "UI compatible" and more than one
> credential matches, show a picker ui.
>

What does "UI compatible" mean? :) That's basically the question that I
intended the "same `[[Retrieve]]` implementation" to answer. Can we make
things more generic than that?

- 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.
>>
>
> My point was that the algorithms in sitebound.html return a single
> credential instead of a list or sequence.
>

Right. But they need a list of credentials from the credential store. That
is, we find X credentials to display in the chooser via the "retrieve a
list of credentials" operation on the credential store, and then hand those
off to the chooser in the `[[Retrieve]]` algorithm.

- 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? :)
>>
>
> Hehe, that aside. I was wondering whether we should treat Passwords and
> Federated credentials separately (as if they were in two different
> documents) to prove the extensibility of the algorithms - i.e. prove that
> you can support different kinds of credentials that can be stored
> simultaneously and selected via a picker UI.
>

Sounds like a reasonable goal. One (bad) idea is to define a Cartesian
product of all known credential types in a registry somewhere, with a "UI
compatible" flag. Can we do better than that?

-mike