From d23f37ebb858a73d473a10c01a5a5cc6f7a71341 Mon Sep 17 00:00:00 2001 From: Alexei Czeskis Date: Thu, 8 Dec 2016 10:38:26 -0800 Subject: [PATCH] Adds authenticator attachement to credential options (#243) * Adds authenticator attachement to credential options Closes issue #213 * use Vijay's examples * addressed Jeff's comments * put back vijay's suggestion that got dropped * addressed Jeff's comments * closing div needed in dfn for Attachment. See #243 * editorial tweak as per Jeff's comments --- index.bs | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index cf0e5dabf..e5b837f97 100644 --- a/index.bs +++ b/index.bs @@ -428,13 +428,19 @@ When this method is invoked, the user agent MUST execute the following algorithm 9. Initialize |issuedRequests| to an empty list. -10. For each authenticator currently available on this platform: asynchronously invoke the authenticatorMakeCredential +10. If {{ScopedCredentialOptions/attachment}} is specified, let |attachment| be + {{ScopedCredentialOptions/attachment}}. If |attachment| is null or empty, + reject |promise| with a DOMException whose name is "InvalidArgumentError". + Otherwise, only consider authenticators whose attachment is mentioned in + |attachment|. + +11. For each available authenticator: asynchronously invoke the authenticatorMakeCredential operation on that authenticator with |rpIdHash|, clientDataHash, {{accountInformation}}, |normalizedParameters|, {{ScopedCredentialOptions/excludeList}} and |clientExtensions| as parameters. Add a corresponding entry to |issuedRequests|. - For each credential C in {{ScopedCredentialOptions/excludeList}} that has a non-empty |transports| list, optionally use only the specified transports to test for the existence of C. -11. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses +12. While |issuedRequests| is not empty, perform the following actions depending upon the |adjustedTimeout| timer and responses from the authenticators: - If the |adjustedTimeout| timer expires, then for each entry in |issuedRequests| invoke the authenticatorCancel operation on that authenticator and remove its entry from the list. @@ -621,8 +627,9 @@ authorizing an authenticator with which to complete the operation. dictionary ScopedCredentialOptions { unsigned long timeoutSeconds; USVString rpId; - sequence < ScopedCredentialDescriptor > excludeList; + sequence < ScopedCredentialDescriptor > excludeList; WebAuthnExtensions extensions; + Attachment attachment; }; @@ -645,6 +652,50 @@ authorizing an authenticator with which to complete the operation. the credential, or that additional information be returned in the attestation statement. Alternatively, the caller may specify an additional message that they would like the authenticator to display to the user. Extensions are defined in [[#extensions]]. + + - The attachment parameter 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]] for a description of the attachment values and their meanings. + + + +### Credential Attachment enumeration (enum Attachment) ### {#attachment} + +
+    enum Attachment {
+        "platform",
+        "cross_platform"
+    };
+
+ +
+ Clients may communicate with authenticators using a variety of mechanisms. + For example, a client may use a platform-specific API to communicate + with an authenticator which is physically bound to a platform. On the + other hand, a client may use a variety of cross-platform transport + protocols such as Bluetooth (see [[#transport]] to discover and communicate + with authenticators. We define authenticators that are part of the + client's platform as having a |platform| attachment, while those that are + reachable via standardized cross-platform transport protocols are defined + as having |cross_platform| attachment. This distinction is important + because there are use-cases where only |platform| attached authenticators + are acceptable to a [RP], and conversely ones where only |cross_platform| + attached authenticators are employed. As a concrete example of the former, + a credential on a platform authenticator may be used by [RPS] to quickly + and conveniently reauthenticate the user with a minimum of friction. As + a concrete example of the latter, when the user is accessing the [RP] from + a given client for the first time, they may be required to use a + cross-platform authenticator which was originally set up on a different + client. + +