Re: Splitting "Credential Management"?

Hi Mike,

I think that splitting the API into two is an important exercise to be sure
that the API is extensible as intended.

A few nits:
- 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. I think that it is
not clear yet how |options| are selected to be passed to
[[Retrieve]](options, 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.
-
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
- As discussed some time ago, maybe we should get rid of
SiteBoundCredential and move name and iconURL into PasswordCredential and
FederatedCredential.

WDYT?

I am happy to help with these.

Best regards,
Dominic

On Fri, Mar 17, 2017 at 8:37 AM, Mike West <mkwst@google.com> wrote:

> Hey Daniel! Thanks for your feedback!
>
> On Thu, Mar 16, 2017 at 6:06 PM, Daniel Bates <dabates@apple.com> wrote:
>
>>
>> On Mar 16, 2017, at 6:26 AM, Mike West <mkwst@google.com> wrote:
>>
>> Hey folks!
>>
>> While re-reading through the Credential Management API, I realized that
>> the extension mechanisms aren't at all clear. As a thought exercise, I'm
>> mostly finished with splitting the document into a generic API that defines
>> the high-level architecture (https://w3c.github.io/webapps
>> ec-credential-management/base.html), and a document that specifies
>> `PasswordCredential` and `FederatedCredental` as an extension (
>> https://w3c.github.io/webappsec-credential-management/sitebound.html).
>>
>> WDYT? Is this a sane division? Does it actually make the integration
>> points clearer by forcing us to use them, or is it more confusing than not
>> to have the pieces in distinct documents?
>>
>>
>> Is this split more for organizational purposes as an editor?
>>
>
> I should have been a little more clear about the context: we're working
> with the WebAuthentication group to sketch out what it might look like to
> fold their API into the Credential Management API (https://github.com/w3c/
> webauthn/pull/384). As part of that exercise, I've realized that the
> current CM API document is both too hand-wavey about how the extension
> model actually works, and unclear about the pieces inherent to the generic
> API vs those that are specific to the `PasswordCredential` and
> `FederatedCredential` interfaces.
>
>
>> Without such a hyperlink, if this proposed division existed before my
>> reading of the Credential Management spec then the devision would have
>> hampered my understanding of the concrete use cases of this API as I would
>> need to read a secondary spec to be able to ascertain them or rediscover
>> them.
>>
>
> Yeah, I guess it's an open question at this point whether the API will
> cover passwords/federations and nothing else. If those are the only
> credentials we support, then I agree with you that things are simpler if
> everything is in a single document. If we branch out a bit, then I think
> there's some merit to treating all the credential types as extensions to
> the generic document, rather than "privileging" one set of credential types
> by including them in the document.
>
> You state in sections Extension Points and Browser extensions of <
>> https://w3c.github.io/webappsec-credential-management/base.html> there
>> is a future for just the base Credential Management API outside of usage
>> for passwords and federated credentials, but then leave it largely as an
>> exercise to the reader to imagine such usage. I understand you just split
>> the specs as a step towards expanding these sections. I'm unclear how much
>> we can expand these sections. Is there so much to write about such
>> extensions that would make the spec excessively long so as to warrant
>> separating it into two?
>>
>
> It's quite possible that folks might implement the WebAuthn credential
> type before they implement passwords/federations, for instance. To do so,
> they'd still need to implement the generic API bindings, but the detail
> about passwords/federations might end up confusing that implementation more
> than helping. *shrug* I'm not sure what the right balance is.
>
>
>> How much value is there in just implementing <
>> https://w3c.github.io/webappsec-credential-management/base.html>?
>>
>
> ~zero. The API is just a stub that vends promises that resolve to `null`
> until a concrete credential type is implemented. :)
>
> -mike
>


-- 
Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle