[webauthn] User friendly credential ID string for troubleshooting (#2256)

timcappalli has just created a new issue for https://github.com/w3c/webauthn:

== User friendly credential ID string for troubleshooting ==
## Proposed Change

Troubleshooting WebAuthn with end users can be difficult, especially remotely (e.g. a chat or call). Most WebAuthn credential identification done today is via either user-provided friendly names, or automatically generated names based on AAGUID. This isn't super useful to support folks when troubleshooting as they don't uniquely identify the credential to both the user and the RP support staff. Today, the only other real option is for an RP ID to show the credential ID, and authenticators would need to do this same. Credential IDs are variable in length and are often long, making them not very user friendly.

A basic method would be to concat the RP ID and credential ID, SHA-256 hash it and then return the last 6 characters.

`sha256(rpId, credentialId)`

```typescript
import { createHash } from 'crypto';

const concatenateAndHash = (str1: string, str2: string): string => {
    const concatenatedString = str1 + str2;
    const hash = createHash('sha256').update(concatenatedString).digest('hex');
    return hash.slice(-6); // Get the last 6 characters
};

const result = concatenateAndHash("webauthn.io", "SwAuYQuh0LlVDdH7sQVsDQ");
return result;
```

Result: `b4c52f`

## Why define in WebAuthn?

While this change would not change the shape or function of the WebAuthn API, this string needs to be consistent across authenticators, clients, and Relying Parties, so defining the derivation of the user friendly identifier is important. WebAuthn is the logical home for this. The spec would simply define the derivation procedure above and potentially give this thing a name (e.g. "Key ID").


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2256 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 10 February 2025 19:25:51 UTC