Not for the Internet as a whole

The reason why Moonshot is not directly suitable for use as a general authentication mechanism for Internet users in general is its reliance on a so-called Trust Router, a component that sits between the parties and that basically reigns over trust relationships between a client and a server. Such structures are not sufficiently distributed to blend in with the rest of the Internet, which decentralises control and distributes resposibilities as well as possible.

ABFAB Architecture

Moonshot implements the ABFAB architecture, which is designed to operate over GSS-API. This mechanism has always been designed to permit switching between alternative mechanisms for authentication and encryption, even it is long been used only for Kerberos.

What Moonshot uses is EAP over GSS-API; EAP being the Extensible Authentication Protocol. A common roll-out of Moonshot will interface to a backend by wrapping EAP in GSS-API towards the client, and into RADIUS towards the backend. A service therefore needs to wrap/unwrap GSS-API and RADIUS, but need not be able to do the actual authentication.

As a last component worth mentioning, Moonshot also integrates SAML support.

ABFAB Clients

To be able to authenticate with ABFAB, a client needs to be able to handle the additional EAP-over-GSS mechanism. To that end, it must implement a handler.

Many client applications already know how to do GSS-API exchanges, especially when they support Kerberos5 and when their protocol is SASL-protected or uses another form of GSS-API (instead of raw Kerberos exchanges). The applications may have bugs, effectively presuming that GSS-API equals Kerberos5, but this can usually be remedied reletively easy and this is indeed being done by the Moonshot development team.

It may be a while until all clients are fully suited to do Moonshot, but the mechanism has its merits.