Authorization & Application Registrations

[woutermont]

As already pointed out by @RubenVerborgh, and also by @elf-pavlik, the extended profile documents, type indexes, and public storage triple, as specified in the WebID-Profile draft, are not well constructed to be compatible with decent authorization mechanisms, from the perspective of consistency, interoperability, performance and privacy. The crux here is, as @RubenVerborgh so finely put:

[T]he whole design is starting to be based on a permissions model, whereas permissions are supposed to be orthogonal in Solid.

The SAI spec is, on that account, less tightly bound with authorization, using a small dynamic discovery mechanism called Agent Registration Discovery that points each application to its own entrypoint into the user's data, leaving other applications blind as to what other apps/data the user has. In fact, these registrations themselves have a lot of similarities with the vague outlines of the app-discovery proposal in this repo.

I would therefore propose:

• that these authorization considerations are discussed in a separate document, together with people from SAI;
• that such a discussion centers on the idea of application registrations;
• that any discovery mechanism remaining in this spec should be based on that idea.

EDIT: see #62 (comment) for what might be a better rephrasing of the core idea.

[jeff-zucker]

I agree that how an app gains authorization should be orthogonal and that the webid-profile spec should refer to other specs in that regard.

I also agree that how permissions are granted (e.g. ACL/ACP) should be orthogonal.

I do not agree that the webid-profile spec should ignore the overall question of
permissioning. We will address (possibly non-normatively) seeAlsos, preferencesFile, etc. because these exist and are depended on by many existing apps. We will be re-writing current sections and you're welcome to critique those when they come out.

[woutermont]

@jeff-zucker I think you should first read #66, since I believe it is useless to call anything "the webid-profile spec" as long as it does so many things together.

I do not agree that the webid-profile spec should ignore the overall question of permissioning. We will address (possibly non-normatively) seeAlsos, preferencesFile, etc.

What I would like to indicate is not necessarily that these triples cannot be addressed, but rather that these triples should serve a single purpose: either they are some kind of permissioning system, OR they are some kind of social media profile system; trying to be both goes against orthogonality. We can build a social media profile system on top of a permissioning system, but this spec has to choose which of the two it is, and not bother with the other.

[jeff-zucker]

I believe it is useless to call anything "the webid-profile spec" as long as it does so many things together

I call it the webid-profile spec to because that is the current name of the repo. If and when its name changes, I'll call it that new thing.

We will be re-writing current sections and you're welcome to critique those when they come out.

About this: that is not how writing specs in a CG works.

What I meant was we will be submitting PRs and welcome your input on them. And that is very much how CG works.

[woutermont]

My apologies for the nit-picking. I was triggered by the we-versus-you wording, but that's not something we should have to go into here. I marked my comment as off-topic.

---

[@jeff-zucker] I do not agree that the webid-profile spec should ignore the overall question of
permissioning. We will address (possibly non-normatively) seeAlsos, preferencesFile, etc. because these exist and are depended on by many existing apps.

[@woutermont] I believe it is useless to call anything "the webid-profile spec" as long as it does so many things together

[@jeff-zucker] I call it the webid-profile spec to because that is the current name of the repo. If and when its name changes, I'll call it that new thing.

Let me then rephrase my point this way. The triples used in the (current) WebID-Profile draft, e.g. seeAlso and preferencesFile, are used to achieve too many things at once that should in fact be treated orthogonally. I therefore propose to split the spec into a (new) "Application-Registration" draft, specifying a level of application-based privacy barrier, and a (new) "RDF-Profile" draft, specifying some kind of social media profile system. The current triples can be used by one of them, but not both, unless this causes no compatibility issues (as they currently do, as pointed out by @RubenVerborgh, and also by @elf-pavlik).