Re: SPC Scope.md Comments

Hi Gerhard,

Fantastic list! I'm almost scared to reply because I worry my choice of
bits to pick at will cause others not to read the full thing :D. So my call
to others is - please read Gerhards list in full too and formulate your own
areas to comment on as well.

> Add Secure Remote Commerce (ClickToPay) to this list

This may come from my general caution around this section or at least how
it's named ('Protocols and Systems Helping to Guide Requirements'), but do
you propose adding SRC here because you believe it represents a use-case
that SPC should support (a proxy to 'digital wallets'?), or because it
explicitly has representatives in the SPC task force and/or WPWG?

> Browser Behaviour / Enrollment
> Browser Behaviour / Transaction

I think these are fantastic questions, but I don't think we have an answer
to them yet to put in the scope document. Perhaps just adding a TODO is
enough, not sure.

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

Can you clarify 'the extra auth step'?

> Should we be specific about the fields and structure of the cryptogram?
> If SPC runs inside Iframes, which permissions will be required to allow
this?

I think this level of detail for both of these belong in the explainer (and
eventually the spec), not the scope document?

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

I'm not really sure what these comments mean; can you elaborate?

Thanks,
Stephen



On Fri, 7 May 2021 at 02:28, 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?
>    - 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.
>       - 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)
>       - Add Secure Remote Commerce (ClickToPay) to this list
>    - 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
>       - In authentication and Enrollment, we should Indicate the extra
>       auth step for Fido Auth
>       - Other things can happen during a transaction. Do we indicate the
>       cancel & Timeout option/logic/cases
>       - 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
>    - 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?
>       - Is there scenarios’ where credentials may not exist?
>    - 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).
>       - Other
>       - Should we be specific about the fields and structure of the
>       cryptogram?
>       - If SPC runs inside Iframes, which permissions will be required to
>       allow this?
>    - Preferences
>       - Who determines what is allowed? Or is that browser & customer
>       permission?
>       - If we have preferences the assertion should include it?
>    - 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?)
>       - 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.
>       - Should we expand on the linking between the data objects/entities
>        (linking between a Credential and a Payment token)
>    - For Future
>       - Discoverability of tokens on a domain (similar to Fido Level 2?)
>
>
>
> Chat again soon,
>
> Gerhard
>