2025-03 dev log

[michielbdejong]

Solid

• Fix consent information solid-contrib/pivot#38
• Milestone E8 case study (including Solid MVP) solid-contrib/data-modules#136

[michielbdejong]

Yay! This feels like a fun project for this week. I also want to add in the ecosystem tests that I started working on earlier this year IIRC.

[michielbdejong]

Ah yes, solid-contrib/ecosystem-tests#1

[michielbdejong]

And solid-contrib/ecosystem-tests#4

[michielbdejong]

I'll test this now with Pivot and empty-solid-app

[michielbdejong]

michielbdejong/empty-solid-app#3 done. It works with NSS and Pivot now.

[michielbdejong]

will dig into pivot.pondersource.com logs and find out why my ACL file is not working as intended - solid-contrib/ecosystem-tests#4 (comment)

[michielbdejong]

OK, so my understanding now - Solid is actually more broken than I thought, unless I'm missing something.

This would be a continuation of the work I started a few weeks after joining the Solid project (now almost 5 years ago) in solid/webid-oidc-spec#12 but it seems that this was never satisfactorily finished or properly implemented anywhere as far as I'm aware. So the big picture is this:

For authentication, you could use

1. direct interaction between WebID owner and storage, so for instance direct OIDC authentication, webauthn, WebID+TLS or username/password, resulting in for instance a cookie or a short-lived client-bound refreshable bearer token
2. DPoP to authenticate the agent but not the client
3. DPoP to authenticate both the agent and the client

In case 2., who gets to decide which clients are trusted? It's one thing to share your identity directly with a storage server, but another to share your identity with a client and then let that client act on your behalf through DPoP. But if the application is itself an agent and not (just) a client then it makes sense to whitelist this application by its WebID and not by its origin.

If we disable dynamic client registration at the IDP then it's basically saying that a given WebID cannot be represented by a dynamically registered client. Then a WebID can be:

• the pod owner
• another human or organisation with whom data is shared
• an application the pod owner uses to access their data (this might be blurry with the previous one)
• an application that another human or organisation uses to access the shared data

Ideally you would want arbitrary levels of delegation, but what we have in Pivot/CSS and in NSS is DPoP-on-storage, which means we get to specify up to two levels, namely one agent and optionally one client.

[michielbdejong]

And actually UMA doesn't change much here, since it still goes WebID -> OIDC -> DPoP -> UMA -> storage, so there is still a DPoP step.
And it's actually not that bad, we can work with the two-level system to implement data portability as well as data sharing, albeit that their combination would really require a third level.

The basis of Solid's security model is the ACLs (WAC or ACP), combined with WebID and OIDC. There are then four approaches:

• carefully list the WebID's that have access, but allow these agents to use any client they choose. This goes well with Fix consent information solid-contrib/pivot#38 or disabling dynamic client registration altogether (still allow a few trusted clients probably through those two mechanisms and/or through NSS trusted apps), and then the launcher app could set WebID's of apps as agents. Avoid use of acl:origin and acp:client (unlike current NSS and CSS behaviour which I think is a big footgun)!
• implement Match acl:origin with OIDC azp  solid-contrib/pivot#64 so that acl:origin becomes usable. This has the advantage that DPoP becomes meaningful and client-side web apps become doable
• let client-side web apps publish their WebID documents (but this feels quite messy)

[michielbdejong]

An application can have its own WebID, have its own backdoor way of getting its OIDC identity token from its IDP, and then use DPoP to present it. In fact an application would probably have a dedicated built-in IDP? And then DPoP makes sense!

Maybe I can create a single app-hosting server that acts as an IDP and OIDC provider for otherwise static client-side web apps. The interaction between this server and the app can be custom, and based on same-origin.

Ah, it would have to act as a proxy, otherwise the app could just be scraped and impersonated.

• OIDC to log into the app
• the app then uses its own WebID to access your storage on your behalf
• you trust the app not to cross-serve your data to other users, of course, but
• you can effectively restrict this app to a single folder

[michielbdejong]

-> solid-contrib/data-modules#137

[michielbdejong]

OK, unexpected plot twist, I finally understand that WAC has no way of identifying clients.
This means:

• I merged Circumventing Origin restriction with proxies solid/web-access-control-spec#34 (comment)
• Cancelled Match acl:origin with OIDC azp  solid-contrib/pivot#64
• the launcher app (relevant for this SDM milestone) should use web apps with their own WebID
• WAC-based Solid is incompatible with Unhosted Web Apps (!)

[michielbdejong]

Suggested a WAC spec change that could make it compatible with Unhosted. Still, not sure if I should put energy into that, or switch away from WAC-based Solid to work on other stuff.

[michielbdejong]

• Get CSS running with ACP on localhost
• Try adding an ACR with a PUT from https://github.com/michielbdejong/empty-solid-app or Penny

[michielbdejong]

$ pwd
/Users/michiel/gh/CommunitySolidServer/CommunitySolidServer
$ git diff config/default.json
[...]
-    "css:config/ldp/authorization/webacl.json",
+    "css:config/ldp/authorization/acp.json",
[...]
$ npm start
[...]
Could not create the server
ErrorResourcesContext: Could not find (valid) component types for config "urn:solid-server:default:AcrIdentifierStrategy" among its types, or a requireName

[michielbdejong]

Second attempt:

$ git diff config/default.json
diff --git a/config/default.json b/config/default.json
index 459dde98a..3b41537b0 100644
--- a/config/default.json
+++ b/config/default.json
@@ -16,7 +16,7 @@
     "css:config/identity/ownership/token.json",
     "css:config/identity/pod/static.json",
     "css:config/ldp/authentication/dpop-bearer.json",
-    "css:config/ldp/authorization/webacl.json",
+    "css:config/ldp/authorization/acp.json",
     "css:config/ldp/handler/default.json",
     "css:config/ldp/metadata-parser/default.json",
     "css:config/ldp/metadata-writer/default.json",
@@ -25,7 +25,7 @@
     "css:config/storage/key-value/resource-store.json",
     "css:config/storage/location/root.json",
     "css:config/storage/middleware/default.json",
-    "css:config/util/auxiliary/acl.json",
+    "css:config/util/auxiliary/acr.json",
     "css:config/util/identifiers/suffix.json",
     "css:config/util/index/default.json",
     "css:config/util/logging/winston.json",

[michielbdejong]

Right, that works!

• curl http://localhost:3000/ -> 200
• curl -X PUT -H'Content-Type: text/turtle' http://localhost:3000/.acr -> 201
• curl http://localhost:3000/ -> 401

[michielbdejong]

Now I need to author an ACR that restricts access to /bookmarks to:

• agent https://michielbdejong.solidcommunity.net/profile/card#me
• client https://some-bookmarks-app.com or https://some-other-bookmarks-app.com

And restricts access to the rest of this pod to:

• agent https://michielbdejong.solidcommunity.net/profile/card#me
• client mashlib or penny

[michielbdejong]

I can use this fixture as an example.

[michielbdejong]

Will continue with this next week