Re: Splitting "Credential Management"?

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