Re: SPC Scope.md Comments

HI Gerhard,

Thanks very much for the detailed comments. Some notes inline.

Ian

> On May 7, 2021, at 1:27 AM, Gerhard Oosthuizen <goosthuizen@entersekt.com> wrote:
> 
> Hi Team,
>  
> Some comments from my side on:
>  • https://github.com/w3c/secure-payment-confirmation/blob/gh-pages/scope.md
> Ideally we can address most of them via email, and then discuss the more unclear items in our meeting.
>  
> (For the suggestions the team is comfortable with, I’ll then update/edit the sections in the scope document. Just want to first get your input before going off and making changes)
>  
> Each bulleted header links to the relevant section in scope.md document:
>  • Introduction
>   • Should we perhaps already mention that this is to improve ecommerce checkout, and that Cross Domain (from merchant to issuer) and the fact that the merchant gets more control over the UX in a checkout. This is to separate this from This will help readers to differentiate it from Delegated Auth (parallel industry concept), which has the same goals, but the Identity is transferred to the merchant side?


* I don’t mind adding “ecommerce” but wasn’t sure if we wanted to be that specific. We currently say "support streamlined authentication during a payment transaction.” We could
  change it to "support streamlined authentication during an ecommerce transaction.”

* Regarding “cross domain” I think that is covered by “scale authentication across merchants.” If you have more specific text in mind, let me know.
 
* Regarding “merchant gets more control over the UX in a checkout”: I’m not sure we should add that to the intro. I do think it relates to the “simpler front-end deployment”, or at least we could make it relate.
  That’s in the “unique features” section.

>  • Unique Features:
>   • If suggest we focus on the 3 primary features (perhaps mention the others as secondary)
>    • Controlled Display, focused on Payments
>     • Even if we allow frictionless, the customer is in control of the display, aided by the browser. The Issuer and Merchant cannot ‘skip the sheet’
>    • Cryptographic Proof
>    • Third Party domain enablement (so called from separate division)
>   • Regarding the other listed features
>    • Streamlined UX: We should restate. The need for SPC is actually because Fido is not optimized for payments today. So would not lead with that
>    • Phishing Resistant: Suggest removing this. This is a core Fido benefit. If we use fido we’ll get it. But we should not be bound by it.
>    • Simpler Front-end: Seems to discuss controlled display and Third party combination. As mentioned, we can consider splitting this into the two sections.

I think “controlled display” includes three of the existing bullets:

 * Streamlined UX
 * Phishing resistant 
 * Simpler front-end deployment

Is your suggestion to rework those three bullets into a single entry? Let’s discuss, because I find “controlled display” does not convey the benefits as clearly.

"Cryptographic Proof” is covered by “Transaction Confirmation.” I don’t feel too strongly about one phrase over the other; I’d love input here.

Regarding “Third party domain enablement”, that’s covered by “Scalable and Ubiquitous”.I would ask the same question here: What is the phrase that most clearly articulates
the benefit?

Regarding “Phishing-resistant”: the intention here is not to capture the FIDO qualities that are anti-phishing (e.g., domain-bound credentials), but rather the UX of the transaction 
confirmation dialog, which is owned by the browser (or authenticator hardware). So this “phishing-resistant” point should be applicable for FIDO or WebCrypto or other auth method.

Summary:

  * Even though the section is about “Unique Features” I realize through this thread that my focus is on “Unique Benefits”. We should discuss which we prefer.
  * There’s room for greater clarity (e.g., around what “phishing resistant” means in this context)

>  • Protocols and Systems Helping to Guide Requirements
>   • For Open banking, we might want to state that this is specifically focused on the PISP use-cases (payments)

Added.

>   • Add Secure Remote Commerce (ClickToPay) to this list

(I think I had already added that one last week.)

>  • User Stories
>   • We need to add the scenario’s for Unenrollment/delinking/ updates
>    • E.g. Alice closes one of her cards / Alice closes the account with the bank /
>    • The bank would like to change the logo & description on Alice’s card

+1. I’ve added two placeholders for these (to develop them).

>   • In authentication and Enrollment, we should Indicate the extra auth step for Fido Auth

The text may have changed since your review. Can you say more what you mean?

>   • Other things can happen during a transaction. Do we indicate the cancel & Timeout option/logic/cases

I agree it’s important to consider those. However, we’ll need to add those for every one of the use cases. Instead, I’ve created two new issues:
 https://github.com/w3c/secure-payment-confirmation/issues/66
 https://github.com/w3c/secure-payment-confirmation/issues/67

>   • Add the scenario where merchant does not support SPC. The Bank obviously does (that’s why they created the credentials). So when the redirect happens to them (e.g. via 3DS or Open Banking OAuth2 redirect) the bank will want to execute SPC in their own context 

+1. I’ve added the stub of a story for that use case. (And we should discuss.)

>  • Browser Behaviour / Enrollment
>   • When does credential creation ask for a user authentication event? E.g. if credential already exists / is linked a second time / is unlinked / is created new?

Perhaps this behavior could be left to the browser:

 * During enrollment the browser detects that the user already has an SPC credential for this instrument. 
 * How the browser manages the user experience is left to the browser. Recommended capabilities:
   - Add the authenticator for the same instrument.
   - Delete the previous binding(s) and only store the new one

This relates to the cardinality topic, so I’ve added a note here:
 https://github.com/w3c/secure-payment-confirmation/issues/49#issuecomment-836858493

>   • Is there scenarios’ where credentials may not exist?

I’m not sure to understand this point.

>  • Browser Behaviour / Transaction
>   • If there are more than one credential that match
>    • Should we not offer some selection by the user (especially if they are
>    • Could the user select a ‘default’ in the browser
>    • What if one of them has been ‘activated’ for frictionless flow. Should that be auto-selected based on some order/type (e.g. first single factor, then multifactor).

New issue:
 https://github.com/w3c/secure-payment-confirmation/issues/69


>  • Other
>   • Should we be specific about the fields and structure of the cryptogram?

I feel like we don’t need to do so in detail in this document. 

I think the next document to develop is a requirements document, and that document (which might pull some material from the scope document) should begin to list requirements for
the data structure. But even there, I think we will end up being precise in the spec.

>   • If SPC runs inside Iframes, which permissions will be required to allow this?

New issue:
 https://github.com/w3c/secure-payment-confirmation/issues/68

>  • Preferences
>   • Who determines what is allowed? Or is that browser & customer permission?
>   • If we have preferences the assertion should include it?

I think the user should have the final say on the user experience.

I think the relying party should be able to ask the browser for a particular authentication experience (but where the user can override).

I think the merchant should be able to express a preference to the relying party.

Added some notes here on frictionless flows:
 https://github.com/w3c/secure-payment-confirmation/issues/34#issuecomment-836864051


>  • Other notes
>   • Should we note the 3 classic types of payments that SPC trying to address to ensure we cover the scenario’s (card Pull, Card Push, Account Push?)

+1 for the scope document. Want to propose some text?

>   • Should we define if we include/exclude the actors in the payment.
>    • Person-to-person  vs Person to Merchant
>    • Right now focus is solely on merchant, which might be right. But we should then state this.

That relates to my earlier comment about whether to say “ecommerce.” Personally I am ok to say this for the time being. 

In practice PR API has not been relevant for P2P payments. Maybe SPC will lend itself more to that (and if it can be used outside of PR API, then we might explore that use case more closely).
Thus, this may relate to Stephen’s issue:
 https://github.com/w3c/secure-payment-confirmation/issues/65


>   • Should we expand on the linking between the data objects/entities  (linking between a Credential and a Payment token)

My sense: not here, but either in the requirements document or the spec itself.

>  • For Future
>   • Discoverability of tokens on a domain (similar to Fido Level 2?)

Is that a use case to describe now, even if we don’t prioritize it?

Thanks again!

Ian

>  
> Chat again soon,
> Gerhard

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Monday, 10 May 2021 15:50:33 UTC