Consider the advantages of wACLs being readable by apps about authorization-panel HOT 12 OPEN

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

from authorization-panel.

Thanks @TallTed for the clarification. I made the changes and added some extra examples.

from authorization-panel.

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

👍 I think we could just add option to set explicit rule for the acl resource itself ('inside' of that acl) and keep current 'controller only' access as default behavior. Which would mean that applications should gracefully handle cases where they can't access ACL (eg. prompt user to select credential if they don't have existing active user session) and if they detect public ACL can use progressive enhancement strategy to offer some kind of dynamic credential detection.
Applications which require explicit 'log in' up front and establish single active user session this way, should not be affected in any way by this added functionality and can choose to safely ignore it.

from authorization-panel.

@elf-pavlik @bblfish Apologies i didn't catch this notification the first time around! I'm combing through the resource metadata pull request to make sure i haven't missed anything and just came across this.

I think @bblfish makes a good argument for cases where it might be beneficial to see an .acl without proof of control access first. Still, I do not think it would be appropriate to change the default behavior or expectation of the same from what it is today.

I think @elf-pavlik's proposal would be the right way to go about it, because that's something we could add that would be backwards compatible and not change assumed default behavior. That said, I think it would need to accompany verifiable credential support - otherwise it would seem like we're making a change without a use case to justify it.

from authorization-panel.

I think the acl should control itself as @elf-pavlik describes and that there should be an ACL control between stealth and detectable. Unauthorized access to the resources would yield:

As architects, we've been unable to decide between stealth and detectable because there is no single answer. Users may want finer-grained control than that but I think this covers most use cases.

from authorization-panel.

quibble -- the WG's name notwithstanding, "Verifiable Claims" (and "claims") should be changed to "Verifiable Credentials" (and "credentials") in most cases.

from authorization-panel.

I would be fine with allowing access to .acls as long as you are able to set who has access to them.

Ok so if wACLs can themselves have Link: rel=acl ... headers, then one needs to think this through.

For the client this is quite easy. On receiving an wACL document it will receive a header showing if it too has an acl, so that it can work out if it is allowed to edit it.

For the Guard the reasoning should be the same as for the client.

The open question is how someone with the correct rights would set the acl of an acl. This is a similar question as to how one sets headers for resources, and who is allowed to do so.

If we have wACL docs pointing to acls, is it that the current situation is that we implicitly have all wACLs pointing to themselves?

Answering these problems looks like a simple research project to me.

from authorization-panel.

The open question is how someone with the correct rights would set the acl of an acl. This is a similar question as to how one sets headers for resources, and who is allowed to do so.

I think acl document should contain rules to access itself. For consistency we might still require for them to have rel="acl" which MUST point to itself. In that case we don't have need for clients to manipulate relations exposed in HTTP Link header, we might still need to address it for some other requirement.

We could create PR proposing it after solid/data-interoperability-panel#32 gets merged. @justinwb how do you see discussion here turning into followup PR to your original metadata PR?

from authorization-panel.

If the rough rough rough consensus here is that an ACL need not have its ACL, then the proposal at solid/specification#184 would prevent servers from advertising a link relation.

from authorization-panel.

@justinwb wrote

I think @bblfish makes a good argument for cases where it might be beneficial to see an .acl without proof of control access first. Still, I do not think it would be appropriate to change the default behavior or expectation of the same from what it is today.

What is the expectation meant to be for a client? Is it that it won't be able to read the wACLs that is linked to in the header unless it already knows what the acl contains because it (or the user who owns the app) wrote it?

Apart from this being a very odd expecation to have, it creates the following problems:

1. It goes against the fundamental principle #73 on client server symmetry
2. as a result it pushes the problem elsewhere: for example requiring complex protocols to be developed to allow a client to work out if it has access rights to a resource (how can it do that without just guessing?)

from authorization-panel.

I think the problem is the following. If wACL documents have their own acl link relation how do you not end up with an infinite regress? Also how does this work with the current installed base?

The answer is quite simple and is what I implemented in rww-play.

A wACL document can have a link relation to itself by placing a Link: <>, rel="acl", indicating that it is the source of truth for itself.

One can see this to be the current behavior implicitly. It just happens that the current solid apps don't publish that link.

from authorization-panel.

ACP Proposal allows for setting access on Access Control Resource itself.

from authorization-panel.