Strawman of an integration between WebAuthn and Credential Management. #384

mikewest · 2017-03-16T12:29:37Z

@battre: I took a different tack in this patch, leveraging most of the work you've already done.

The main distinction between what we talked about yesterday and what I ended up with here is the value of the ScopedCredential's id parameter. I no longer agree with myself from yesterday; it doesn't make much sense to treat this as the Account's ID. I think we should keep the existing relationship between the credential's ID and the "credential identifier" that the authenticator produces. I've just stored that ArrayBuffer as an internal property, and turned the id getter into a base64url encoded version of that buffer.

Also note that this set of patches focuses on getAssertion(), but doesn't make much change to makeCredential() (other than the rename). I'd still like to turn that into a dictionary, but this is already a big patch, so...

WDYT?

…ertionResponse.

This is a temporary step to get rid of WebAuthentication, and pave the way to move to 'get()' in the next patch.

In order to align with CredentialsContainer::get(), merge the challenge into 'AssertionOptions' and rename 'AssertionOptions' to 'ScopedCredentialRequestOptions'.

This relies on some things that aren't official yet, in particular the [[Retrieve]](options, mediation) internal method defined at https://w3c.github.io/webappsec-credential-management/base.html#dom-credential-retrieve-slot. But I think it all works. :)

mikewest · 2017-03-16T12:57:53Z

Whoops! I meant to make this a PR against @battre's fork of this repo, as there are still some open issues to work out. Ah well. :(

So, hello, webauthn! This is a slightly-more-fleshed-out strawman than we discussed on the call last week, but the broad strokes are the same.

equalsJeffH · 2017-03-16T19:08:00Z

see also:

Splitting "Credential Management"? (Mike West)
https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0016.html

https://w3c.github.io/webappsec-credential-management/base.html

https://w3c.github.io/webappsec-credential-management/sitebound.html

vijaybh · 2017-03-16T16:42:52Z

index.bs

@@ -92,8 +89,11 @@ is [=Registration=], where a [=scoped credential=] is created on an [=authentica
 with the present user's account (the account may already exist or may be created at this time). The second is
 [=Authentication=], where the [=[RP]=] is presented with an <em>[=Authentication Assertion=]</em> proving the presence
 and consent of the user who registered the [=scoped credential=]. Functionally, the [=Web Authentication API=] comprises
-two methods (along with associated data structures): {{makeCredential()}} and {{getAssertion()}}. The former is used
-during [=Registration=] and the latter during [=Authentication=].
+a {{ScopedCredential}} which extends the Credential Management API, and infrastructure which allows those credentials to be


Nit: Should add a normative reference link to the CM API.

Added in b1e87ca.

vijaybh · 2017-03-16T16:48:03Z

index.bs

@@ -186,8 +186,7 @@ below and in [[#index-defined-elsewhere]].

 : HTML
 :: The concepts of [=relevant settings object=], [=origin=],
-    [=opaque origin=], [=is a registrable domain suffix of or is equal to=], and the {{Navigator}} interface are
-    defined in [[!HTML52]].
+    [=opaque origin=], [=is a registrable domain suffix of or is equal to=].


Nit: missed the ending of the sentence.

Fixed in b1e87ca

vijaybh · 2017-03-16T16:55:57Z

index.bs

+    ::  This method allows a developer to request the User Agent to create a new credential, and persist it to the underlying
+        platform, which may involve data storage managed by the browser or the OS. The user agent will prompt the user to
+        approve this operation. On success, the promise will be resolved with a {{ScopedCredential}} which contains an
+        {{AuthenticatorAttestationResponse}} object. Implementation details are found in [#createCredential].


Nit: missing one set of brackets around #createCredential

Fixed in b1e87ca.

vijaybh · 2017-03-16T17:06:28Z

index.bs


 <xmp class="idl">
    [SecureContext]
-    interface WebAuthentication {
-        Promise<ScopedCredentialInfo> makeCredential(
+    interface ScopedCredential : Credential {


Does this mean that ScopedCredential implements Transferable as well? If so, do we need to define a structured clone algorithm for it? If not, is CM API going to drop the requirement around implementing Transferable?

hm, https://w3c.github.io/webappsec-credential-management/base.html seems to have dropped "Transferable"

fyi/fwiw, part of our webauthn's rationale for not declaring "transferable" is that making credentials transferable means that they can be postMessage'd to another origin (as we understand it) and that seemed to violate our security & privacy requirements.

Transferable basically means that when the object is postMessaged, it doesn't copy the data, but moves it out of your window. We don't need that behavior for any of the current credential types, and if y'all don't need it either, then I'm happy to drop Transferable from the CM spec.

That said, there's nothing stopping a malicious developer from copying or serializing the ScopedCredential object and using postMessage() to transfer that data to a different window. What's the threat you'd like to defend against?

Thanks @equalsJeffH, I had been reading the ED which differs from the base.html version.

*cough* To make things more confusing (but hopefully less confusing in the long term!), I've now folded those two documents back into https://w3c.github.io/webappsec-credential-management/. :)

vijaybh · 2017-03-16T18:06:39Z

index.bs


-## <dfn interface>WebAuthentication</dfn> Interface ## {#iface-credential}
+The {{ScopedCredential}} interface inherits from {{Credential}} [[!CREDENTIAL-MANAGEMENT-1]], and contains the attributes that
+are returned to the caller when a new credential is created, or a new assertion is requested.


We should probably add some text here about what a ScopedCredential object actually represents. One of the challenges I had when reading this was keeping in mind that "credential" as used in this spec is not the same as "Credential" which is the base interface of the same name. AIUI we a page might have multiple ScopedCredential objects representing a single "credential" on an underlying authenticator. Can we find better words to overcome this semantic confusion?

This is less of an issue with password credentials, because every copy of a password is a valid credential. But in the WebAuthn case this is more salient because there is only a single thing underlying all these objects, and the objects are essentially invalidated if I, for example, pull my USB authenticator out of the port.

I agree that there's a lot of prose that needs rethinking. This PR really only concentrates on the mechanics right now, and one explicit goal is to work through y'all's thoughts on the confusing bits that remain unaddressed. :)

vijaybh · 2017-03-16T21:20:19Z

index.bs

+    :   <dfn method>\[[Retrieve]](options, mediation)</dfn>
+    ::  The {{ScopedCredential}} [=interface object=] defines this internal method to override {{Credential}}'s implementation,
+        which will enable support for assertion generation through {{CredentialsContainer/get()}}. Implementation details are
+        found in [[#getAssertion]].


Perhaps it's my lack of knowledge of WebIDL, but I have many questions about this.

How does this actually show up in the author's code? We're saying here that a method in an internal slot of the ScopedCredential object overrides a method of the CredentialsContainer interface. Does this then constitute a monkey patch on section 4.1.1 of Credentials Management? Maybe this should be broken out of here and into a real extension point?

How does this actually show up in the author's code?

It doesn't. The [[...]] syntax is what the ECMAScript spec uses for internal properties... slots and methods that exist on an object for explanation purposes, but don't have IDL bindings).

We're saying here that a method in an internal slot of the ScopedCredential object overrides a method of the CredentialsContainer interface.

No, sorry for the confusion: here, we're overriding Credential's implementation of [[Retreive]]. [[Retrieve]] is used by CredentialsContainer/get(), but isn't monkeying around with CredentialsContainer's implementation. I'll walk through the new flow below:

Does this then constitute a monkey patch on section 4.1.1 of Credentials Management?

In https://w3c.github.io/webappsec-credential-management/base.html, I'm fiddling around with how get() is wired up to specific kinds of credential objects. The existing document is pretty hand-wavey about how it knows that get({ 'password': true }) is a request that operates on PasswordCredential objects. That new document attempts to be a little more rigorous. I'll try to spell it out briefly here:

All Credential interface objects have an internal (e.g. not exposed to the web) implementation of [[Retrieve]](options, mediation) (https://w3c.github.io/webappsec-credential-management/base.html#credential-internal-methods).

During get(), we walk through all the interface objects that derive from Credential directly or indirectly (step 5.1 of https://w3c.github.io/webappsec-credential-management/base.html#abstract-opdef-request-a-credential), and examine their [[type]] slot's value. If that value is the same as one of the keys in the dictionary that we passed into get(), then we'll grab the interface object's [[Retrieve]] method.

If, after walking through all such objects, we've only gotten one [[Retrieve]] method, then we'll execute it and return the resulting Credential to the developer.

If we got more than one hit (e.g. the developer passed in { 'password': true, 'scoped': { ... } }), then we'll error out.

It might be easier to explain this on a call. It's a bit convoluted, but I do think it's more clearly explained than the last attempt, at least from a mechanical perspective of what the browser would actually do. :)

vijaybh · 2017-03-16T21:24:56Z

index.bs

+
+    :   <dfn method>create(accountInformation, cryptoParameters, attestationChallenge, options)</dfn>
+    ::  This method allows a developer to request the User Agent to create a new credential, and persist it to the underlying
+        platform, which may involve data storage managed by the browser or the OS. The user agent will prompt the user to


Re: "persist it to the underlying platform..." - I think it would be more accurate and consistent to say "persist it to an authenticator" which may be an external device or built into the client. I think referring to "data storage" is misleading in either case as it implies general-purpose data stores.

I borrowed this text from the current section 4.1.1: https://w3c.github.io/webauthn/#makeCredential. I'm happy to change it to something more accurate, though! I'll do that in a distinct patch.

Changed in b1e87ca. The bit about prompting might also be something to address, as it's not clear to me whether that's actually a requirement imposed by this spec.

vijaybh · 2017-03-16T21:31:38Z

I have to run now, so I just published a half-done review. I will go through the rest of the PR later (likely this weekend) but please feel free to respond to these comments now if you'd like.

mikewest · 2017-03-17T05:30:32Z

I appreciate you taking a look, @vijaybh. I've answered your comments inline, and I'll clean up the nits you've noted later today. Good eye!

battre · 2017-03-17T16:39:47Z

index.bs

 extension identifier, and the value MUST be the [=client argument=].

 <pre class="example" highlight="js">
-    var assertionPromise = credentials.getAssertion(..., /* extensions */ {
-        "webauthnExample_foobar": 42
+    var assertionPromise = navigator.credentials.get({


nit: navigator.credentials.get({"scoped": {

also below...

Taken care of in c48c70b.

jyasskin · 2017-03-21T21:14:21Z

index.bs

+        data contained in the object's {{ScopedCredential/[[identifier]]}} slot.
+
+    :   {{ScopedCredential/rawID}}
+    ::  This attribute returns the {{ArrayBuffer}} contained in the {{ScopedCredential/[[identifier]]}} internal slot.


Note that ArrayBuffers are mutable, so folks will be able to change the value of that internal slot. Web Bluetooth invented a "read only ArrayBuffer" variant to handle this, but I don't think we've implemented the read-only aspect yet.

This is equally a concern in the status quo API, right? readonly attribute doesn't prevent the contents of the ArrayBuffer stored in ScopedCredential/id from being modified.

If we need that kind of guarantee, then we probably need to chat with folks like @tobie, @bzbarsky, and @domenic about WebIDL and ECMAScript bindings.

Does ES even let you freeze Typed Arrays?

Typed arrays are "Integer Indexed Exotic Objects". Per https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects that means their integer-named properties are writable and non-configurable, so you can't make them non-writable.

But that's a red herring anyway, because you can just create a new typed array of your own using the same backing arraybuffer.

If you actually perform a set on a typed array, you end up in https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects-set-p-v-receiver and thence in https://tc39.github.io/ecma262/#sec-integerindexedelementset which will do some validation and call https://tc39.github.io/ecma262/#sec-setvalueinbuffer

There are no provisions for readonlyness of arraybuffers and therefore no provisions for readonlyness of typed arrays. The bluetooth spec is basically unimplementable as written.

Oh, and adding such provisions is likely to cause prohibitive performance regressions for code that uses typed arrays. Which means JS engine implementors will push back very hard on attempts to add something like this. They have before.

The right way to expose binary data that you don't want mutated is to expose a copy.

I agree with @bzbarsky. I'm also not sure I understand why it's necessary to freeze these buffers in the first place, as they're all already munged copies of things passed into other methods. I haven't looked at the bluetooth usage, but it's not clear to me why you need read-onlyness there either. shrug

If a user mutates the ArrayBuffer returned by rawId, does that change the value returned by id? If so (which is what the spec implies to me right now), then cred.id !== cred.id. If not, does the result of id reflect the initial value of [[identifier]] or the value at the point where id was first retrieved? I think we wind up needing to store both values eagerly and separately.

If a user mutates the ArrayBuffer returned by rawId, does that change the value returned by id? If so (which is what the spec implies to me right now), then cred.id !== cred.id.

That's how things are written now, yes. That seems reasonable, given that the ID would indeed change if the underlying data changed. If that seems untenable, then we could make rawID return a copy of the underlying buffer. That seems expensive, but maybe it's worthwhile?

A simpler alternative would be to drop the internal slot entirely, and just store the base64url encoded data. It isn't actually clear to me from our various conversations whether the raw buffer is necessary. I only introduced rawID to maintain some portion of the status quo while migrating over to derive from Credential.

I think dropping the internal slot makes sense here. It's also not clear to me if we need to keep the ArrayBuffer version.

jyasskin · 2017-03-21T21:23:14Z

index.bs

+        2.  Let |value| be a new {{ScopedCredential}} associated with |global| whose fields are:
+
+            :   {{ScopedCredential/[[identifier]]}}
+            ::  A new {{ArrayBuffer}} containing the bytes of the credential ID returned from the successful


Keep the "created using |global|'s [=%ArrayBuffer%=]" phrase.

Thanks! Fixed in fedcced.

jyasskin · 2017-03-21T21:24:37Z

index.bs


-## Information about Scoped Credential (interface <dfn interface>ScopedCredentialInfo</dfn>) ## {#iface-credentialInfo}
+The {{AuthenticatorResponse}} interface and its derieved interfaces represent the data 


I think you're missing the end of a sentence here.

Thanks! Fixed in fedcced.

jyasskin · 2017-03-21T21:25:04Z

index.bs

+<dl dfn-for="AuthenticatorResponse">
+    :   <dfn attribute>clientDataJSON</dfn>
+    ::  This attribute contains a representation of the data sent from the client to the authenticator in order to generate
+        a given response. The {{AuthenticatorAttestationResponse}} and {{AuthenticatorAssertionResponse}} 


Another truncated sentence here.

Thanks! Fixed in fedcced.

mikewest

I spent this morning merging in the changes from #397, #398, and #399, and addressing @equalsJeffH's feedback. I need to take another pass to make sure that the state we've ended up in is sane, but it would be helpful if other folks skimmed the result as well, as those three patches introduced a lot of churn. :)

mikewest · 2017-04-18T09:37:52Z

index.bs

+        data contained in the object's {{ScopedCredential/[[identifier]]}} slot.
+
+    :   {{ScopedCredential/rawID}}
+    ::  This attribute returns the {{ArrayBuffer}} contained in the {{ScopedCredential/[[identifier]]}} internal slot.


If a user mutates the ArrayBuffer returned by rawId, does that change the value returned by id? If so (which is what the spec implies to me right now), then cred.id !== cred.id.

That's how things are written now, yes. That seems reasonable, given that the ID would indeed change if the underlying data changed. If that seems untenable, then we could make rawID return a copy of the underlying buffer. That seems expensive, but maybe it's worthwhile?

A simpler alternative would be to drop the internal slot entirely, and just store the base64url encoded data. It isn't actually clear to me from our various conversations whether the raw buffer is necessary. I only introduced rawID to maintain some portion of the status quo while migrating over to derive from Credential.

mikewest · 2017-04-18T09:38:48Z

index.bs

+        {{CredentialsContainer/get()}}, and this attribute's value will be an {{AuthenticatorAssertionResponse}}.
+
+    :   <dfn>\[[type]]</dfn>
+    ::  The {{ScopedCredential}} [=interface object=]'s {{Credential/[[type]]}} slot's value is the string "`scoped`".


It seems implied, but I'm happy to imply less if it's helpful.

mikewest · 2017-04-18T09:53:20Z

index.bs

@@ -651,8 +716,8 @@ When this method is invoked, the user agent MUST execute the following algorithm

    1. [=set/Append=] |authenticator| to |issuedRequests|.

-1. Let |promise| be [=a new Promise=]. Return |promise| and start a timer for |adjustedTimeout| milliseconds. Then execute the
-    following steps [=in parallel=]. The [=task source=] for these [=tasks=] is the [=dom manipulation task source=].
+1. Start a timer for |adjustedTimeout| milliseconds. Then execute the following steps [=in parallel=]. The [=task source=] for


create(), above, directly implements an IDL API, so it returns a promise directly. In this section, on the other hand, we're implementing a function called by https://w3c.github.io/webappsec-credential-management/#algorithm-request. We don't need to manage the promise bits, we return a result to our caller, and our caller uses that result to resolve the promise.

(Note that create() will move to a similar model once w3c/webappsec-credential-management#72 lands)

mikewest · 2017-04-18T09:54:43Z

index.bs

    </dd>
    </dl>

-1. [=Reject=] |promise| with a {{DOMException}} whose name is "{{NotAllowedError}}".
+1. Return a {{DOMException}} whose name is "{{NotAllowedError}}".


See the explanation above.

mikewest · 2017-04-18T09:55:45Z

index.bs

-## Information about Scoped Credential (interface <dfn interface>ScopedCredentialInfo</dfn>) ## {#iface-credentialInfo}
+The {{AuthenticatorResponse}} interface represents the data returned from an [=authenticator=] in response to a client's
+request. This base interface contains common attributes for all response types, while derived interfaces like
+{{AuthenticatorAttestationResponse}} and {{AuthenticatorAssertionResponse}} add attribute specific to a particular kind


Skipping these comments, as we reworded/reworked this section in #397.

mikewest · 2017-04-18T10:31:14Z

index.bs

@@ -806,8 +914,7 @@ authorizing an authenticator with which to complete the operation.
        complete. This is treated as a hint, and may be overridden by the platform.

    - The <dfn>rpId</dfn> parameter explicitly specifies the RP ID that the credential should be associated with. If it is
-        omitted, the RP ID will be set to the [=origin=] specified by the {{WebAuthentication}} object's [=relevant settings
-        object=].
+        omitted, the RP ID will be set to the [=environment settings object/origin=] specified by the [=current settings object=].


(Fixed in #397)

mikewest · 2017-04-18T10:32:33Z

index.bs


    - The optional <dfn>timeout</dfn> parameter specifies a time, in milliseconds, that the caller is willing to wait for the
        call to complete. This is treated as a hint, and may be overridden by the platform.

    - The optional <dfn>rpId</dfn> parameter specifies the rpId claimed by the caller. If it is omitted, it will be assumed to
-        be equal to the [=origin=] specified by the {{WebAuthentication}} object's [=relevant settings object=].
+        be equal to the [=environment settings object/origin=] specified by the [=current settings object=].


Fixed in #397.

domenic · 2017-04-18T13:51:14Z

Drive-by comment: it should be rawId, not rawID: https://w3ctag.github.io/design-principles/#casing-rules

AngeloKai · 2017-04-18T19:12:51Z

I looked through the PR and haven't found problem with it.

equalsJeffH · 2017-04-18T20:29:08Z

index.bs

-    object's [=relevant settings object=]. This default can be overridden by the caller subject to certain restrictions, as
-    specified in [[#makeCredential]] and [[#getAssertion]].
+    them. By default, the RP ID for a WebAuthn operation is set to the [=environment settings object/origin=] specified by the
+    [=current settings object=]. This default can be overridden by the caller subject to certain restrictions, as


wrt [=current settings object=] -- given the language a ways below of:

Let |callerOrigin| be the [=environment settings object/origin=] specified by this {{ScopedCredential}} object's [=relevant settings object=].

..is using [=current settings object=] here correct?

Probably not. Fixing.

equalsJeffH · 2017-04-18T20:32:31Z

index.bs

@@ -651,8 +716,8 @@ When this method is invoked, the user agent MUST execute the following algorithm

    1. [=set/Append=] |authenticator| to |issuedRequests|.

-1. Let |promise| be [=a new Promise=]. Return |promise| and start a timer for |adjustedTimeout| milliseconds. Then execute the
-    following steps [=in parallel=]. The [=task source=] for these [=tasks=] is the [=dom manipulation task source=].
+1. Start a timer for |adjustedTimeout| milliseconds. Then execute the following steps [=in parallel=]. The [=task source=] for


alrightie -- i wonder whether that rationale ought to be captured somewhere in these spec(s)?

equalsJeffH · 2017-04-18T20:34:46Z

index.bs

    </dd>
    </dl>

-1. [=Reject=] |promise| with a {{DOMException}} whose name is "{{NotAllowedError}}".
+1. Return a {{DOMException}} whose name is "{{NotAllowedError}}".


equalsJeffH · 2017-04-18T20:39:32Z

index.bs

@@ -870,7 +914,7 @@ use a [=roaming authenticator=] which was originally registered with the [RP] us

    :   <dfn>attachment</dfn>
    ::  This member contains authenticator attachment descriptions, which are used as an additional constraint on which
-        authenticators are eligible to participate in a [[#makeCredential]] or [[#getAssertion]] operation. See [[#attachment]]
+        authenticators are eligible to participate in a {{ScopedCredential/create()}} operation. See [[#attachment]]


[=attachment=] is not used in get() ?

It's only passed into a create() operation, but I suppose it is used in the backend decisions for get()? Do we need to pass it into get() as well?

equalsJeffH · 2017-04-18T20:41:28Z

index.bs

-the {{makeCredential()}} or {{getAssertion()}} method. It mirrors the fields of the {{ScopedCredential}} object returned by
-these methods.
+the {{create()}} or {{CredentialsContainer/get()}} methods. It mirrors the fields of the {{ScopedCredential}} object returned by
+latter method.


s/latter method/the latter methods/

equalsJeffH · 2017-04-18T20:56:47Z

index.bs

@@ -806,8 +914,7 @@ authorizing an authenticator with which to complete the operation.
        complete. This is treated as a hint, and may be overridden by the platform.

    - The <dfn>rpId</dfn> parameter explicitly specifies the RP ID that the credential should be associated with. If it is
-        omitted, the RP ID will be set to the [=origin=] specified by the {{WebAuthentication}} object's [=relevant settings
-        object=].
+        omitted, the RP ID will be set to the [=environment settings object/origin=] specified by the [=current settings object=].


equalsJeffH

This looks nominally OK given our decision on call last Fri 12-Apr-2017 (https://www.w3.org/2017/04/14-webauthn-minutes.html) to "merging in, in order to get the namespaces nailed down, and deal with problems afterwards". Thanks for addressing my comments. I have a couple/few additional ones above.

equalsJeffH · 2017-04-18T21:57:51Z

I've re-reviewed and changed my "changes requested" to "approved" given our decision on call last Fri 12-Apr-2017 (https://www.w3.org/2017/04/14-webauthn-minutes.html) to "merging in, in order to get the namespaces nailed down, and deal with problems afterwards".

[ i added this comment because presently "reviews" are not cc'd to the mailing list :-/ ]

…l-management@59bba00

mikewest · 2017-04-19T08:05:38Z

w3c/webappsec-credential-management#72 added a create() method to CredentialsContainer for asynchronous creation of all credential types: 2335da4 shifts this patch to use that method rather than a static method on ScopedCredential, which I think will address one of @leshi's earlier concerns.

I'll address @equalsJeffH's other feedback shortly.

vijaybh · 2017-04-19T16:11:49Z

index.bs

-    {{WebAuthentication/makeCredential(options)/options}}.{{MakeCredentialOptions/user}} passed to {{makeCredential()}}, by
-    associating it with the credential ID and credential public key contained in |authData|'s [=attestation data=], as
+    {{ScopedCredential/[[Create]](options)/options}}.{{MakeCredentialOptions/user}} passed to {{CredentialsContainer/create()}},
+    by associating it with the credential ID and credential public key contained in |authData|'s [=attestation data=], as


After the CM API merge, the implication of the current text is that the RP should take the credential ID directly from the attestation data, and ignore the id in the credential object itself. This seems like the right thing to do and actually a security measure. Should we make this explicit in the text here?

They should be the same, shouldn't they? I suppose there's additional confidence that the signed attestation data is more trustworthy...

RP should take the credential ID directly from the attestation data, and ignore the id in the credential object itself. This seems like the right thing to do...

agreed.

...and actually a security measure. Should we make this explicit in the text here?

I think so, and perhaps discussed in a sec-cons section.

equalsJeffH · 2017-04-19T16:46:53Z

index.bs

+The <dfn for="ScopedCredential" method>\[[DiscoverFromExternalSource]](options)</dfn> method is used to discover and use an
+existing scoped credential, with the user's consent. The script optionally specifies some criteria to indicate what credentials
+are acceptable to it. The user agent and/or platform locates credentials matching the specified criteria, and guides the user
+to pick one that the script should be allowed to use. The user may choose not to provide a credential even if one is present,


s/should be allowed/will be allowed/ ?

equalsJeffH · 2017-04-19T16:53:24Z

index.bs

-        imageURL: "https://pics.acme.com/00/p/aBjjjpqPb.png"
-    };
+    var scoped = {
+      challenge: new TextEncoded().encode("climb a mountain"),


I have angst wrt this bogus client-side non-random setting of challenge (see #404) -- perhaps we should change it to (if I have it correct)..

var challenge = Uint8Array.from(window.atob("PGifxAoBwCkWkm4b1CiIl5otCphiIh6MijdjbWFjomA="), c=>c.charCodeAt(0))

for now as we await #404 to be decided?

Sure (although that's hideous). ;)

equalsJeffH · 2017-04-19T16:54:37Z

the new changes in the latest commits today look overall ok to me -- thx @mikewest -- i did make a couple detail-level comments.

mikewest · 2017-04-19T17:18:58Z

@equalsJeffH: a042dd9 should address your two nits.

When we resolve #404, we'll certainly want to update the other challenge examples... https://w3c.github.io/webauthn/#example-33d07a93 in particular. But let's address those separately. :)

equalsJeffH · 2017-04-19T18:14:16Z

@mikewest thanks for your patience & perseverance. will merge forthwith.

also, closes #249, improves #404

…i-strawman

mikewest added 11 commits March 16, 2017 09:24

Tiny typo in 'ScopedCredentialDesciptor'.

3b5138d

Create a combined interface for authenticator responses.

6c38d02

Invert the relationship between ScopedCredential and AuthenticatorAss…

6074c50

…ertionResponse.

Change 'makeCredential' to return a 'ScopedCredential'.

524f8ac

Move 'makeCredential()' to 'ScopedCredential'.

146f2c0

Shift 'ScopedCredential' to derive from 'Credential'.

ab8d74e

Rename 'ScopedCred' to 'scoped' to align with CM API types.

394babd

Rename 'makeCredential()' to 'create()'.

46eff1a

Move 'getAssertion' to 'ScopedCredential'

d9c8b74

This is a temporary step to get rid of WebAuthentication, and pave the way to move to 'get()' in the next patch.

Merge the arguments to 'getAssertion()'

fdf341a

In order to align with CredentialsContainer::get(), merge the challenge into 'AssertionOptions' and rename 'AssertionOptions' to 'ScopedCredentialRequestOptions'.

mikewest added 2 commits March 16, 2017 14:13

Typos in examples.

245c275

Typo in headers (not enough #)

21be528

vijaybh reviewed Mar 16, 2017

View reviewed changes

mikewest added 2 commits March 17, 2017 09:00

Merge remote-tracking branch 'origin/master' into cm-api-strawman

e04c5f0

Nits from @vijaybh's review.

b1e87ca

battre reviewed Mar 17, 2017

View reviewed changes

mikewest added 2 commits March 17, 2017 18:02

Add battre@ to the acks.

926375a

Nits from @battre.

c48c70b

jyasskin approved these changes Mar 21, 2017

View reviewed changes

Comments from @jyasskin

fedcced

equalsJeffH added subtype:algorithms/WebIDL type:technical labels Mar 22, 2017

equalsJeffH added this to the CR milestone Mar 22, 2017

mikewest added 2 commits March 23, 2017 09:02

Merge remote-tracking branch 'origin/master' into cm-api-strawman

3a0ae84

Merge remote-tracking branch 'origin/master' into cm-api-strawman

488ae31

mikewest added 3 commits April 18, 2017 11:27

Merge commit '275a552' into merge-with-tot

76605e5

Merge branch 'merge-with-tot' into cm-api-strawman

8887324

fixup @equalsJeffH feedback.

f967ffb

mikewest commented Apr 18, 2017

View reviewed changes

equalsJeffH reviewed Apr 18, 2017

View reviewed changes

equalsJeffH approved these changes Apr 18, 2017

View reviewed changes

fixup 'CredentialsContainer::create()', as of w3c/webappsec-credentia…

2335da4

…l-management@59bba00

mikewest added 2 commits April 19, 2017 10:07

fixup ID => Id, even though I hate it. :)

eab3551

fixup @equalsJeffH

45e1b50

vijaybh reviewed Apr 19, 2017

View reviewed changes

equalsJeffH reviewed Apr 19, 2017

View reviewed changes

fixup @equalsJeffH nits.

a042dd9

mikewest mentioned this pull request Apr 19, 2017

Should the "authentication" attribute on Navigator be [SameObject]? #249

Closed

equalsJeffH merged commit 66c6224 into w3c:master Apr 19, 2017

WebAuthnBot pushed a commit that referenced this pull request Apr 19, 2017

Built by Travis-CI: 66c6224 Merge pull request #384 from battre/cm-ap…

2cccb33

…i-strawman

equalsJeffH mentioned this pull request Apr 19, 2017

Review Web Authentication spec w3ctag/design-reviews#97

Closed

selfissued added a commit to selfissued/webauthn that referenced this pull request Apr 19, 2017

Merged with master now that PR w3c#384 is in place

b02764f

jyasskin mentioned this pull request Apr 20, 2017

RawId vs Id is confusing #412

Closed

equalsJeffH mentioned this pull request May 30, 2017

reconciling origin and RP ID handling #464

Merged

This was referenced Jun 20, 2017

There is no "current settings object" in algorithm steps that are executing in parallel #254

Closed

restrict WebAuthentication API to only top level browsing context #374

Closed


		## Information about Scoped Credential (interface <dfn interface>ScopedCredentialInfo</dfn>) ## {#iface-credentialInfo}
		The {{AuthenticatorResponse}} interface and its derieved interfaces represent the data

Strawman of an integration between WebAuthn and Credential Management. #384

Strawman of an integration between WebAuthn and Credential Management. #384

Conversation

mikewest commented Mar 16, 2017

mikewest commented Mar 16, 2017

equalsJeffH commented Mar 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vijaybh commented Mar 16, 2017

mikewest commented Mar 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikewest Mar 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikewest left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Apr 18, 2017

AngeloKai commented Apr 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH Apr 18, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH left a comment • edited

Choose a reason for hiding this comment

equalsJeffH commented Apr 18, 2017 • edited

mikewest commented Apr 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

equalsJeffH commented Apr 19, 2017

mikewest commented Apr 19, 2017

equalsJeffH commented Apr 19, 2017

mikewest Mar 22, 2017 •

edited

equalsJeffH Apr 18, 2017 •

edited

equalsJeffH left a comment •

edited

equalsJeffH commented Apr 18, 2017 •

edited