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

Thank you, Lutz. Replies inline below.

On Fri, Dec 4, 2015 at 9:49 AM, Lutz Suhrbier <l.suhrbier@bgbm.org> wrote:

>
>
> 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.
>

Much of this feels analogous to email.

I can state that an email is intended "To" someone and that email (or this
one ;) ) will make its way through the various "post offices" until it
lands in the appropriate inbox. Along the way, anyone with access to those
post offices could open the mail. Additionally, once received it may be
passed on by the new person holding the mail--for which email is
accomdating and wraps the message inside a new "envelope" with a newly
stated "intended audience" and keeps the provenience chain (hopefully) of
where it came from to begin with.

But, along the way, the only guarantee the original author has is that
they've stated the "intended audience" and that there's a collection of
machines (and people) who will hep the message make it to that entity. It
does not (ever) guarantee that it won't go elsewhere or won't be read by
others. It can't.

In the email world, encryption is typically the answer.

Relatedly, Nick's point about knowing / find the provenance of an
annotation as it moves about the world (on and off the Web) is worth some
more attention. We've discussed it in the context of `via` and `updated`,
etc. Perhaps it needs a concerted focus (even if it's post CR) to explore
"routing" and "provenance" with reguards to federation and the protocol.

RFC822 has some great prior art--which has worked quite well for the past
33 or so years--and see what if anything is needed in the model...or around
it (packaging, protocol, etc)--keeping in mind that RFC822 is a messaging
format in which the thing itself (the message) is contained...and is not
the thing itself.

Anyway. I think it's worth our exploring it, but separately from the core
annotation model.


> 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 ?


It should not be the sum total of what we intend (or rather expect) to be
built and used, but we certainly shouldn't prevent that existing around the
model. That data, though, is likely not *in* the annotation, but around it
(re: RFC822, etc).

Thank you for weighing in Lutz,
Benjamin
--
Developer Advocate
http://hypothes.is/


>
>
>> ---
>>
>> **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
>
>
>