Use WAC ontology for authorizing authentication

[bblfish]

Currently we have been using the WAC ontology to allow the resource Guard to decide whether a given request is allowable.

But @elf-pavlik and @justinwb and others have regularly brought up another form of authorisation in calls: client authorization. The idea is that a user may wants to limit where a client is authorised to authenticate to. For example: trying a new app, one may be comfortable at first only allowing it to access some part of one's Solid pod. Later one may be happy to extend it to larger spaces. Another example: One may be happy for a banking app to work with one's banks, but not elsewhere. etc... These types of use cases of course are client side authorizations - authorization to authenticate - not server side authoritations: authorizations to access.

We want to limit which agents access which set of resources in what modes, but from the perspective of a Wallet handing out signatures.

So in the case of the Launcher App - which is just a specific Self Sovereign Identity Wallet - the LA needs to decide when to sign an HTTPSig header for a client. So it needs to look into a database of rules for the App, presumably published on the user's POD.

Rules could be

<#clientRule1> wac:accessToClass </testing/app1/*>;
        wac:agent <http://example.app/photoeditor/> ;
        wac:mode wac:Read, wac:Write .

(here I am assuming we have a way to describe sets of resources and their children, that would replace the use of *).
The above rule should not be confused with the rule linkedto via the Link: <.acl>; rel="acl" header, from resources inside </testing/app1/*>. Those could just refer to the agent directly without any mention of the apps (s)he wishes to use, and only describe them indirectly by key.

<#serverRule1> a wac:Authorization;
    wac:agent [ cert:key [ cert:modulus "...."^^xsd:hexBinary; cert:exponent "..."^^xsd:int ] ];
    wac:mode wac:Read, wac:Write;
    wac:default </testing/app1/> .

This rule used by the Guard, need not worry at all about what client is requesting access. And that is a good thing, because we want to people to choose clients easily without having to update access control resources everywhere on the web. It should be up to the user's Wallet (a.k.a keychain) to decide what signatures to give out to which apps, by applying rules written out and accepted by the user.

[bblfish]

The good thing about discussions here is that they are threaded, which should make it easier to follow conversations. Here is a thread to keep track of other relevant aspects of the discussion.
I wrote up WAC issue 101 just pointing to this discussion as a hook to later report back on what comes up here.

[elf-pavlik]

These types of use cases of course are client side authorizations - authorization to authenticate - not server side authoritations: authorizations to access.

I see them as authorizations to access not 'authorization to authenticate'. To be more precise End-user is delegating subset of their access rights to some Client (application) they use. So we have case of access delegation. Client is only authorized to access the subset of resources, access to End-user delegated to the client.

we want to people to choose clients easily without having to update access control resources everywhere on the web.

agreed with this specific part of that statement.

This rule used by the Guard, need not worry at all about what client is requesting access.
[...]
It should be up to the user's Wallet (a.k.a keychain) to decide what signatures to give out to which apps, by applying rules written out and accepted by the user.

I can see this proxy approach as a path to explore, at the same time this is only one of possible approaches.
Currently I'm focusing on delegation based approach where both End-user and Client are authenticated. End-user uses dedicated party they can choose to manage what access they delegate to the client, but it doesn't require proxying requests.

[bblfish]

@elf-pavlik wrote:

I can see this proxy approach as a path to explore, at the same time this is only one of possible approaches.
Currently I'm focusing on delegation based approach where both End-user and Client are authenticated. End-user uses dedicated party they can choose to manage what access they delegate to the client, but it doesn't require proxying requests.

You could call it proxying but it really is the Wallet signing individual http requests for the client to use. Seems pretty much like the philosophy of OIDC, except

• we don't just have tokens signed which could be re-used maliciously, we have the request signed including the mode of access, which can't be replayed
• the app does not need to fetch tokens from a remote server and so be limited by the speed of light. Rather the App can just make a browser level connection to get the header signed, which is immediate in comparison.

Do you have your approach written up somewhere? Note that it too will only one of many possible approaches :-)
The advantage of this proposal is that it cleanly separates the two forms of authorization: a) on the client and b) on the server
And it proposes to re-use the ontology already used on the server, so that we avoid re-inventing concepts.

[woutermont]

Seems pretty much like the philosophy of OIDC, except

• we don't just have tokens signed which could be re-used maliciously, we have the request signed including the mode of access, which can't be replayed

So in fact it is a lot like DPoP?

[bblfish]

@woutermont

So in fact it is a lot like DPoP?

I don't know DPoP well, so I don't know how much DPoP pulls in of requirements from other areas of OAuth.

It is similar, except that HTTP-Sig is only relying on HTTP Message Signatures which just had a new release yesterday btw! I have implemented the version from 4 months ago, in Reactive Solid. All the rest is pure RESTful Solid stuff.

[acoburn]

So in fact it is a lot like DPoP

Yes, very similar. Both approaches bind the access token to the specific request so that it cannot be replayed on a different resource (Pod) server.

[woutermont]

@bblfish, can you elaborate on how browser clients (SPAs in particular) would sign those requests? As I understand it, they would need to have posession of some private key, which they cannot in an insecure environment. But I'm not yet familiar with HTTPSig, so maybe I'm missing something here.

[acoburn]

I am also very interested in how this would work for an SPA. When interacting with an in-browser wallet that is able to manage private key material, the flow is pretty clear.

[bblfish]

I wrote an SPA client in ScalaJS 6 years ago (already!!) where the client created its own key and saved these using JS-Crypto-API in the local storage. The App would then have to link the public key to your WebID. That works if you trust the client not to send the keys on to other end points, and you then have to trust it for everything as the app then has all the rights you have.

So that would not work for non-trusted apps. But it would work for your most trusted App: your Launcher App that could then sign headers for other apps via Window.postMessage following rules I explained above.

That is just the best way to get things going. Other possibilities are:

• develop a plugin for the browser
• build it into the browser
• use a proxy on your Pod that signs the requests made by the app

All those three options can use exactly the same WAC rules/policies as I suggested above for the Launcher App.

[elf-pavlik]

So that would not work for non-trusted apps. But it would work for your most trusted App: your Launcher App that could then sign headers for other apps via Window.postMessage following rules I explained above

Do you have small snippets showing exactly how one app would sign http requests of an another app?

[bblfish]

I don't have code that signs headers for another app. But I could try that out next month.
But I do have code that shows how a client frame can request information from a parent one:
https://github.com/bblfish/LauncherApp

[mfosterio]

Could ideas from the Confidential Data Storage project help out? https://identity.foundation/confidential-storage/ What are your thoughts on WebID-DIDs in this scenario? https://github.com/decentralized-identity/ethr-did-resolver Also how do CRDTs fit? Could data write locally and utilize methods of syncing up to LDP using libraries like LevelJS? It would be interesting to see CRDTs that help increase scalability and persistence but be controlled by the WAC agent in the client side application as well. You could even sync the changes in ACL first with Service Workers and Background Sync when users that live in countries with poor internet utilize Solid Protocols.

[mfosterio]

The encrypted data vault on the client side is important to think about https://digitalbazaar.github.io/encrypted-data-vaults/ as mentioned in this TPAC breakout session.

https://www.youtube.com/watch?v=DdnREB-oYr4

[bblfish]

Thanks for the pointer. 15min in Dimitri points out in the video that encrypted data vaults can be used to store keys, credentials etc... and that looks like it would be very useful tool for a Wallet App to use to store its own keys. For Solid deployments on a Freedom Box we can get going I think without needing to wait for that spec to be finished.

The HTTP Sig authentication protocol is open to DID usage, by the way.

I will need to think through what role CRDT could play.

I hope I will be able to start a mini prototype of this proposal in October, so I should have a better idea of what it entails.

There are many different ways to implement a Wallet Agent that can use WAC descriptions to authorize Apps. And indeed I don't think the WAC ontology would constrain the type of authentications allowed either.

[elf-pavlik]

Last week we discussed during the call cases where the client runs somewhere 'in the cloud', as well as native clients which run on the user's device but not in a web browser. Suggested Window.postMessage() only takes into account cases where the client runs in a web browser.

[bblfish]

Yes, the Launcher App using Window.postMessage should work well for an important subset of apps: those running in the browser. That covers a very important set of applications.

As mentioned above and in the meeting, other authentication systems can use the same WAC descriptions to authorize authentication requests:

• Browser Extensions could have access to other APIs to do the same thing
• a solid POD proxy agent could use the same rules to decide on whether to sign messages from certain apps making requests to sets of resources - though here the proxy will be in direct communication with the server
• keychain/wallet apps on cell phones could also use the same rules to specify what requests from which apps to which resources will be signed in what mode
• ... other?

[bblfish]

As per @csarven 's request at last weeks Web Access Control Meeting I drew up a diagram to illustrate one workflow. I may add an other diagram later for some other workflows. There are 5 steps starting from the App requesting the Wallet Agent to sign a request header for it. Not all of the arrows require an HTTP connection. For example it is to be assumed that the Wallet has the rules for the App cached locally.