Improving understanding of who is authenticating for whom

[ianbjacobs]

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]

cc @stare893

[stephenmcgruer]

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 authentication¹. 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.

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

[ianbjacobs]

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]

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]

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]

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]

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