Should SPC be limited to passkeys with the payment bit set?

[ianbjacobs]

We have previously suggested (and Chrome has implemented) that a Relying Party should be able to use its own passkeys with SPC, even if those passkeys were originally generated for login use cases.

At our 22 May 2025 meeting we discussed the question of whether, at registration time, the browser should generate a BBK for a passkey that does not have the payment bit set. The sense from the meeting was "In any case, at registration time the browser has no way to return the BBK unless the payment bit is set." So for now the expectation is that a passkey will need to have the payment bit set to get back a BBK at registration time. (The browser will return a BBK at authentication time, whether or not the passkey has the payment bit set.)

This led us to the broader question: How important is the use case for an RP to use its own passkeys (without the payment bit set) with SPC? Should we just require that a passkey have the payment bit set to be used with SPC?

The Chrome Team let us know that that requirement would simplify the implementation.

A question was asked: if the passkey is generated without the payment bit set and the RP decides later it wants to use that credential with SPC, is there a way to update the credential for use with SPC? The Chrome Team will look into this question.