Clarify that RP can use its own credentials even if extension not specified (#272)

Make clear that an RP should be able to use its own credentials even if payment extension not specified.

---------

Co-authored-by: Stephen McGruer <[email protected]>

Author: ianbjacobs

scope.md

@@ -112,7 +112,7 @@ Note: This use case intends to capture the "in-transaction registration" use cas
 
 #### EMV® Secure Remote Commerce (SRC) System as Relying Party
 
-* Alice checkouts on a merchant web site with SRC, which triggers the SRC Digital Card Facilitator (DCF) to be displayed. The SRC DCF asks whether she wants to use biometric authentication to streamline payment. She agrees and SRC DCF redirects her to her bank where she goes through an ID&V process with her bank for the credit card she wishes to use.
+* Alice checkouts on a merchant web site with SRC, which triggers the SRC Digital Card Facilitator (DCF) to be displayed. The SRC DCF asks whether she wants to use biometric authentication to streamline payment. She agrees and SRC DCF redirects her to her bank where she goes through an Identity and Verification (ID&V) process with her bank for the credit card she wishes to use.
 * As an alternative, Alice visits her bank, authenticates to her bank, registers into biometric authentication, and selects card(s) that she wants to make available to SRC. The bank (the Relying Party) shares the authentication credential with the SRC System.
 * The following week Alice checkouts with a merchant enabled with SRC. The SRCi/DCF prompts Alice to do biometric authentication. The SRC System reviews the authentication results, and the bank authorizes the transaction.
 
@@ -187,7 +187,7 @@ These use cases represent additional considerations, some of which (e.g., unregi
 #### Merchant as Relying Party
 
 * Alice logs into her favorite merchant using a merchant proprietary mechanism or using biometric authentication.   
-* The merchant asks Alice if she wants to use biometric authentication to streamline payment. She agrees and goes through an ID&V process with her bank for the credit card she wishes to use. (The merchant may decide to perform IDamp;&V during the checkout or outside of the checkout.)
+* The merchant asks Alice if she wants to use biometric authentication to streamline payment. She agrees and goes through an ID&V process with her bank for the credit card she wishes to use. (The merchant may decide to perform ID&V during the checkout or outside of the checkout.)
 * The merchant is the relying party for this authentication credential, and shares authentication data with Alice’s bank and/or payment network to allow for partial or full validation of authentication results in subsequent checkouts.
 * The following week Alice checks out on the merchant site and is prompted by the merchant to do biometric authentication. The merchant uses SPC then shares authentication results with Alice’s bank and/or payment network, which reviews the data. The bank authorizes the transaction.
 
@@ -220,7 +220,7 @@ priority:
 
 ## Out of Scope
 
-* ID & V to establish real world identity during registration.
+* ID&V to establish real world identity during registration.
 * Use cases for peer-to-peer payments or business-to-business transactions.
 
 ## Future Extensions

spec.bs

@@ -90,6 +90,7 @@ spec:fetch; type:dfn; for:/; text:request;
 spec:i18n-glossary; type:dfn; text:bidi isolation
 spec:i18n-glossary; type:dfn; text:language priority list
 spec:url; type:dfn; text:valid domain;
+spec:html; type:dfn; for:environment settings object; text:origin
 </pre>
 
 <pre class="biblio">
@@ -703,7 +704,7 @@ NOTE: The use of the static {{PaymentRequest/isSecurePaymentConfirmationAvailabl
 ### Steps to validate payment method data ### {#sctn-steps-to-validate-payment-method-data}
 
 The [=steps to validate payment method data=] for this payment method, for an
-input {{SecurePaymentConfirmationRequest}} |data|, are:
+input {{PaymentRequest}} |request| and {{SecurePaymentConfirmationRequest}} |data|, are:
 
 <wpt>
   constructor.https.html
@@ -799,11 +800,13 @@ input {{SecurePaymentConfirmationRequest}} |data|, are:
 1. For each |id| in |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
+        the current device=], passing in
+        |data|["{{SecurePaymentConfirmationRequest/rpId}}"] and |id|.
+        If the result is `false`, remove |id| from
         |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"].
+    1.  If the |data|["{{SecurePaymentConfirmationRequest/rpId}}"] is
+        not the [=origin=] of the [=relevant settings object=] of |request|,
+        run the [=steps to silently determine if a credential is SPC-enabled=],         passing in |data|["{{SecurePaymentConfirmationRequest/rpId}}"] and |id|.        If the result is `false`, remove |id| from |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"].
 
 1. If |data|["{{SecurePaymentConfirmationRequest/credentialIds}}"] is now empty,
     return `false`. The user agent must maintain
@@ -1667,4 +1670,3 @@ This section adds the below-listed [=extension identifier=] to the IANA "WebAuth
 - Specification Document: Section [[#sctn-payment-extension-registration]] of this specification
 - Change Controller: [W3C Web Payments Working Group](https://www.w3.org/groups/wg/payments)
 - Notes: Registration follows [3 May 2023 discussion](https://www.w3.org/2023/05/03-webauthn-minutes#t01) with the Web Authentication Working Group.
-