Security model

[chrysn]

We don't have to reinvent authorization models, but if we provide forms we should say more than "follow any link but only submit forms under same-origin policy".

See notes of today's design team meeting.

Rough idea:

Application provides to the CoRAL engine a set of tuples of

• maximum level of authorization (or the single level) it is willing to commit to for an action, and
• minimum level of authorization required from the form (which, in composite cases like external dictionaries, is the minimum of its parts).

Exemplary corner cases of that are:

• "Use any of my authorizations, but require the provider of the form to be authoritative of all resources that are being acted on". (That is assuming that there is internal consistency in the servers, and no server is trying to trick you to send a request to the server that that server component could not just send to itself).
• "Use no level of authorization other than the ability to send network requests (ie. any authenticated connection would use an ephemeral identity), but accept any form whatsoever". This is basically private browsing mode.
• "Use my bank credentials if the form is coming from my bank (because my bank would never fool me into filling anything out; note that input to the form also needs to come from me or an equally authorized source under the minimum rule), but you can use my 'payments up to 2€' credentials even for other sources, eg. anything that claims to be a device running a known coffee machine manufacturer's firmware, or anything in proven proximity".
• There is no set of authorizations a form provider could offer that would make me hand out the codes to the nukes (unless I've manually entered DEFCON 1 before).

[chrysn]

An aspect that occurred to me as a consequence of yesterday's meeting, which I don't think we have a model for yet, is this:

Applications need to describe whether resource they indicate "speak truth".
If a resource speaks truth, any of its statements are made with the full authority principal speaking through the key holder for the resource;
conversely, the key holder (server) must only produce representations which it trusts to be true.
When an application produces links to other resources,
even when they reside on the same server,
those can not be assumed to speak truth unless the link relation says so
(in which case the server has to be careful when producing links with that relation).

When a client obtains a resource from source A
and a different source B says that that resource speaks truth,
its statements are only spoken with the intersection of A and B's authorizations,
in other words, with the authorization of A reduced by all authorizations not in B's.

In particular, the .well-known/core resource needs to speak truth to bootstrap,
but the plain "hosts" relation does not transfer trust.
A pubsub broker's topic descriptions will be truth, the topics themselves not.

An application can also specify limits to a resource's truth content (eg. "all its statements of pattern X are true, of the rest I don't know"), this is what RD's security policies do.

Does this ring any bells for a trust model that we could refer to, rather than spelling it out? I haven't found anything in SPKI.