Integrating with SASL for webid authentication

The Soid ecosystem aims for decentralized web, in which users are in control of their data, and identity. To enable that, it uses WebIds as the primary identifiers for agents. The WebId Speciication describes it's motive as follows:

A global distributed Social Web requires that each person be able to control their identity, that this identity be linkable across sites - placing each person in a Web of relationships - and that it be possible to authenticate globally with such identities.

A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.). For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI referring to the Profile Document.

The profile document is an rdf document that contains asserted authoritative information about the owning agent.

There are few existing standards for services to perorm authentication against webids. The usual principle is: The profile document either contains a verifiable assertion about the owning agent, or authoritatively delegates authentication to external identity provider services. The service dereferences the profile document, and then verifies the provided credentials against asserted information to authenticate a user. Or, if the profile document links to any external identity provider services, then the service initializes corresponding idp flows (like OIDC), to assert user identity.

As of now, following standards are in active development.

WebId-TlS:

Is a transport layer level mechanism or TLS enabled services to authenticate, by matching the pub-key asserted in the provided client x.509 certiicate (possibly self-signed) against the pub-key asserted in the agent's webid-profile document. The method is PKI based, it can be used non interactively by bots and scripts. But has disadvantage that: It requires transport level muddling, and not straight forward to use with protocol level libraries.

Solid-OIDC:

Is a profile of general oidc. The mechanism is not purely for authentication, but also or authorizing a third party client to act on behalf of the user. As part of the mechanism, the agent links to an identity provider from it's profile document. A client can initiate oidc flow a relying-party, and can get an id-token from the idp, that rieies user's consent. And it uses the id token at authorization server to exchange for an access token to access resources at an associated resource server.

The process involves many browser rediects, and explicit involvement of the agent. Intended for using third party clients to interact with resource servers. It is difficult to be used offline by bots, scripts or other non interactive processes.

Unfortunately there doesn't yet exist a protocol-layer level standard to authenticate non interactively by bots, scripts, first-party clients, etc. WebId-TLS requires transport-layer level operations.

There are few draft specifications like HttpSig. But the work was stalled after late @bblfish. Currently it was drafted against very old http-signatures pre-rfc draft, and has many incompatbilities against the final rfc.

@bblfish was also trying to create a method to integrate the WebId into SASL ecosystem, so that there will be a pluggable framework for WebId authentication to use with existing SASL mechanisms, or to develop new ones. This seems a good way forward for following reasons:

We can reuse existing SASL mechanisms, and have a better framework to create new ones for WebId authentication.
Along with the web, WebId can be used as a linked agent identifier in sasl-compatible network protocols, where applicable.

To realise that, folloing need to be specified.

A profile of SASL, that concretizes few abstract notions of general SASL to integrate the WebId.
Extra requirements for SASL mechanisms to securely handle decentralized nature of WebIds.
Standardization of SASL authentication exchanges for http. Fortunately, this work had been already done at HTTP Authentication with SASL internet draft.

With those specified, we can then investigate on suitable existing mechanisms, and recommonded authentication flows for Solid ecosystem, etc.

> Profile of SASL

Though need to be fully investiigated, following few immediate extra requirements are somewhat obvious for WebId-SASL.

The SASL authentication identity and authorization identity values must be WebIds.
Services must treat the information in dereferenced WebId-Profile document as authoritative for the identity verification.
Only WebId compatible mechanisms as defined below are allowed.

> Extra requirements for WebId-SASL mechanisms

Due to the decentralized nature of WebId, not all SASL mechanisms can be usable with WebId-SASL. Following are a few observations:

As the public WebId-Profile doc is the only authoritative source of information about agent, no shared secrets between agent and services possible. Thus, all password based, or any kind of shared-secret based mechanisms are not usable. This rules out many of popular mechanisms like SCRAM.
The mechanism must provide a way to bind client-to-server proof exchanges against the server. Otherwise, a rogue service can play man-in-the-middle by reusing those exchanges at another service.

For example, the mechanisms specified by RFC3163: ISO/IEC 9798-3 Authentication SASL Mechanism seems qualify these requirements by being PKI based, and providing a way to bind c2s proof exchanges against server identifier.

> Standardization of SASL authentication exchanges for http

Already done at HTTP Authentication with SASL internet draft.

Once these are concretized, we can define standard flows to use with Solid resource servers as a first application.

solid / specification