Luchesar V. ILIEV wrote:
> Probably I'm missing something, but besides a few simple policies
> (like "public: everyone can read, only creator can write" or "OT only:
> partners can read, only creator can write") how would we predefine
> more, considering that the "who" part of the policy could be rather
> different.
>
> For instance, I might desire the following policy for a certain
> resource that I create:
>
> uid:luchesar=GET,POST,PUT,DELETE (as I'm the creator)
> uid:nina=GET,POST,PUT,DELETE
> gid:partners=GET,POST
> uid:anonymous=GET
>
> but it could as well be:
>
> uid:luchesar=GET,POST,PUT,DELETE (that should be default, anyway)
> uid:nina=GET,POST
> gid:parners=GET
> (since I don't explicitly mention anonymous, that implies "deny all")
>
> and so forth... There are likely an endless number of combinations.
>
> BTW, although I haven't yet given it much thought, the above notation
> might be a very crude example to start with.
>   
I would suggest also having a look at W3C ACL schema (RDF based, as
almost everything else in OpenTox)

http://esw.w3.org/WebAccessControl

http://linkeddata.deri.ie/tr/2009-rw-wod

Regards,
Nina

> Cheers,
> Luchesar
>
>
> On Fri, Jun 25, 2010 at 12:43, Nina Jeliazkova <nina at acad.bg> wrote:
>   
>> chung wrote:
>>     
>>> Hi All,
>>>
>>> On Thu, 2010-06-24 at 22:59 +0300, Luchesar V. ILIEV wrote:
>>>
>>>       
>>>> Hi,
>>>>
>>>> Not a comment per se, but closely related to the question about
>>>> specifying the policies. I'm trying to compile an "OpenTox AA best
>>>> practices and implementation guide"; the title might eventually
>>>> change, but the general idea is to have a singe, likely only internal
>>>> document, documenting the AA implementation in as much detail as
>>>> necessary for the developers -- in order to achieve perfect
>>>> synchronization between the different development teams.
>>>>
>>>> One thing that's obviously going to be in this document is exactly
>>>> what you ask: how the policies are specified when a client/user is
>>>> creating new resource. I suppose we won't require the client/user to
>>>> create a complete OpenSSO policy, so we could use much simpler syntax.
>>>>
>>>>         
>>>   I agree that clients should not take on the creation of complex XML
>>> documents for creating a resource with some policy. Instead, if we need
>>> to keep it simple, we can specify a list of optional policies from which
>>> the client can choose and maybe provide some advanced options also. Then
>>> the client can POST parameters either in the Header or using forms
>>> choosing from a list of standard policies (like policy=1) [This is quite
>>> similar to how Creative Commons licenses work]
>>>
>>>
>>>       
>> If I remember right, we have already discussed something similar, even
>> having a service with predefined policies , from which one could select.
>>
>> Regards,
>> Nina
>>     
>>> Regards,
>>> Pantelis
>>>
>>>
>>>       
>>>> However, the exact syntax might depend on where we'll put that
>>>> information... Do the HTTP headers make sense as such place?
>>>>
>>>> Cheers,
>>>> Luchesar
>>>>
>>>>
>>>> On Thu, Jun 24, 2010 at 19:16, chung <chvng at mail.ntua.gr> wrote:
>>>>
>>>>         
>>>>> Heloooo,
>>>>>  Any comments?
>>>>>
>>>>> On Mon, 2010-06-21 at 18:33 +0300, chung wrote:
>>>>>
>>>>>           
>>>>>> Dear All,
>>>>>>   NTUA web services ( http://opentox.ntua.gr:3000 ) now support some
>>>>>> initial functionalities of the A&A API. All resources are accessible to
>>>>>> all users in the groups partner and development. You can either provide
>>>>>> a token in the url (url endcoded) or your credentials in the URL. The
>>>>>> latter is more convenient but less secure. For example, if you want a
>>>>>> list of all models, use the URL: /model/?username=...&password=...
>>>>>>   All connections between the services and the openSSO server are over
>>>>>> SSL.
>>>>>>
>>>>>> One question:
>>>>>> * Does the client specify some parameters about the policy of the
>>>>>> created resource (e.g. model)? We have to specify which.
>>>>>>
>>>>>>             
>>>>> What about this?
>>>>>
>>>>>           
>>>>>> We also have to discuss about the QPRF reporting services (see
>>>>>> http://opentox.org/dev/apis/api-1.2/report ). An initial implementation
>>>>>> of the QPRF editor is available at
>>>>>> http://opentox.ntua.gr/Q-edit/launch.html (source code at
>>>>>> http://github.com/alphaville/Q-edit ).
>>>>>>
>>>>>> Regards,
>>>>>> Pantelis
>>>>>>
>>>>>> _______________________________________________
>>>>>> Development mailing list
>>>>>> Development at opentox.org
>>>>>> http://www.opentox.org/mailman/listinfo/development
>>>>>>
>>>>>>
>>>>>>             
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at opentox.org
>>>>> http://www.opentox.org/mailman/listinfo/development
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at opentox.org
>>>> http://www.opentox.org/mailman/listinfo/development
>>>>
>>>>         
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>>     
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>