Re: PR #384 CredMan Integration

Dear list,

I'm all for getting the spec done fast, for getting implementations out
fast, and for making the world a better place faster.  If we want to speed
things up, I'm not convinced that the PR as it is right now is the right
move.  I'm not simply arguing for making fast progress and accepting a
messy API landscape in return.  I'm arguing for not venturing into the
unknown to find the perfect -- in effect passing on the known-good.

I believe that in its current form, the merge will cause questions that
will take a while to iron out.  I would suggest an alternate approach: hold
off on the merge until the proposal does not have as many unknowns.  Maybe
that means waiting until version 2.  It's true that at that point we'll
have gone down different roads with credman and merging might be harder,
but surely worse things have happened.

In my opinion, the big reason to be hesitant about this merge is that it
takes us down the path of one single .makeAuthFactor() and one single
.getAuthFactor() methods.  Where .makeAuthFactor() can result in a
username/password, password, oauth token, url of oauth provider, a public
key of one kind or another.  I'm not convinced that that's the right big
picture approach.  Maybe it is, maybe it isn't -- but going down that path
opens up A LOT of questions, not just about the specs, but about UI/UX as
well.  For example, for usernames and password -- the browser manages
identities and shows the UX for selection.  For authenticators such as
phones, the phone does.  I'm not sure what the right way to show UX is
there.  Maybe it's not a problem for Edge that might just call Hello, but
I'm not sure what cross-operating-system browsers such as FF and Chrome
would do.  Or for example, consider during the create account phase when
acme.com tells the browser that it'll accept a username/password/oauth
token from Google or Facebook or an Authenticator -- what does the browser
draw then?  How does the user choose?  We haven't figured out what it means
to not require user mediation for webauthn, because there are lots of
details.  The relationships between user accounts and passwords is 1:1 --
but that's not the case for users and authenticators.

I can keep going, but the point is that there are questions here -- lots of
them.  It will take a while to iron them out, to play with implementations,
to iterate, to refactor, to make a UX that users understand.  On the other
hand, we pretty much know how to build webauthn in its current form.  It's
self-contained and doesn't depend on any outsides specs.  If I understand
the proposed merge correctly, it also requires that the credential
management API be changed.  So now, before any webauthn api can be put out,
the credential management API must be refactored and only then can webauthn
be developed.  Also, let's not forget that there are websites that depend
on the current credential management API.

Perhaps my English is a bit Russian, but this emails is meant not a
"whimper", but as a well-laid-out, technically-sound argument, worthy of
your serious consideration.  I look forward to your comments and feedback!


The PR is not the only possible credman merge proposal.  Here is another
(if you don't like this one, we've got another):

interface Credential {
 readonly attribute USVString id
<https://www.w3.org/TR/credential-management-1/#dom-credential-id>;
 readonly attribute DOMString type
<https://www.w3.org/TR/credential-management-1/#dom-credential-type>;
};

----------------------------------------------------

interface BearerCredential : Credential
<https://www.w3.org/TR/credential-management-1/#credential> {
 readonly attribute USVString name
<https://www.w3.org/TR/credential-management-1/#dom-siteboundcredential-name>
;
 readonly attribute USVString iconURL
<https://www.w3.org/TR/credential-management-1/#dom-siteboundcredential-iconurl>
;
};

interface PasswordCredential :
<https://www.w3.org/TR/credential-management-1/#siteboundcredential>BearerCredential
{
 attribute USVString idName
<https://www.w3.org/TR/credential-management-1/#dom-passwordcredential-idname>
;
 attribute USVString passwordName
<https://www.w3.org/TR/credential-management-1/#dom-passwordcredential-passwordname>
;

 attribute CredentialBodyType
<https://www.w3.org/TR/credential-management-1/#typedefdef-credentialbodytype>
? additionalData
<https://www.w3.org/TR/credential-management-1/#dom-passwordcredential-additionaldata>
;
};

// similar for FederatedCredential

--------------------------------------------

interface PublicKeyCredential : Credential
<https://www.w3.org/TR/credential-management-1/#credential> {
  readonly attribute object publicKey;
};


interface AuthenticatorResponse {
 readonly attribute PublicKeyCredential credential;
 readonly attribute ArrayBuffer
<https://heycam.github.io/webidl/#idl-ArrayBuffer> clientDataJSON;
};

// note that this is just a renamed ScopedCredentialInfo,
// with the addition of a public key, id, and type in it (as part of the
// credential attribute)
interface MakeCredentialResponse : AuthenticatorResponse {
 readonly attribute ArrayBuffer
<https://heycam.github.io/webidl/#idl-ArrayBuffer> attestationObject;
};

// note that this is just a renamed AuthenticationAssertion
interface AssertionResponse : AuthenticatorResponse {
 readonly attribute ArrayBuffer
<https://heycam.github.io/webidl/#idl-ArrayBuffer>       authenticatorData;
 readonly attribute ArrayBuffer
<https://heycam.github.io/webidl/#idl-ArrayBuffer>       signature;
};

-------------------------------------------

partial interface Navigator
<http://www.w3.org/TR/html5/webappapis.html#navigator> {
 readonly attribute CredentialsContainer
<https://www.w3.org/TR/credential-management-1/#credentialscontainer>
credentials;
};

interface <https://w3c.github.io/html/webappapis.html#navigator>CredentialsContainer
{
 readonly attribute BearerCredentials bearer;
 readonly attribute
<https://w3c.github.io/webauthn/#webauthentication>PublicKeyCredentials
publicKey;
};

interface BearerCredentials {
 Promise<BearerCredential?> get
<https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-get>
(CredentialRequestOptions
<https://www.w3.org/TR/credential-management-1/#dictdef-credentialrequestoptions>
options
<https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-get-options-options>
);
 Promise<BearerCredential>  store
<https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-store>
(BearerCredential credential
<https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-store-credential-credential>
);
 Promise<void> requireUserMediation
<https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-requireusermediation>
();
};

// continue here as in existing CredMan API

------------------------------------------------------------

interface <https://w3c.github.io/webauthn/#webauthentication>PublicKeyCredentials
{
   Promise<MakeCredentialResponse> makeCredential(
                          RelyingPartyUserInfo
<https://w3c.github.io/webauthn/#dictdef-relyingpartyuserinfo>
                accountInformation
<https://w3c.github.io/webauthn/#dom-webauthentication-makecredential-accountinformation-cryptoparameters-attestationchallenge-options-accountinformation>
,
                          sequence<ScopedCredentialParameters
<https://w3c.github.io/webauthn/#dictdef-scopedcredentialparameters>>
cryptoParameters
<https://w3c.github.io/webauthn/#dom-webauthentication-makecredential-accountinformation-cryptoparameters-attestationchallenge-options-cryptoparameters>
,
                          BufferSource
<https://heycam.github.io/webidl/#BufferSource>
attestationChallenge
<https://w3c.github.io/webauthn/#dom-webauthentication-makecredential-accountinformation-cryptoparameters-attestationchallenge-options-attestationchallenge>
,
                          optional ScopedCredentialOptions
<https://w3c.github.io/webauthn/#dictdef-scopedcredentialoptions>
options
<https://w3c.github.io/webauthn/#dom-webauthentication-makecredential-accountinformation-cryptoparameters-attestationchallenge-options-options>
   );


   Promise<AssertionResponse> getAssertion(
                          BufferSource
<https://heycam.github.io/webidl/#BufferSource>
assertionChallenge
<https://w3c.github.io/webauthn/#dom-webauthentication-getassertion-assertionchallenge-options-assertionchallenge>
,
                          optional AssertionOptions
<https://w3c.github.io/webauthn/#dictdef-assertionoptions>       options
<https://w3c.github.io/webauthn/#dom-webauthentication-getassertion-assertionchallenge-options-options>
   );
};

// continue here as in existing Webauthn API
// (note that the naming here treats the key pair as *the credential*, and
the thing
// that is sent over the wire is something else - an authenticator
response, etc.)


--------------------------------------------------------

// Example:  generating and registering a new key follows

var webauthnAPI = navigator.credentials.publicKey;

if (!webauthnAPI) { /* Platform not capable. Handle error. */ }

var userAccountInformation = {
   rpDisplayName: "Acme",
   displayName: "John P. Smith",
   name: "johnpsmith@example.com",
   id: "1098237235409872",
   imageURL: "https://pics.acme.com/00/p/aBjjjpqPb.png"
};

// This Relying Party will accept either an ES256 or RS256 credential, but
// prefers an ES256 credential.
var cryptoParams = [
   {
       type: "publicKey",
       algorithm: "ES256"
   },
   {
       type: "publicKey",
       algorithm: "RS256"
   }
];

var challenge = new TextEncoder().encode("climb a mountain");
var options = { timeout: 60000,  // 1 minute
               excludeList: [],      // No excludeList
               extensions: {"webauthn.location": true}  // Include location
                                                        // information

                                                        // in attestation
};

// Note: The following call will cause the authenticator to display UI.
webauthnAPI.makeCredential(userAccountInformation, cryptoParams,
                          challenge, options)
    .then(function (makeCredentialResponse) {
   // Send make credential response to server for verification and
registration.
}).catch(function (err) {
   // No acceptable authenticator or user refused consent. Handle
appropriately.
});


--------------------------------------------------------

// Example:  authentication without hints

var webauthnAPI = navigator.credentials.publicKey;

if (!webauthnAPI) { /* Platform not capable. Handle error. */ }

challenge: new TextEncoder().encode("climb a mountain"),
var options = {
               timeout: 60000,  // 1 minute
               allowList: [{ type: "publicKey" }]
             };

webauthnAPI.getAssertion(challenge, options).then(function (
assertionResponse) {
   // Send assertion response to server for verification
}).catch(function (err) {
   // No acceptable credential or user refused consent. Handle
appropriately.
});

--------------------------------------------------------

// Example:  authentication with hints

var webauthnAPI = navigator.credentials.publicKey;

if (!webauthnAPI) { /* Platform not capable. Handle error. */ }

var challenge = new TextEncoder().encode("climb a mountain");
var acceptableCredential1 = {
   type: "publicKey",
   id: encoder.encode("!!!!!!!hi there!!!!!!!\n")
};
var acceptableCredential2 = {
   type: "publicKey",
   id: encoder.encode("roses are red, violets are blue\n")
};

var options = {
               timeout: 60000,  // 1 minute
               allowList: [acceptableCredential1, acceptableCredential2];
               extensions: { 'webauthn.txauth.simple':
                  "Wave your hands in the air like you just don’t care" };
             };

webauthnAPI.getAssertion(challenge, options)
   .then(function (assertion) {
   // Send assertion response to server for verification
}).catch(function (err) {
   // No acceptable credential or user refused consent. Handle
appropriately.
});

--------------------------------------------------------
Advantages of this Proposal

   -

   Fewer changes to CredMan & WebAuthn specs

   -

   No need to have a no-op store() operation for PublicKeyCredentials

   -

   No need to reconcile the two notions of user mediation.
   Credentials.bearer uses the requireUserMediation
   <https://www.w3.org/TR/credential-management-1/#dom-credentialscontainer-requireusermediation>
   operation, whereas credentials.publicKey uses a parameter in the
   ScopedCredentialOptions

   -

   The only thing a reader of the webauthn spec has to understand about the
   CredMan spec is the (very simple) Credential interface.

   - New methods like cancel() and promoteAuthenticatorIfAvailable() can
   easily be added to credentials.publicKey without having to worry how they
   interact with other credential types.




Thanks!
-Alexei

*____**_**__**_**_**_**_**_**_**_**_**_*

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 <(317)%20698-4740> .

On Mon, Apr 10, 2017 at 7:14 PM, Anthony Nadalin <tonynad@microsoft.com>
wrote:

> Too nice need to raise a formal objection not whimpers as I can't read
> between the lines
>
> -----Original Message-----
> From: Hodges, Jeff [mailto:jeff.hodges@paypal.com]
> Sent: Monday, April 10, 2017 4:18 PM
> To: public-webauthn@w3.org
> Subject: Re: PR #384 CredMan Integration
>
> On 4/10/17, 2:29 PM, "Anthony Nadalin" <tonynad@microsoft.com> wrote:
>
> > So based upon the discussions that have been going on there seems to
> > be some issues raised on what happens when we merge. I have not heard
> > and real outright objections to the merge,
>
> Dirk made such an outright objection -- but perhaps he said it too nicely
> [0]:
>
>   ..I'm arguing against accepting https://na01.safelinks.protect
> ion.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%
> 2Fwebauthn%2Fpull%2F384&data=02%7C01%7Ctonynad%40microsoft.
> com%7C8fa40e78c673482b7eed08d480681726%7C72f988bf86f141af91a
> b2d7cd011db47%7C1%7C0%7C636274633275960038&sdata=mV1%
> 2FBr337%2B%2BsXPfyFXpid3LgBi6VFtKiig1YUcJe2IQ%3D&reserved=0 as
>   is, because I believe it will create a lot of future work for us that
> will
>   slow us down.
>
> > so in favor of progress I suggest we accept #384 and deal with the
> > questions as they comes up with Mike West, as we see to be just going
> > around and around w/o making a decision.
>
> A more productive approach may be to consider our options in light of the
> desire to have an implementable and nominally usable draft webauthn level 1
> API in the near term.
>
> To me the decision context appears to be:
>
>   What's more important,
>
>     (1) near-term implementable & adoptable/deployable webauthn draft with
> or
>         without credman incorporation, or,
>
>     (2) adding credman dependency now (because it seems we will do it at
> some
>         point regardless), i.e., merge PR#384 as-is, and hope the resultant
>         fixing/polishing does not take "too long" ?
>
> Tony is suggesting (2).
>
> in [0] Dirk is arguing that (2) will result in taking "too long", and
> implies we should do option B plus some renaming.
>
> Though, an option (3) is that we could think things through more
> thoroughly, convince ourselves option C (below) is the correct thing to do
> in light of the other below options, and if it is, revise the PR#384
> appropriately, then merge. One could argue this will take less time that
> just merging #384 as-is.
>
> @mikewest replied to Dirk's points in detail in [3], so we've embarked on
> option (3) if we hold off on merging. This is what I'd vote for.
>
> HTH,
>
> =JeffH
>
>
> details:
>
> Again, the webauthn||credman options [1][2] are:
>
> A. Just Rename (slides 8, 9)
> (as noted in the F2F minutes, this is to just "'rename' scopedCredential"
> such that webauthn (WA) does not use the term 'cedential' in its API)
>
> B. Join credman class hierarchy, keep webauthn methods  (slides 10..14)
>
> C. Join credman (CM) class hierarchy, use CM methods (slides 15..18)
>
> Plus, there is also the status-quo:
>
> D.  Leave credman and webauthn entirely separate for their "level 1" (ie
> initial version) incarnations (leaves door open to address some sort of
> merger in level 2 incarnations).
>
>
> [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-webauthn%
> 2F2017Apr%2F0138.html&data=02%7C01%7Ctonynad%40microsoft.
> com%7C8fa40e78c673482b7eed08d480681726%7C72f988bf86f141af91a
> b2d7cd011db47%7C1%7C0%7C636274633275970046&sdata=PjQcFrH6YKX
> 2D4Uc0mYDJw8THRmIaQ%2FaCepnx1InDWo%3D&reserved=0
>
> [1] WebAuthn vs Credential Management (@balfanz) <
> https://na01.safelinks.protection.outlook.com/?url=https%
> 3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1RyfQS3f-Dk7xU8
> S6pCSBzWl3jGGGrkF1zWkUypVUnik&data=02%7C01%7Ctonynad%40micro
> soft.com%7C8fa40e78c673482b7eed08d480681726%7C72f988bf86f141
> af91ab2d7cd011db47%7C1%7C1%7C636274633275970046&sdata=NCCw7z
> goj6p8R20qbFn%2FP9I8uSwzr3zVSVBs1rFiqtI%3D&reserved=0>
>
> [2] https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Fgithub.com%2Fw3c%2Fwebauthn%2Fpull%2F384%23issu
> ecomment-292734633&data=02%7C01%7Ctonynad%40microsoft.com
> %7C8fa40e78c673482b7eed08d480681726%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C636274633275970046&sdata=33LM5ULKf4s5%2
> BTwRdf6Iq0DWENH5YU6cy%2F5oxiI4i7g%3D&reserved=0
>
> [3] https://na01.safelinks.protection.outlook.com/?url=https%3A%
> 2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-webauthn%
> 2F2017Apr%2F0147.html&data=02%7C01%7Ctonynad%40microsoft.
> com%7C8fa40e78c673482b7eed08d480681726%7C72f988bf86f141af91a
> b2d7cd011db47%7C1%7C0%7C636274633275970046&sdata=9Qi%
> 2FOXTyPnDfj3wHbbvoO%2BhGf1kgyFUFEIEyvvOlQJQ%3D&reserved=0
>
>
>
>
>