Reconsider pros and cons of advertising the Registry Set in user's WebID

[elf-pavlik]

SAI does an excellent job of minimizing unintentional disclosure of information. Currently, Solid+SAI only requires WebID to advertise:

• solid:oidcIssuer (Solid-OIDC)
• interop:hasAuthorizationAgent (SAI)
• interop:hasRegistrySet (SAI)

Requiring the interop:hasRegistrySet may not be fully justified. It leads to the disclosure of the location of a very important resource, giving minimal benefit. It pretty much only sits there for the very rare occasion when the user wants to change their Authorization Agent. As a matter of fact, it only optimizes that rare experience by not requiring the user to manually provide the location of their Registry Set to the new Authorization Agent.

I think that this tiny optimization for the already relatively rare occasions doesn't really justify the requirement to advertise it in the user's WebID Document.

[michielbdejong]

Interesting! So in a scenario where a user has one WebID and 7 storage pods, how are those pods discoverable?
I thought we were still listing pod roots publicly in the WebID document and I had a conversation on Friday with @janschill and Theo about whether there should be some private registry where these 7 storage pods are listed, but that an app can only discover after the user already "logged in" to the app.

It seems it should be possible to only announce the idp and the auth agent, and keep everything else secret until the user authorised the app.

So yeah, specifically to this question, it sounds like it should be possible to have an 'Authorization Agent Picker' app, and after you 'log in' to it, that app is then allowed to discover your registry set, but not before that.

[elf-pavlik]

Interesting! So in a scenario where a user has one WebID and 7 storage pods, how are those pods discoverable?
I thought we were still listing pod roots publicly in the WebID document

The Registry Set is publicly advertised, but only the user's Authorization Agent can access it. This already provides a better level of privacy since the number and location of all individual storage instances are NOT advertised publicly.

It seems it should be possible to only announce the idp and the auth agent, and keep everything else secret until the user authorized the app.

This is already the case, with the only exception of publically advertising the location of the user's Registry Set. I'm proposing here that we stop doing it and trade-off tiny convenience, only applicable when switching to another Authorization Agent for tightening information disclosure even further.

So yeah, specifically to this question, it sounds like it should be possible to have an 'Authorization Agent Picker' app, and after you 'log in' to it, that app is then allowed to discover your registry set, but not before that.

TBH I think we need a dedicated WebID Provider, which is distinct from OpenID Provider! It should provide Two-factor authentication and practically only allow modification:

• solid:oidcProvider (Solid-OIDC)
• interop:hasAuthorizationAgent (SAI)

Both are important anchors of security and if someone can alter them they gain full access to all the user data! I think that grants them special treatment, like 2FA and not being exposed via Solid Protocol.

Anything else should be handled by https://github.com/solid/webid-profile as a separate document and in this case exposed via Solid Protocol.

[woutermont]

[@elf-pavlik:] As a matter of fact, [advertising interop:hasRegistrySet] only optimizes that rare experience [when the user wants to change their Authorization Agent] by not requiring the user to manually provide the location of their Registry Set to the new Authorization Agent.

I agree. Moreover, even without advertised Registry Set, the experience of changing Authorization Agent (AA) should probably not include manually provisioning it: the new AA could simply request access to the value via the old AA.

---

Aside: the same reconsideration could be made for the OIDC issuer. As long as the Authorization Server can access the value, user authentication can be done during interactive claims gathering, hiding the issuer from the public eye (issue).

[tomhgmns]

We're moving towards a WebID document in which only the issuers are visible. If you get a token from one of the issuers, you can send it with the GET request to the profile document and get a list of the storages as well. In other words, a WebID document in use.id will have a public and private part.

[elf-pavlik]

That sounds like you are moving some responsibilities of the Authorization Agent to the WebID itself.
I think there are many benefits of keeping WebID minimal and simply relying on interop:hasAuthorizationAgent to delegate authorization-related responsibilities there.