Re: Splitting "Credential Management"?

Thoughts on the new merged version at https://w3c.github.io/webap
psec-credential-management/:

1) I'd like to start coming up with terms to distinguish "concept 1", the
thing you possess that gives you the right to do something, say, log in as
User X; and "concept 2", the proof that you have that thing. We're going to
need this for full federated credentials, SMS auth, and WebAuthn. Some
options: "credential"/"credential proof", "credential"/"attestation",
"credential generator"/"credential", "identity"/"credential". I lean toward
the first pair and will use those here, but I'm happy to take anything that
avoids conflating them.
  a) Does store() merely record that a particular CredentialProof worked
for a site, or does it save a whole Credential? The first is consistent
with the current behavior for "federated", and would imply that a WebAuthn
CredentialProof could be stored too. If the second, we'd change store()'s
parameter to be Credential, and passwords might be the only valid argument.

2) Nit: It's odd to have both NoInterfaceObject and Exposed=Window on
CredentialUserData.

3) Nit:
https://w3c.github.io/webappsec-credential-management/#construct-federatedcredential-data
has a title of "The PasswordCredental ...".

4) I think we'll need the UA to store a notion of:
  a) Which credentials successfully log into which identities for a given
site. Call these "known" credentials. An "identity" is just the content
of CredentialUserData.
  b) Which credentials have been used successfully since the most recent
requireUserMediation(). Call these the "active" credentials?

  When get() is called with options that match exactly one "active"
credential, the UA should try to get a proof for that credential, whether
it's a password, a federated identity, or a WebAuthn authenticator. Some of
these will do their own mediation, but the UA shouldn't show an extra
chooser. This is where a .cancel() operation
<https://github.com/w3c/webauthn/issues/380> would be useful.

  When get() is called with options that match zero or >=2 active
credentials, the UA may need to show a chooser. It should prioritize active
credentials over known credentials over unknown credentials, but it needs
to let the user select an unknown credential. In some cases, the get()
options might narrow down the set of credentials so that the UA can call a
single OS API to do the operation (e.g. "publicKey" with no active
credentials). In that case, the UA should still tell the OS to insist on
some sort of mediation.

  SMS and email auth might be interesting cases here: users might want one
of them to be the active credential, but still want to confirm receiving an
SMS or email. I guess we could treat that as the credential type doing its
own mediation?

5) The credential store's different pieces might have different lifetimes:
  a) Passwords and UA-stored private keys need to survive "clear browsing
data", and so they need more user approval to be stored.
  b) Knowledge that the user has a removable WebAuthn authenticator or has
used SMS auth with a particular site can be cleared with a site's cookies,
and so maybe doesn't need any user approval to be stored.

HTH,
Jeffrey


On Fri, Mar 17, 2017 at 7:40 PM, Jeffrey Yasskin <jyasskin@google.com>
wrote:

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