W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2017

Re: Splitting "Credential Management"?

From: Dominic Battre <battre@google.com>
Date: Fri, 17 Mar 2017 21:49:36 +0100
Message-ID: <CAFa1-K2Tbp4ezURPT1Exzk6uHYwQfGiL9Wi43jRdjx8ceETXaA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Daniel Bates <dabates@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Václav Brožek <vabr@google.com>, Angelo Liao <huliao@microsoft.com>, Peter Dolanjski <pdolanjski@mozilla.com>
"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

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

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

> -mike
Received on Friday, 17 March 2017 20:50:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC