Client can't determine if user has authorization to modify annotation

[azaroth42]

Clients typically display whether the current user can modify an annotation when presenting them to the user. The client might wish to present an edit button only when the edit is possible, rather than for every annotation on the chance that the user can edit it.

Currently there's nowhere in the model where this information can be conveyed.

[paolociccarese]

Are we just talking about modification or more? Or should the other aspects such as ‘deletion’ belongs to separate issues?

In Annotopia I've adopted the permission levels used by the Permissions plugin of Annotator.js http://docs.annotatorjs.org/en/latest/permissions.html plus one more feature related to commenting. Such feature records if an annotation can be commented on or not. In fact, there are cases in which commenting is not meant to happen.

[tilgovi]

I don't necessarily think considering an annotation to be the subject of a relationship with any representation of permissions is right. I've been embedding ACLs in annotations, too, but I often think about instead using capability URLs. These would have relationships to the annotations and be communicated alongside. These could live in Link headers for individual annotations, but I don't know how they might appear for each item in a collection. Is anyone doing anything like this with LDP?

[azaroth42]

Initial Proposal: If the current user has permission to modify the annotation, then this can be expressed by including PUT and/or DELETE in the http Allow response header when the annotation is retrieved individually.

A further solution would be needed for bulk retrieval such as paged search results.

[iherman]

Discussed at call (http://www.w3.org/2015/12/02-annotation-irc#T17-03-44) and the feeling is that we have to ask security experts to help us out with the best approach and we should not make security related decisions ourselves.

[nickstenning]

@iherman: we certainly agreed that we should consult outside the WG on how/if to consider access control as part of the protocol.

But let's not confuse authorization with authentication. It's very likely that any recommendation we make regarding authentication (if we even need to make any) will be to follow existing industry standards. But authorization may well be more complicated, and specific to the use cases of annotation. We're also less likely to burn our fingers on authorization/access control than we are on authentication.

I do think we should have some semblance of an answer for how authorization to do things on annotations are expressed and granted, because otherwise any real-world implementation of the protocol is going to end up being a standardised protocol wrapped in an unstandardised authorization layer, which would have negative implications for interoperability.

[iherman]

@iherman https://github.com/iherman: we certainly agreed that we should consult outside the WG on how/if to consider access control as part of the protocol.
But let's not confuse authorization with authentication. It's very likely that any recommendation we make regarding authentication (if we even need to make any) will be to follow existing industry standards. But authorization may well be more complicated, and specific to the use cases of annotation. We're also less likely to burn our fingers on authorization/access control than we are on authentication.

I do think we should have some semblance of an answer for how authorization to do things on annotations are expressed and granted, because otherwise any real-world implementation of the protocol is going to end up being a standardised protocol wrapped in an unstandardised authorization layer, which would have negative implications for interoperability.

I answer as if I understood this area:-) but isn't it so that even in the area of authorization things are moving so fast, due to all the current focus on these problems, that we would incur the danger of coming out with something out-of-date at the moment we publish our rec?

[azaroth42]

Who can identify appropriate security people to discuss with? And if no one, then how are we going to make progress on this issue?