Headless API

[matthewp]

Description

The current API is great, but misses use-cases such as:

• Server-to-server communication
• Scripting

In these scenarios there is no web browser for the user to authenticate with. However a user still might want to communicate over HTTP, authenticated.

Related Links

• Gemini, a protocol that achieves this via client certificates

[sbweeden]

I believe this might be out of scope for the WebAuthn WG. The WebAuthn API is a Javascript API for browsers, operated by humans. Further, the use of this API requires user presence, which is incompatible with the use cases mentioned in this issue.

[matthewp]

Humans use HTTP clients. But if this is only for a JS API, where's the proper place to bring up these use-cases?

[Firstyear]

You aren't meant to use webauthn in those cases. A human logs in with webauthn, gets a bearer token / cookie, then the browser uses that for interactions.

For scripting and server-to-server this also isn't a webauthn use case, this is for TPM's or other security primitives.

[matthewp]

The word "browser" only appears 12 times in the spec doc, whereas the word "web" appears 531 times. If this spec is truly only for a browser JS API then I would suggest making it explicitly stated in the abstract.

Happy to take this conversation to a more appropriate place if you'll just point me to it.

[arianvp]

FYI Apple uses headless webauthn in two places:

AppAttest for attesting apps against servers to avoid abuse: https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity

And https://datatracker.ietf.org/doc/html/draft-bweeks-acme-device-attest-01 uses WebAuthn challenges to attest device identity for requesting ACME client certificates for Apple MDM

https://github.com/brandonweeks/acme-device-attest-demo is a demo using Webauthn Attestations format to send a TPM attestation to an ACME server to get client certificate.

https://smallstep.com/blog/acme-managed-device-attestation-explained/ explains more

Maybe these can lead to inspiration for OP.

[arianvp]

I've also been working on an extension to OAuth to allow exchanging headless webauthn attestations for access tokens.
This allows using e.g. AppAttest to have iPhone Apps act like a confidential OAuth client

Though this work isn't published yet.

[nicksteele]

The word "browser" only appears 12 times in the spec doc, whereas the word "web" appears 531 times. If this spec is truly only for a browser JS API then I would suggest making it explicitly stated in the abstract.

That's because we use the word client generally to describe a browser in the spec. The word client appears a lot. Edit to add: it doesn't have to be a full-fledged browser, plenty of applications are capable of using WebAuthn from a non-browser context.

The most helpful link I can think of here would be for something like SSH with FIDO2, which is possible on Linux via OpenSSH 8.2p1 or later to use (and available in some other less-baked formats on Mac and Windows). One could think of some ways to configure ssh to use FIDO2 and then trigger additional actions after a user authenticates.

As others like Firstyear and Shane have mentioned above, a human is necessary within WebAuthn transactions (called ceremonies) so having M2M WebAuthn is out of scope.

Happy to take this conversation to a more appropriate place if you'll just point me to it.

We run the WebAuthn Adoption Community Group and encourage you to drop by with any questions or concerns regarding adoption and implementation.

[timcappalli]

FYI Apple uses headless webauthn in two places:

They use some data structures defined in the WebAuthn spec, but they are not using WebAuthn itself (the API).

[emlun]

Not quite duplicate, but significant overlap with: #1255

Indeed, many WebAuthn authenticators (FIDO CTAP2 ones in particular) can also be used outside of WebAuthn for server-to-server authentication and more. Unlike WebAuthn, CTAP2 allows for skipping the user presence test during authentication, so CTAP2 authenticators can be used for unattended authentication outside of a web browser. For example, I use a couple of YubiKeys to authenticate some automated backup transfers via OpenSSH between my machines.

The "scripting" use case is vague, but perhaps some of it (testing in particular) is already addressed by the user agent automation features?

Beyond that I agree this is out of scope for WebAuthn itself, which is specifically a web API.

[matthewp]

Closing as I guess this is not the right place to fix the DX problem of HTTP auth. If there are any pointers on where I should go next I'd love the advice, thank you.

[ve7jtb]

Like SSH it would be up to Gemini to define how CTAP credentials would be used. I don't know what if any standards process Gemini is part of. I agree that this would be out of scope for webAuthn.