@Goosth and I believe others have pointed out that it would be great to reduce tracking risk by not reusing the same SPC Credential IDs across transactions. Here is an idea:

1. At enrollment, the relying party provides a public key in addition to other data (e.g., display
   information, relying party ID). The relying party associates this public key with the SPC Credential
   Identifier they get back through enrollment.

2. At transaction time, the relying party prepares input for SPC (either for someone like a PSP or their
   own usage) by encrypting a hash of an SPC Credential ID along with a time stamp (for example).
   The relying party ID and encrypted blob are provided as input to SPC.

3. The browser follows this algorithm (or similar):

   • Create a list of all SPC Credentials that have the relying party ID. If none, silently fail.
   • For each SPC Credential, get the stored public key. Use it to decrypt the encrypted blob. If the
     SPC Credential ID in the blob matches this SPC Credential's identifier, proceed to authenticate
     based on this SPC Credential.
   • If nothing matches, silently fail.

This is a rough idea; I look forward to hearing suggestions to make it realistic and effective.