Secure Payment Request

[fabiancook]

Hi,

It would be great if we could implement secure payment request support in SimpleWebAuthn.

I have a demo of it working here:

opennetwork/logistics#19 (comment)

I'm leaning on generateAuthenticationOptions/verifyAuthenticationResponse to generate the challenge, and verify the response that comes back, with the payment response matching the shape, returning a PublicKeyCredential with a AuthenticatorAssertionResponse

A credential setup for secure payment requests is setup using the normal register process, with just the authenticatorAttachment + extensions options updated.

The only difference between a normal credential and the asserted payment one, is that the type given in the returned clientDataJSON, in the case of payments, it is payment.get instead of webauthn.get, allowing both these types let me use verifyAuthenticationResponse for payments as well.

If verifyAuthenticationResponse could accept more than the fixed type of webauthn.get, that would work, but, if we setup a dedicated generateOptions for a payment request, that would work better long run, as it has a slightly different shape to authentication but some over-lap.

[MasterKale]

Hello @fabiancook, I suppose it was only a matter of time before this came up given the latest news of the Secure Payment Confirmation spec becoming a Candidate Release:

https://www.w3.org/TR/secure-payment-confirmation/

I've been somewhat dialed into the Secure Payments Working Group and its overlap with WebAuthn via my participation in the Web Authentication Working Group. I knew that SPC and WebAuthn were similar, but it sounds like SPC only requires minor accommodations to work with otherwise WebAuthn-compatible code...

I'm going to start reading up on the SPC spec, if the two really are that close then maybe it's not so crazy to think that SimpleWebAuthn could also offer support for Secure Payments. I'd have to think about that use case and if it would make sense to bake into @simplewebauthn/browser and @simplewebauthn/server, or perhaps as new packages that import both respectively and then tweak the API for the Secure Payments use case.

[fabiancook]

With the registration, to register for a secure payment confirmation passkey, you can use the registration process that SimpleWebAuthn provides, however, the required options include using:

{
  extensions: {
      "payment": {
          isPayment: true,
      }
  }
}

The types given currently, do not support this:

export type GenerateRegistrationOptionsOpts = {
  extensions?: AuthenticationExtensionsClientInputs;
}

export interface AuthenticationExtensionsClientInputs {
    appid?: string;
    credProps?: boolean;
    hmacCreateSecret?: boolean;
}

I can see that both AuthenticatorSelectionCriteria and AuthenticationExtensionsClientInputs are extracted from typescript/lib/lib.dom.d.ts ... Which I guess means I am running into "Why is my fancy API still not available here?"

In my implementation right now I am just... doing some hacky type jumping to allow this..
https://github.com/opennetwork/logistics/blob/21134aa703f9aa4bfde552889c71205e2221cb45/src/listen/auth/webauthn.ts#L322-L340

I do see that the types for dom.ts are passing through tsmorph, adding a small change in:

const extendableTypes = [
    'AuthenticationExtensionsClientInputs'
]

// ....
types.map(type => {
    // ....
   if (extendableTypes.includes(type)) {
      const extendable = domSourceFile.getInterface(type);
      if (!extendable) {
        throw new Error(`${type} does not refer to an interface so is not extendable`);
      }
      extendable.addExtends("Record<string, unknown>");
    }
    // ....
}) 

Results in an input type that allows any extensions in the future... but means the outputs type would be hiding these unknown other properties

export interface AuthenticationExtensionsClientInputs extends Record<string, unknown> {
    appid?: string;
    credProps?: boolean;
    hmacCreateSecret?: boolean;
}

[MasterKale]

@fabiancook I was sitting in the Web Payments WG today at TPAC 2023 and was reminded of your discussion. I need to refresh my memory on all this, I wonder if opening up support for SPC might be as simple as extending the extension inputs, like this:

export interface AuthenticationExtensionsClientInputsFuture
  extends AuthenticationExtensionsClientInputs {
  payment?: { isPayment: true };
}

I'll play around with this idea a bit and see where it leads.

[fabiancook]

This wasn't mentioned originally, but one of the other issues I ran into was the checking for type.

I had cloned the repository today and had a go at this, I was just going to add expectedType for verifyAuthenticationResponse and that was going to be enough to get me past the non type problems.

type VerifyAuthenticationResponseOpts = {
  // ....
  expectedType?: string;
}

// ....
export async function verifyAuthenticationResponse(
  options: VerifyAuthenticationResponseOpts,
): Promise<VerifiedAuthenticationResponse> {
  // ....
  const {
    expectedType = 'webauthn.get'
  } = options;
  // ....
  if (type !== expectedType) {
    throw new Error(`Unexpected authentication response type "${type}", expected "${expectedType}"`);
  }
  // ....
}

I wasn't able to get project building locally, nor the tests running, so couldn't make a PR for this, but, the above would need to be implemented at some point to allow this to work.

Could even be

type VerifyAuthenticationResponseOpts = {
  // ....
  expectedType?: string | string[];
}

// ....
export async function verifyAuthenticationResponse(
  options: VerifyAuthenticationResponseOpts,
): Promise<VerifiedAuthenticationResponse> {
  // ....
  const {
    expectedType = 'webauthn.get'
  } = options;
  // ....
  if (Array.isArray(expectedType)) {
     if (!expectedType.includes(type)) {
      const joinedExpectedType = expectedType.join(', ');
      throw new Error(`Unexpected authentication response type "${type}", expected one of: ${joinedExpectedType}`);
     }
  } else if (type !== expectedType) {
     throw new Error(`Unexpected authentication response type "${type}", expected "${expectedType}"`);
  }
  // ....
}

[fabiancook]

#436

Here we go, I haven't added tests for it, as above, but theres at least a thought towards it and some maybe progress.

[MasterKale]

Hello again @fabiancook, I glanced at Secure Payment Confirmation again today and I don't see a corresponding payment.create that would come out of a call to navigator.credentials.create(). Does it still make sense for verifyRegistrationResponse() keep its expectedType argument that was added in #436? I'm inclined to get rid of it because I don't see a need for it...

[MasterKale]

And I've added docs to the SimpleWebAuthn homepage to describe how to use expectedType when calling verifyAuthenticationResponse() to support verification of SPC responses:

https://simplewebauthn.dev/docs/advanced/secure-payment-confirmation