Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Spec] Add note on SPC opt-in, and misc clarifications #183

Merged
merged 2 commits into from
Apr 29, 2022
Merged

[Spec] Add note on SPC opt-in, and misc clarifications #183

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b12d406
[Spec] Add note on SPC opt-in, and misc clarifications
stephenmcgruer Apr 28, 2022
1fac0bb
Address review comments
stephenmcgruer Apr 29, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 31 additions & 19 deletions spec.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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}
stephenmcgruer marked this conversation as resolved.
Show resolved Hide resolved

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
Expand Down Expand Up @@ -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,
stephenmcgruer marked this conversation as resolved.
Show resolved Hide resolved
// but prefers an ES256 credential.
pubKeyCredParams: [
{
type: "public-key",
Expand All @@ -288,7 +289,6 @@ const publicKey = {
}
],

// This Relying Party requires user verification.
authenticatorSelection: {
userVerification: "required",
residentKey: "required",
Expand Down Expand Up @@ -321,7 +321,7 @@ navigator.credentials.create({ publicKey })

</div> <!-- non-normative -->

### 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
Expand Down Expand Up @@ -418,19 +418,29 @@ try {
not) be used by a [=Relying Party=] for other authentication flows (e.g.,
login).

: <dfn>Steps to determine if a credential is SPC-enabled</dfn>
:: 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
stephenmcgruer marked this conversation as resolved.
Show resolved Hide resolved
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.

: <dfn>Steps to silently determine if a credential is SPC-enabled</dfn>
:: 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 <a href="https://github.com/w3c/webauthn/issues/1667">WebAuthn
issue 1667</a>.

: <dfn>Steps to silently determine if a credential is available for the current device</dfn>
:: 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering about the phrase "current device" here and elsewhere in the API. It might be overly constraining in light of synched credentials and CABLE. Would it be more inclusive to say "current API call"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question. I'm not sure how best to resolve that yet (maybe worth adding a minor comment to #174), so going to leave for now.

[[webauthn-3#sctn-getAssertion|Get]] call).

This allows the user agent to only conditionally display
Expand Down Expand Up @@ -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
Expand Down