web-annotation
web-annotation copied to clipboard
w3c
Client can't determine if user has authorization to modify annotation
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.
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.
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?
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.
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.
@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 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?
Who can identify appropriate security people to discuss with? And if no one, then how are we going to make progress on this issue?
We will have to have a security review of the document anyway. I propose to keep this open for now and, as soon as the next draft is public (even in the form of an editor's draft) we contact Wendy Seltzer (the relevant domain lead) for a review in general, and this issue in particular.
On 12 Jan 2016, at 01:33, Rob Sanderson [email protected] wrote:
Who can identify appropriate security people to discuss with? And if no one, then how are we going to make progress on this issue?
— Reply to this email directly or view it on GitHub https://github.com/w3c/web-annotation/issues/19#issuecomment-170742896.
permission is given by whom?
Can an annotation can be stored on a variety of servers (e.g. "via" discussion?) Thus server side permissions could become inconsistent depending on local policy.
Can an annotation creator specify permissions, e.g. create an annotation that cannot be modified? If so then the permissions are naturally part of the annotation itself.
I don't think a security expert can resolve the issue until we are clearer on the use model of how permissions relate to annotations and servers that store them and the sharing of annotations.
+1 to Ivan's comment from Jan 11, and Nick's comment from Dec 2.
Let's publish a new WD, get a quick review (sanity check rather than anything systematic) and then circle back to try and make a more coherent set of issues around authorization (not authentication) in general.
@fhirsch
permission is given by whom? Permissions are typically associated to roles, and roles are asigned either to user groups of to users directly.
However the policies are typically more complicated ... We can think of having and administrator of the system, a moderator, an owner (i.e. creator) of the annotation, even an software agent (i.e. generator) or a unidentified user (i.e. annonymous). All of these roles make sense in an (moderated) annotation system.
This .. is about authorization ... the authentication is easier. However, for both I'll suggest consulting the oauth standard https://oauth.net/2/ Br, Sergiu
