Thinking in terms of proofs and Origins

[bblfish]

In a discussion with @csarven yesterday on Origin and Access Control Rules (AC Rules), I think I came to an interesting insight that should help simplify how we think about authorization. In short this covers the question that @elf-pavlik always asks: how do we take into account the agent that is sending the credentials from a different origin.

The trick is to think of the Guard as verifying two things

1. A Claim that it receives from the client with different content, such as:
   i. that the connection is controlled by some Agent A, with as proof the TLS certificate (for WebID-TLS)
   i. that the client is in possession of an Solid-OIDC token with a specific semantics
   i. that an Agent A, signed a header for a particular request at a particular time (HTTP Sig)
   i. that an Agent A has some attributes as submitted by another Institutional Agent and wants access to R
2. The Agent with the properties given in 1 is allowed the requested access to resource by checking the rules specified by the acl link header linked to from that resource.

I will look at the case of HTTP Sig, where the HTTP headers are signed by a Launcher App. The Launcher App can sign headers as requested by an App using Iframes as tested here. For each client the Launcher App can have policies as to what requests it will sign on which resources globally.

So let us look at the case when a Guard for a resource R on a solid server receives a signed HTTP Request req signed by an agent A listed as being allowed that mode of access. Let us add that request R comes via an origin O or even an agent identified by AppId. So to ground our intuitions a bit, here Agent A may be a human identified by a WebID or keyId for example and O would be a software agent.

The guard on receiving the signed HTTP request is essentially getting the following statement:

O says req .
req signedBy A .

For which it can deduce that

A says req .

And so O falls out of the equation.
Note that

• HTTP Signatures can be made to be the signing of a unique event at a precise point in time so as to avoid replay attacks.
• O does not fall out of all equations: the fact that O forwards and receives the request means that O can leak the information. So A may trust O to not leak, but the server may (for some reason) not trust O. Still the problem here is to do with information flow, not with whether A made the request.

How would this work with Solid OIDC?
I think this can be formalized very cleanly with Abadi's logic of saying-that, but it is also really quite intuitive.

[csarven]

My consideration was taking authentication and authorization as decoupled components (by default) where the Guard provides information from authentication to authorization eg. when an entity's (organism, machine, ..) identifier (or any other parameter) is provided as input to authorization, it is assumed to to be authenticated - for all intents and purposes. The authorization system doesn't normally question or doubt the inputs. So, any parameter (whether the input is agent's WebID, the Origin value or something else) that can be used by the authorization component is taken "as is" - but that's of course not a rule. In the case of the Origin header, I figured that signing the HTTP message may be one way to ensure who/what is making the request, but it could be some other way. This is beside the point on Origin's purpose or flexibility to what's desired.

[bblfish]

We should not as engineers presume we know ahead of time where the joints in the system are best placed, what they are, how and what they communicate. We of course don't start from nothing either: we know that there is a distinction between authN and authZ. But they may be interacting in ways more subtle that what we initially thought of. So I am saying we need to keep an open mind here. In terms of logic it helps to be explicit about what is known.

This comes up with Cross Origin requests, which covers most Solid Apps. This is really difficult to get a good grasp on because of the complexity of the CORS standard, and so being explicit here is really helpful.

So it is is not enough for the Guard to know that A made the request req. If the Origin header is to have any value, it should be interested in knowing at least that A made the request via O, or that O made the request, but it was signed by A. Keeping that in mind makes it much easier to see what proofs the guard needs to look at.

So my thought was that for a read req R signed by A the access control rule

[] acl:accessTo <doc>;
    acl:mode :Read;
    acl:agent :A .

should allow it to go through, but not a write request W signed by A.
The origin information falls out because the request is signed by A.
On the other hand if we are looking at information flow control then it could make sense for the server to specify that certain intermediaries are not allowed to read the data, and that is where the client "Launcher App" signing the Origin may be useful, and the server could create a list of apps that are not allowed access. But how would that be expressed?

[bblfish]

I think this is related to the question @elf-pavlik asked on gitter on May 03 21:39 CET

What would happen if user would want to switch identities while using the same application? Would all WebID documents include that application's public key?

The Launcher App would only sign headers for requests that the user had allowed the App to reach using one of the user's keyid.

The App can be identified by the Origin, a header the Launcher App could sign. If the App also wants to authenticate, that would be possible too, and it could add another signature to the HTTP headers using the method described in the IETF spec. But I am not sure which use cases would require it: the Launcher App (or Wallet's (Authorization?) Agent equivalent in SSI talk) is the one making decisions as to what key can be used for a given resource for a given app.

In any case: the Launcher App can sign different requests with different keyids allowing the user to switch identities.