WebAuthn PRF extension

[agl]

I'm requesting a TAG review of the WebAuthn PRF extension

This extension lets WebAuthn assertions also contain secret keys for the decryption of data. With it, the confidentiality of data can be protected by a security key.

• Explainer: https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension
• Specification URL: https://w3c.github.io/webauthn/#prf-extension
• Tests: wpt/webauthn/createcredential-prf.https.html and wpt/webauthn/getcredential-prf.https.html
• Security and Privacy self-review²:
  • "What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?" This feature exposes randomly generated secret keys to a site for the site's use.
  • "How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?" This feature does not allow a site to store data as the output is always generated by the authenticator.
  • "Do the features in your specification introduce new state for an origin that persists across browsing sessions?" Yes, new state is added to the WebAuthn credential. Since the purpose of a WebAuthn credential is to sign-in, they perforce have to persist across sessions. This is ameliorated by having significant user-agent UI before they can be exercised.
  • "Do the features in your specification expose information about the underlying platform to origins?" This feature exposes whether or not a security key supports this extension, which is the minimum practical amount of information to expose to make the feature useful.
• Primary contacts (and their relationship to the specification):
  • Adam Langley (agl), Google
  • Tony Nadalin (nadalin), WebAuthn chair.
• Organization(s)/project(s) driving the specification: Microsoft, Google.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5138422207348736

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: we would like the implementation to see the light of day in a reasonable time-frame, but there are no critical external dependencies.
• The group where the work on this specification is currently being done: WebAuthn WG
• Major unresolved issues with or opposition to this specification: Mozilla objected to this extension in WebAuthn level two because (I believe) of charter scope. I understand that they no longer object since WebAuthn has been rechartered.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[MattMenke2]

The privacy properties are unclear. Is there a single random_oracle() exposed globally, which could then be used to track a user across sites? Are they scoped per-site or per origin? Are these persisted or not?

There's mention of this being UI gated, but neither the explainer nor the spec mention the UI, or what triggers it. Does the UI expose whether this feature is available before a user grants permission (e.g., only show a dialog if the feature is available), or is it just for the existence of a security key in general? Or does it reveal nothing?

A privacy section in the explainer would make the privacy properties of this proposal much easier to evaluate.

[agl]

The privacy properties are unclear.

Have added a section to the explainer as suggested. This extension doesn't change any of the privacy properties of WebAuthn so the PRFs are per-credential and credentials are still scoped to an RP ID.

There's mention of this being UI gated, but neither the explainer nor the spec mention the UI, or what triggers it.

This extension doesn't change anything about WebAuthn in that regard either. So sites trigger operations via Javascript calls on navigator.credentials as usual and the data is part of an assertion and thus behind the same ceremony as signing in.

During registration, if the user completes the ceremony and creates the credential then the site learns whether the authenticator supports the extension or not.

[MattMenke2]

Thanks, much appreciated!

[rhiaro]

@plinss, @atanassov and I reviewed this in our virtual face-to-face breakout today. Thanks for clarifying the privacy implications in the explainer. This seems like a useful addition to the API.