Skip to content

WebAuth

Jump to bottom
Martin Paljak edited this page Aug 21, 2017 · 20 revisions

This is the background story. For a better understanding, read also the developer tutorial and OpenID X509 ID Token specification

TL;DR

The purpose of this effort is to define a simple challenge-response authentication mechanism for PKI (X509) roll-outs, with a standardized token format for transporting the claim and a standard API for website developers to request for that authentication token, to overcome a set of issues present with client certificate authentication in the web context.

Background

For various reasons (poor UX, ignorance from browser vendors, missing support on mobile platforms, server configuration complexity etc) using TLS CCA (Client Certificate Authentication) for end-user authentication with eID smart cards is not feasible in the long run, even if this type of session establishment has desirable security properties (like implicit MITM protection via mutual authentication).

Current alternative efforts that have potential horizontal reach, seem to focus around IdP-s (3rd party on-line service providers, OAuth etc), XML based schemes (SAML2, ISO 24727 etc), low level "PKCS#11 style API-s" or require an all-in commitment to a very different scheme like FIDO. Initiatives like WebCryptoAPI have failed to deliver, no support for existing infrastructure (hardware tokens with pre-distributed, cross-origin keys) is planned.

Having simple, web-scale implementations means omitting overly complex architectures and XML in favour of JSON and one of the requirements for a fail-safe solution is to be able to function in a "peer to peer" fashion, without a dependence on an on-line third party.

The situation is comparable with the mess of online signature schemes, a fragmented zoo (retired Java applets, ActiveX components, NPAPI plugins, native messaging extensions, localhost services etc, all with different interfaces on different platforms) where there do exist implementations right now that implement some sort of authentication capabilities, but there is no visible standardisation effort, thus the inevitable NASCAR problem

Thus it seems sensible to define a challenge-response authentication scheme that relies on client-side capability of providing JWT ID tokens with authentication information to websites, and to define requirements for client-side and server-side implementations.

This does make the server-side a bit more complex, but also more transparent, as the authentication step is more explicit than with TLS, which is often implemented implicitly in an off-loading appliance and not in the application domain itself.

The outcome of this effort will be a JavaScript library/API for website developers to call, to get browser extension generated JWT ID tokens, signed by PKI eID smart cards with X509 certificates. Similar tokens could be issued by a locally running self-hosted OpenID Connect provider

Use in Estonia

The scheme has comparable security to Mobile-ID authentication, with similar challenges (proper session management). Usability is even better, because does not require matching of the control code and the token by definition includes values to be generated and checked by the RP (unlike the DigiDocService interface for Mobile-ID).

In fact, the same token format could should be used for Mobile-ID.

Other protocols

Challenge-response, based on PKI, with various "assertion serialisation formats".

Banklink

Mobile ID

Smart ID

WebAuthentication (FIDO)

SignWise, isign.io, lvrtc.lv etc

  • Undefined raw access to authentication key for signing something.
  • No defined inputs nor no defined way of interpreting the output

Links

Clone this wiki locally