I remember seeing conversations in the past about using OAuth2, but I couldn't find them now, so creating this issue about it now (but please feel free to mark this as a duplicate of an older issue if it exists).
As an alternative to our current webid-oidc flow, maybe we could use OAuth2 similar to how remoteStorage does it. But in a more follow-your-nose kind of way, because we don't want to specify which container names people should put in the root of their storage, and also sometimes the data you want to access with your WebID is not actually on your storage, but somewhere else, for instance on the pod of another Solid user.
An easy case is where the app wants to access a single resource, they can just request an OAuth scope made up of the resource URL followed by : and an r, w, a, and/or c, depending on whether they want read, write, append, and/or control access.
An app could also include a list of such scopes, as long as that list doesn't become too long.
The user could then grant/disallow each of those scopes individually in the consent dialog.
The above would be the base mechanism. An extra mechanism on top of this would be to request a scope like https://example.com/#:s (s for set), which means retrieve https://example.com/ and find triples like:
@prefix acl: <https://www.w3.org/ns/auth/acl>.
<https://example.com/#>
a acl:RequestSet;
acl:RequestSetContains <https://example.com/#1>.
<https://example.com/#1>
acl:accessTo <https://storage.com/foo/bar>;
acl:mode [ acl:Read acl:Append ].
So that would be an RDF document describing a set of access requests.
A resource could be included with different access modes in different access request sets.
The hope would be that a user could have an access request set like 'chat conversations', and chat apps that create new chats would also add those new documents in there, a bit like the private type index, but linked to access scoping considerations, rather than to RDF type considerations.
Footnote about the relation between write and append access: write access implies append access, so when requesting write access it's useless to also request append access.
I remember seeing conversations in the past about using OAuth2, but I couldn't find them now, so creating this issue about it now (but please feel free to mark this as a duplicate of an older issue if it exists).
As an alternative to our current webid-oidc flow, maybe we could use OAuth2 similar to how remoteStorage does it. But in a more follow-your-nose kind of way, because we don't want to specify which container names people should put in the root of their storage, and also sometimes the data you want to access with your WebID is not actually on your storage, but somewhere else, for instance on the pod of another Solid user.
An easy case is where the app wants to access a single resource, they can just request an OAuth scope made up of the resource URL followed by
:and anr,w,a, and/orc, depending on whether they want read, write, append, and/or control access.An app could also include a list of such scopes, as long as that list doesn't become too long.
The user could then grant/disallow each of those scopes individually in the consent dialog.
The above would be the base mechanism. An extra mechanism on top of this would be to request a scope like
https://example.com/#:s(sfor set), which means retrieve https://example.com/ and find triples like:So that would be an RDF document describing a set of access requests.
A resource could be included with different access modes in different access request sets.
The hope would be that a user could have an access request set like 'chat conversations', and chat apps that create new chats would also add those new documents in there, a bit like the private type index, but linked to access scoping considerations, rather than to RDF type considerations.
Footnote about the relation between write and append access: write access implies append access, so when requesting write access it's useless to also request append access.