Work on a long-term solution where applications have a mechanism to ask users for access to data
The question was (paraphrasing): How do we facilitate this work? This is an issue born from that question, with a proposal. We at inrupt have created a new label named application-acl, and propose to apply this label to all issues in this repo that are related to the work (and discussions in general) that are related to the aforementioned long term solution.
application-acl is an internal label we've used on this, and we're not married to that name; please suggest other names you think cover this topic better.
You need write-permissions to this repo to apply the label, which is problematic, but I hope we can live with that until we have a better solution. There are several people with access to this repo, so I think we can live with the fact that the label might not be applied on issues when initially created. (Please mention that you want to have it labelled if you think it won't be apparent enough.)
We could create a separate repo for this work, but I believe it's better to flesh out some user stories and have broader discussions on this before we decide how we want to organize this work in one or more repoes.
Please create as many issues as you think are needed, reply to this thread if you have questions or want to discuss what is proposed here, or discuss it on the public mailing list if you think that's more appropriate.
In the Solid Community Group meeting March 7th there was a topic on strict origin checking and the implementation of the proposed feature
acl:trustedAppin the Web Access Control specification. The decisions that the team at inrupt put forth was accepted, but there was a question reg the third point:The question was (paraphrasing): How do we facilitate this work? This is an issue born from that question, with a proposal. We at inrupt have created a new label named application-acl, and propose to apply this label to all issues in this repo that are related to the work (and discussions in general) that are related to the aforementioned long term solution.
application-aclis an internal label we've used on this, and we're not married to that name; please suggest other names you think cover this topic better.You need write-permissions to this repo to apply the label, which is problematic, but I hope we can live with that until we have a better solution. There are several people with access to this repo, so I think we can live with the fact that the label might not be applied on issues when initially created. (Please mention that you want to have it labelled if you think it won't be apparent enough.)
We could create a separate repo for this work, but I believe it's better to flesh out some user stories and have broader discussions on this before we decide how we want to organize this work in one or more repoes.
Please create as many issues as you think are needed, reply to this thread if you have questions or want to discuss what is proposed here, or discuss it on the public mailing list if you think that's more appropriate.