remove "possible future" label from acl:trustedApp paragraph

[michielbdejong]

In today's community meeting, we decided to go ahead with the acl:trustedApp system, so we should reword https://github.com/solid/web-access-control-spec#possible-future to say that it's currently part of the spec.

[gobengo]

It seems like a good idea to pursue. I think the 'reword' part is important to make the text normative. So it's a bit more than just removing the "possible future" label as the title here might imply.

[namedgraph]

Please don't pollute the WAC namespace with Solid-specific terms.

WAC quite clearly defines permissions for the document space.

However "applications" are another dimension, strictly orthogonal to documents. Therefore mixing acl:trustedApp with the existing document-space terms makes no sense.

Please choose a namespace (under https://solid.inrupt.com/ ?) different from acl:, and a separate ontology that imports acl:.

[michielbdejong]

Please don't pollute the WAC namespace with Solid-specific terms.

But acl:trustedApp is not Solid-specific, it's WAC-specific. I thought there was a 1:1 relationship between http://www.w3.org/ns/auth/acl# and this spec? Is the WAC spec not the only user of that namespace?

[namedgraph]

The WAC ontology homepage is https://www.w3.org/wiki/WebAccessControl.
This spec is clearly under Solid's documentation.

As I explained, acl:trustedApp is orthogonal to the rest of terms and therefore out of place.

[michielbdejong]

oh bummer so then we have two competing WAC specs. I see that https://www.w3.org/wiki/WebAccessControl calls it acl:trustedOrigin instead of acl:trustedApp.

We should definitely merge https://www.w3.org/wiki/WebAccessControl and https://github.com/solid/web-access-control-spec into one.

@namedgraph are you aware of anyone using the acl:trustedOrigin predicate in production?

cc @RubenVerborgh

[namedgraph]

I don't know where the trusted stuff comes from because it's not in https://www.w3.org/ns/auth/acl

And no I'm not aware. As far as I'm concerned, the core of WAC is Authorization, Mode, accessTo(Class) and agent(Class).

[michielbdejong]

Interesting! And who apart from Solid are using https://www.w3.org/ns/auth/acl, then? So maybe we have three versions of what WAC is then, this github repo, the wiki, and the vocab document...

@namedgraph can you maybe weigh in on #51?

[kjetilk]

I must admit I'm still not confident about acl:trustedApp's scalability properties. Before that, ACL resource caching was quite easy to achieve, and ACL checking implemented on the top of that cache. With acl:trustedApp, I'm not sure how it will play out in practice, if we could end up in a situation where there are a lot of user profiles involved, and where caching could get messy, given that people edit their user profiles for many other reasons than ACL maintenance. Since ACL checking is something we do for every request, we need to be careful about it, and don't feel confident it will play out well at scale. It is possible that lazy checking will help, but also that there are sufficiently many cases where too much data needs to be fetched to allow for efficient ACL checking.

[michielbdejong]

@kjetilk This issue is about updating the spec text to match what we decided in March.

[kjetilk]

@kjetilk This issue is about updating the spec text to match what we decided in March.

Yes, I know, and I think we might have been a bit hasty, and therefore, it shouldn't be removed before we have some empirical evidence for its consequences.

[michielbdejong]

I agree with you that we should move to something better than what we have now, but keeping this document out of sync with reality is not going to fix it. :)

Is it ok with you if we merge #56, and then work on a more granular consent system in the vein of solid/solid-spec#176 or other similar systems we could now start proposing?

[kjetilk]

The question is really the process of deprecating things that have been implemented once it has been in the spec. If it says "possible future", then it is quite clear that it has been implemented as an experimental feature, so I don't think there is really a disconnect with reality in it, it is OK to implement "possible futures" as experimental features at any time.

But OTOH, we're not a working group producing a Recommendation here, I suppose removing it if we have seen it doesn't scale in a WG setting wouldn't be difficult to argue. So, I could live with merging #56, but I'd prefer not.

[michielbdejong]

ok, so you how about if we replace 'possible future' (which is factually incorrect) with 'experimental', which warns that it's probably more subject to change than some of the other parts?

[kjetilk]

Yeah, that works for me, if it works for others.

[michielbdejong]

Great! Updated #56