From b12d40670ebb82a8e20b1fe47228e56e6409aab1 Mon Sep 17 00:00:00 2001 From: Stephen McGruer Date: Thu, 28 Apr 2022 10:40:45 -0400 Subject: [PATCH 1/2] [Spec] Add note on SPC opt-in, and misc clarifications This PR adds a note about what SPC opt-in means today (required for any use of SPC) versus in our preferred future (required for 3p use of SPC). It also contains a set of small clarifications, e.g. updating the 'steps to silently determine...' to acknowledge that an RP ID will likely be needed. --- spec.bs | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/spec.bs b/spec.bs index a2119dd..48dd5a9 100644 --- a/spec.bs +++ b/spec.bs @@ -110,7 +110,8 @@ not just the merchant origin where the user first registered. To that end, an important feature of Secure Payment Confirmation is that the merchant (or another entity) may initiate the authentication -ceremony on the [=Relying Party's=] behalf. +ceremony on the [=Relying Party's=] behalf. The [=Relying Party=] must +opt-in to allowing this behavior during credential creation. Functionally, this specification defines a new [=payment method=] for the {{PaymentRequest}} API, and adds a [=WebAuthn Extension=] to extend @@ -218,10 +219,10 @@ In this section, we walk through some scenarios for Secure Payment Confirmation and the corresponding sample code for using this API. Note that these are example flows and do not limit the scope of how the API can be used. -### Registration ### {#sctn-sample-registration} +### Registration during a purchase ### {#sctn-sample-registration} This is a first-time flow, in which a new credential is created and stored by -an issuing bank. +an issuing bank during a purchase by the user on some merchant. 1. The user visits `merchant.com`, selects an item to purchase, and proceeds to the checkout flow. They enter their payment instrument details, and indicate @@ -275,8 +276,8 @@ const publicKey = { displayName: "Jane Doe", }, - // This Relying Party will accept either an ES256 or RS256 credential, but - // prefers an ES256 credential. + // This example Relying Party will accept either an ES256 or RS256 credential, + // but prefers an ES256 credential. pubKeyCredParams: [ { type: "public-key", @@ -288,7 +289,6 @@ const publicKey = { } ], - // This Relying Party requires user verification. authenticatorSelection: { userVerification: "required", residentKey: "required", @@ -321,7 +321,7 @@ navigator.credentials.create({ publicKey }) -### Authentication ### {#sctn-sample-authentication} +### Authentication on merchant site ### {#sctn-sample-authentication} This is the flow when a user with an already registered credential is performing a transaction and the issuing bank and merchant wish to use Secure @@ -418,19 +418,29 @@ try { not) be used by a [=Relying Party=] for other authentication flows (e.g., login). -: Steps to determine if a credential is SPC-enabled -:: An as-yet undefined process by which a user agent can, given a [=credential - ID=], determine if the credential represented by that ID is an [=SPC - Credential=]. + Note: The current version of this specification requires the [=Relying + Party=] to explicitly opt in for a credential to be used in SPC in + either a first-party or third-party context. Longer-term, our + intention is that all [=public key credential|WebAuthn credentials=] + will be usable for SPC in a first-party context (e.g., on the + [=Relying Party's=] domain) and opt-in will only be required to allow + a credential to be used by a third-party. + +: Steps to silently determine if a credential is SPC-enabled +:: An as-yet undefined process by which a user agent can, given a + [[webauthn-3#relying-party-identifier|Relying Party Identifier]] and a + [=credential ID=], silently (i.e., without user interaction) determine if + the credential represented by that ID is an [=SPC Credential=]. NOTE: See WebAuthn issue 1667. : Steps to silently determine if a credential is available for the current device -:: An as-yet undefined process by which a user agent can, given a [=credential - ID=], silently (i.e., without user interaction) determine if the credential - represented by that credential ID is available for the current device (i.e., - could be successfully used as part of a WebAuthn +:: An as-yet undefined process by which a user agent can, given a + [[webauthn-3#relying-party-identifier|Relying Party Identifier]] and a + [=credential ID=], silently (i.e., without user interaction) determine if + the credential represented by that credential ID is available for the + current device (i.e., could be successfully used as part of a WebAuthn [[webauthn-3#sctn-getAssertion|Get]] call). This allows the user agent to only conditionally display @@ -617,10 +627,12 @@ input {{SecurePaymentConfirmationRequest}} |data|, are: 1. For each |id| in |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"]: - 1. Run the [=steps to determine if a credential is SPC-enabled=] and the - [=steps to silently determine if a credential is available for the - current device=]. If the result of either of these is `false`, remove - |id| from |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"]. + 1. Run the [=steps to silently determine if a credential is available for + the current device=] and the [=steps to silently determine if a + credential is SPC-enabled=], passing in + |data|["{{SecurePaymentConfirmationRequest/rpId}}"] and |id|. If the + result of either of these is `false`, remove |id| from + |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"]. 1. If |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"] is now empty, return `false`. The user agent must maintain From 1fac0bbf1865a6de328243ad3c726678f5628adc Mon Sep 17 00:00:00 2001 From: Stephen McGruer Date: Fri, 29 Apr 2022 09:16:28 -0400 Subject: [PATCH 2/2] Address review comments --- spec.bs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/spec.bs b/spec.bs index 48dd5a9..8cf063e 100644 --- a/spec.bs +++ b/spec.bs @@ -219,10 +219,10 @@ In this section, we walk through some scenarios for Secure Payment Confirmation and the corresponding sample code for using this API. Note that these are example flows and do not limit the scope of how the API can be used. -### Registration during a purchase ### {#sctn-sample-registration} +### Registration during a checkout ### {#sctn-sample-registration} This is a first-time flow, in which a new credential is created and stored by -an issuing bank during a purchase by the user on some merchant. +an issuing bank during a checkout by the user on some merchant. 1. The user visits `merchant.com`, selects an item to purchase, and proceeds to the checkout flow. They enter their payment instrument details, and indicate @@ -276,8 +276,8 @@ const publicKey = { displayName: "Jane Doe", }, - // This example Relying Party will accept either an ES256 or RS256 credential, - // but prefers an ES256 credential. + // In this example the Relying Party accepts either an ES256 or RS256 + // credential, but prefers an ES256 credential. pubKeyCredParams: [ { type: "public-key", @@ -419,7 +419,7 @@ try { login). Note: The current version of this specification requires the [=Relying - Party=] to explicitly opt in for a credential to be used in SPC in + Party=] to explicitly opt in for a credential to be used in either a first-party or third-party context. Longer-term, our intention is that all [=public key credential|WebAuthn credentials=] will be usable for SPC in a first-party context (e.g., on the