Re: [web-annotation] How do we model "groups" in the Annotation model?

> As written, this is absolutely an access control requirement. You a 
> want the ability to give certain collections of 
> people/machines/whatever the ability to perform certain actions on 
> certain resources. To my mind this doesn't place any requirements on 
> the model, but it does (as @BigBlueHat) and others have suggested, 
> have implications for the protocol. @BigBlueHat and @azaroth42: are 
> you imagining that 
> ["containers"](http://www.w3.org/TR/annotation-protocol/#annotation-containers) 
> will be one important unit of access control granularity? That is, a 
> container could represent a group's annotations, and I will be able to 
> see and/or modify specific containers dependent on membership of that 
> group?
>>   What about annotations that are stored locally, or exchanged
>
> So, overall, I think yes, this is an access control issue.
Yes, of course AND with emphasis on control. If there is no instance 
which controls access to certain parts of the graph, why should other 
parties respect the audience properties ? Even though, I am not related 
to security issues anymore for 5 years, from my experience, there are 
lot of knowledge engineers simply not aware of that simple fact.

So, if you want annotations being publicly accessible, with audience 
properties you will never achieve more than to express something like an 
"intended audience" for a given (set) of annotations.
Otherwise, you will have to close your annotation store up and prevent 
any public access through an authentication protocol followed by an 
authorisation instance controlling access to annotations conducted by 
your server. I don't know, if that is the intended usage for producing 
and publishing annotations ?

>
> ---
>
> **But**, there is one important aspect in which I think this does
> touch on the model, and I suspect that @shepazu may be thinking in
> these terms.  A potential user interface for annotating:
>
> 1. May need to be able to signal to a user that an annotation comes
> from a particular group.
That could be solved by provenance properties, and does not require a 
new vocabulary.
> 2. May need to know whether a user can create annotations in the group
>   in order to correctly display or hide editing controls.
Requires authentication...
> 3. May need to know what permissions the user has on specific
> annotations within the group as a result of a role conferred within
> that group (such as "moderator", "administrator", "teacher", etc.)
Requires authentication and authorisation
>
> It's not immediately clear to me that any of these considerations
> place hard requirements on the model, as all of them could in
> principle be achieved by other means (the client maintains state about
>   where each annotation came from, and identity/permissions information
>   also could come from elsewhere). But I think there is one very
> important scenario that we're not yet really considering: federation.
If the information imported by the client can be publicly accessed 
elsewhere, so why do I need identity/permission <-> 
authentication/authorisation and close up the annotation store ?
>
> If a client retrieves an annotation from its "canonical" data store
> (whatever that means) then I can maintain state about where it came
> from and who's allowed to do what with it.
>
> But what if a client retrieves an annotation from a data store which
> is republishing that annotation? What if a client retrieves
> annotations through an "aggregator" API that exposes annotations from
> multiple underlying containers through one set of endpoints?
That's a question of provenance, not of security ...
> AIUI there is at the moment no support in the model for specifying the
>   provenance of such annotations, or for including any kind of
> reference to where changes to such annotations need to be submitted
> (because I would guess the answer would probably not be "back to the
> aggregator").
>
> ---
>
> In summary, then:
>
> - There is an access control component to this which (IMO)
> doesn't/shouldn't form part of the model
If you want to impose access control, you must also consider a control 
component. But you are right, that must not be part of the model, this 
must be part of the access protocol to be used.
> - There are, however, considerations around display which
> fundamentally boil down to support within the model for discovering an
>   annotation's provenance. Perhaps we should open an issue to discuss
> this if we don't have one already?
> - I don't think the "audience" field discussed in #8 has anything to
> do with groups. It seems to me that independent of any discussion of
> groups, an "audience" field for hinting display intent to a potential
> user agent is a useful thing to pursue.
>
As already mentioned above, if the aim is to express an intended 
audience than it could make sense to include such a vocabulary.
If the aim is to protect access to a certain subgraph of statements, 
then you will be forced to implement that via an 
authentication/authorisation protocol.

Best regards
Lutz

Received on Friday, 4 December 2015 14:50:21 UTC