Re: Splitting "Credential Management"?

3 thoughts here:

1) I strongly approve of you using the extension points to define the
initial credential types. Without doing this, it'd be hard for an extender
to use the extension points as you intended, even if you managed to get
them right. I think it's less important to put the initial extensions in a
separate document, although doing so does force you to figure out how
future extensions will be registered.

2) I think it's clearer to make the registry explicit, instead of using
"Let credential interfaces be the set of interfaces whose inherited
interfaces contain Credential." (
https://w3c.github.io/webappsec-credential-management/base.html#abstract-opdef-request-a-credential)
to reach out over all specs for possible branch targets. In Permissions, I
put the registry inside the spec, but as you said on #whatwg, that's not
compatible with the W3C's REC process. I'd still vote for an explicit
registry of credential types *somewhere* that this spec can link to, if
only in a Note.

3) [Maybe not related to this factoring] I don't see anywhere in the spec
that says what the result of get() "means".
https://w3c.github.io/webappsec-credential-management/base.html#user-mediated-selection
implies that a successful call "share[s] credential information" with the
site and that the credential is "provided to the website". I think that's
too tailored to the password case. Instead, can we think of get() providing
proof to the site that the UA has a credential? For a password, the current
proof is to provide the password itself, but we could imagine an HMAC
instead to prove possession without giving away the credential. For
WebAuthn, the result of get() is clearly a proof and not the credential
itself.

Jeffrey

On Thu, 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?
>
> CCing some specific folks who might be interested.
>
> -mike
>