Proposal: Add `payeeName` as alternative to `payeeOrigin`

[stephenmcgruer]

EDIT: Updated after initial discussion indicated it would be better to have the choice of origin-or-name.

Background

In discussion with a partner, we have heard that they (acting as the Relying Party) do not always want to use an exact origin for the payee. Instead, there are occasions where they would want to instead display a 'real name' for the merchant, and are happy to have the name string signed over. That is not currently possible, as the spec says that payeeOrigin must be parseable as a URL and normalized to that URL's origin.

Proposal

1. Make payeeOrigin an optional field in the SecurePaymentConfirmationRequest dictionary.
   • This should be almost entirely backwards compatible, as existing callers must be specifying it already.
2. Add an optional DOMString payeeName field.
3. Change the logic to:
   1. If both payeeOrigin and payeeName are omitted or empty, throw.
   2. If payeeOrigin is present, parse it + throw on fail as before.
   3. For the transaction UX and clientDataJSON, show and include the two fields if present.

dictionary SecurePaymentConfirmationRequest {
    required BufferSource challenge;
    required FrozenArray<BufferSource> credentialIds;
    required PaymentCredentialInstrument instrument;
    unsigned long timeout;
    DOMString payeeName;
    USVString payeeOrigin;
    AuthenticationExtensionsClientInputs extensions;
};

Mock-ups

Quick mock-ups:

[stephenmcgruer]

I welcome input and/or corrections from @jcemer-stripe and @jeremywagemans

(And anyone else of course!)

[rsolomakhin]

Is there anything stopping us from jumping ahead to step 2? (Add a payeeName field and require at least one of the payeeName and payeeOrigin fields to be present.)

[jcemer-stripe]

I would prefer to keep a good semantics. Having an extra payeeName field that could replace payeeOrigin looks a better option.

Wondering what should happen if both are provided, should we display all together like "{payeeName} ({payeeOrigin})" in the user prompt and keep payeeName and payeeOrigin in the clientDataJSON?

[rsolomakhin]

Wondering what should happen if both are provided, should we display all together like "{payeeName} ({payeeOrigin})" in the user prompt and keep payeeName and payeeOrigin in the clientDataJSON?

This is a good idea!

[stephenmcgruer]

I think having two fields is not a bad idea, though unfortunately the existing payeeOrigin is marked required and so cannot have a default value I think (based on this). So currently callers would have to always specify payeeOrigin: '' (i.e., passing an empty string explicitly).

That isn't a deal breaker, just an fyi.

[rsolomakhin]

Is it possible to remove the required annotation from payeeOrigin in WebIDL and perform the OR check in a validation algorithm?

[stephenmcgruer]

Is it possible to remove the required annotation from payeeOrigin in WebIDL and perform the OR check in a validation algorithm?

Yes, and in fact it's actually quite easy. I was thinking of this the wrong way around - making optional fields required isn't backwards compatible, but making required fields optional is mostly. (The one caveat is if someone is explicitly checking for a TypeError when they leave out the field. A very rare edge case.)

So yeah, we could make payeeOrigin non-required, and do as Jean-Carlo suggests above.

EDIT: Adjusted the proposal.

[stephenmcgruer]

With the change to the proposal, this might now address https://github.com/w3c/secure-payment-confirmation/issues/48 partially or completely too.

[ianbjacobs]

@tblachowicz, would this address the issue you raised in #48?