Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorization & Application Registrations #62

Open
3 tasks
woutermont opened this issue Oct 23, 2022 · 5 comments
Open
3 tasks

Authorization & Application Registrations #62

woutermont opened this issue Oct 23, 2022 · 5 comments

Comments

@woutermont
Copy link
Contributor

woutermont commented Oct 23, 2022

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
Copy link
Member

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
Copy link
Contributor Author

@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.

@woutermont

This comment was marked as off-topic.

@jeff-zucker
Copy link
Member

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
Copy link
Contributor Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants