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

Jump to bottom

Improving understanding of who is authenticating for whom #187

Open
ianbjacobs opened this issue May 3, 2022 · 7 comments
Open

Improving understanding of who is authenticating for whom #187

ianbjacobs opened this issue May 3, 2022 · 7 comments
Labels
after-v1 WebAuthn liaison

Comments

@ianbjacobs
Copy link
Collaborator

ianbjacobs commented May 3, 2022 •
edited
Loading

Note: This issue will also involve discussion with the Web Authentication WG.

I have heard several comments about potential user confusion about who is authentication for whom when using WebAuthn or SPC and multiple origins are involved.

Although it may not be the case for all payment systems, at least for now I am hearing that there are two main scenarios:

  1. Bank takes responsibility for authentication.
  2. Merchant takes responsibility for authentication ("delegation" by the Bank). The Merchant may implement may implement this through a Payment Service Provider (PSP).

SPC enables decoupling of authentication ceremony from validation, so these are the main scenarios:

  1. Bank takes responsibility
    1a) Bank conducts ceremony with WebAuthn or SPC and validates assertion.
    1b) PSP conducts ceremony with SPC in merchant.com and communicates via backend to Bank for validation.
  2. Merchant takes responsibility
    2a) PSP conducts ceremony with WebAuthn or SPC in merchant.com and validates assertion. PSP and Bank can have a variety of agreements.

We can further clarify 1p and 3p scenarios:

  1. Bank takes responsibility
    1a.i) In 1p context, Bank conducts ceremony with WebAuthn or SPC and validates assertion.
    1a.ii) In 3p context, Bank conducts ceremony with WebAuthn or SPC and validates assertion.
    1b) In 3p context in merchant.com, PSP conducts ceremony with SPC and communicates via backend to Bank for validation.
  2. Merchant takes responsibility
    2a) In 3p context in merchant.com, PSP conducts ceremony with WebAuthn or SPC and validates assertion. PSP and Bank can have a variety of agreements.

Note: I've not really heard speak of a redirect use case to the PSP 1p origin, so I don't list that here.

Today, there are two dialogs:

  • SPC: The (caller-claimed) merchant name and/or origin are displayed.
  • WebAuthn/FIDO: System-computed relying party information is displayed.

The question of this issue is: what would be most helpful to the user, and which dialog should display it?

For example:

  1. Bank takes responsibility
    1a.i) 1p on bank.com: "bank.com wants you to authenticate."
    1a.ii) 3p in merchant.com: "bank.com wants you to authenticate."
    1b) 3p in merchant.com: "psp.com, on behalf of bank.com, wants you to authenticate."
  2. Merchant takes responsibility
    2a) 3p in merchant.com: "psp.com, on behalf of merchant.com, wants you to authenticate."
    or perhaps: "psp.com and bank.com want you to authenticate."

Looking for guidance here. Thanks!
@ianbjacobs
Copy link
Collaborator Author

cc @stare893

@stephenmcgruer
Copy link
Collaborator

stephenmcgruer commented May 3, 2022 •
edited
Loading

I want to emphasize a point that is covered by Ian's post already (it's scenario 1a.ii), but is worth (imo) repeating:

Today in WebAuthn L2, one can have merchant.com embed rp.com in an iframe and rp.com can trigger WebAuthn authentication1. The browser/platform dialog for this authentication will not (and I believe does not have to, per the WebAuthn spec) show merchant.com inside it, only rp.com.

The rp.com iframe will not have a URL bar that shows the loaded origin. The iframe could be entirely invisible, or 1px tall/wide, or hidden off of the screen, or just visually look exactly like part of the merchant.com page. And it does not require the user to click on it (a 'user activation'), per the WebAuthn spec.

So despite having a different model (i.e., removing the need to embed rp.com in an iframe), the question of whom one is authenticating to from the users perspective doesn't seem much different in SPC versus WebAuthn in a cross-origin iframe.

Which doesn't mean we shouldn't make it clearer :). I do support a goal of better user understanding here.

1 Assuming the correct permission policy is set on the iframe, but that applies to SPC too.

@ianbjacobs
Copy link
Collaborator Author

Some feedback I received regarding this question in a 3DS context:

  • Bank A may use Company B for authentication
  • The Relying Party would be Company B, but it is easier to explain to the user that authentication is to Bank A.
  • For a 3DS/SPC authentication, it would make more sense to let the ACS provide the RP name

@ianbjacobs
Copy link
Collaborator Author

Question for discussion: where is information about "on behalf of" stored? For example, could it be stored at the CTAP level and recorded at registration? Or should it be passed at authentication time?

How does one get permission to authenticate "on behalf of" someone? Is a self-declaration sufficient?

@SensibleWood
Copy link

How does one get permission to authenticate "on behalf of" someone? Is a self-declaration sufficient?

I guess it depends if there is any external construct that might regulate the entity doing the authenticating. Interestingly (well you can be the judge of that) there is currently a move in the UK open banking standards to ensure that any "on behalf of" style authentication is captured as part of the Authentication Request or somewhere in the authorisation flow (the jury is out on how - some options better than others).

Question for discussion: where is information about "on behalf of" stored? For example, could it be stored at the CTAP level and recorded at registration? Or should it be passed at authentication time?

Personally I think it would be good to allow flexibility in setting an "on behalf of" value in case the relevant information changes (e.g. change of domain name, etc). If a change required the credential to be re-minted that would be a foil to usability. Of course that wouldn't be a problem if the "on behalf of" information was mutable.

@rlin1
Copy link
Collaborator

rlin1 commented Jun 27, 2022

Note that the assertion already allows the RP to determine the origin of the requester (see field "origin" in https://w3c.github.io/webauthn/#dictionary-client-data). Additionally the field "crossOrigin" is set if that differs from the RP ID.
With that the RP can already detect (and capture) and even reject cross-origin transactions.

@ianbjacobs
Copy link
Collaborator Author

Discussed at 25 April meeting. One idea is to ping the URL at a well-known URL to get a preferred name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
after-v1 WebAuthn liaison
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@stephenmcgruer @rlin1 @SensibleWood @ianbjacobs