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

Credential Management: Path to CR?

From: Mike West <mkwst@google.com>
Date: Fri, 27 Oct 2017 15:04:55 +0200
Message-ID: <CAKXHy=eAVLA2k3=0BARuhHagcCBqoPWRB=C72q3wPCY0j7XSJg@mail.gmail.com>
To: public-webappsec@w3.org
Cc: "Hodges, Jeff" <jeff.hodges@paypal.com>, Anthony Nadalin <tonynad@microsoft.com>, jfontana@yubico.com, Angelo Liao <huliao@microsoft.com>, "J.C. Jones" <jc@mozilla.com>, Alexei Czeskis <aczeskis@google.com>
As more TPAC prework, it would be good to think a little bit about what
we're doing with Credential Management.

The current spec <https://w3c.github.io/webappsec-credential-management/>
serves two purposes at the moment: it defines a set of infrastructure APIs
that enable (surprise!) credential management in the browser on the one
hand, and defines a concrete implementation of two specific credential
types that use that infrastructure.

The WebAuthn API <https://w3c.github.io/webauthn/> depends upon Credential
Management in the first sense, as underlying infrastructure, and other
browser vendors are implementing those infrastructure bits and pieces in
order to ship WebAuthn implementations. Thus far, Chrome is the only vendor
that's shipping a concrete implementation of `PasswordCredential` and
`FederatedCredential`; other vendors remain lukewarm in their support.

This dependency raises some questions for the group about how we proceed
with Credential Management. I see two paths:

1.  We polish the current draft, push it to CR, and let it wait there,
aging like a fine wine while it waits for two interoperable implementations
of `PasswordCredential` and `FederatedCredential`. This might take some
time, but it leaves us with a document that is a thing unto itself,
defining an API and a client of that API at the same time.

2.  We revisit the decisions we made in the Splitting "Credential
Management" thread
and break the document in half, defining the infrastructure in one
document, and concrete `Credential` types in another. This has the
advantage of getting a stable document in place for WebAuthn more quickly,
which might be a reasonable thing to do, depending on how (un)willing that
group is to rely on a CR as opposed to a REC.

I have a mild preference for the first path (publishing a polished version
of the document as-is), but I could certainly live with the second path if
it helps WebAuthn along.

WDYT? CCing some WebAuthn folks for opinions.

Received on Friday, 27 October 2017 13:05:39 UTC

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