Re: Splitting "Credential Management"?

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


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


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

My concern was about a future type of credentials that could be integrated
that are not part of the current algorithm/spec. Let's say in the future
you can log in with your phone number and storing phone numbers is not part
of https://w3c.github.io/webappsec-credential-management/sitebound.html
<https://w3c.github.io/webappsec-credential-management/sitebound.html#request-credential>
.


> 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.
- If all matching credentials are "UI compatible" and more than one
credential matches, show a picker ui.


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


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

Best regards,
Dominic


>
> -mike
>