On 01/12/2011 14:54, Nina Jeliazkova wrote:
> Hi Tobias,
> 
> On 12 January 2011 14:43, Tobias Girschick <tobias.girschick at in.tum.de>wrote:
> 
>> Hi Nina,
>>
>>
>> On 01/12/2011 01:32 PM, Nina Jeliazkova wrote:
>>
>>> Hi Tobias,
>>>
>>> On 12 January 2011 14:27, Tobias Girschick<tobias.girschick at in.tum.de
>>>> wrote:
>>>
>>>  Hi Nina,
>>>>
>>>> well, as
>>>>
>>>> /dataset/{id}/compound
>>>>
>>>> gives a list of all compounds in the dataset this should be definitely
>>>> protected. /dataset/{id}/feature could maybe left without policy.
>>>>
>>>
>>>
>>> I guess it depends  - if features refer to sensitive data , it might make
>>> sense to be protected.
>>>
>>>
>>>  We are not sure about the metadata.
>>>>
>>>>  OK, then the next question - if we want  /dataset/{id}/compound to be
>>> protected , should a policy to "/dataset/{id}/compound"  be registered as
>>> well,  or we could have one "top level" policy  (this does not work at the
>>> moment ) ?
>>>
>>
>> Well, the easier way would be to register an additional policy, but having
>> just one policy for everything beneath dataset/{id}.... sounds tempting.
> 
> 
> Yes :)
> 
> 
>> But that would mean to introduce wildcards to the policies, right? And that
>> is something that might complicate things, although I am not aware of the
>> exact reason we have/had not to use wildcards,
>>
> 
> It was decided for security reasons not to use wildcards, otherwise, one
> could register  http://tu-muenchen.de/* once and not let the  services
> register specific URIs upon creation, e.g.
> http://tu-muenchen.de/model/idwhen amodel is created.
> 
> Perhaps Andreas could comment and suggest the right behaviour.  There is
> also subsequent question what do we do with compound URIs  that belong to a
> dataset ... do we need policies for every single URI of a compound in a
> protected dataset ?  Wildcard policies would help a lot.

Now that I think of it, are the wildcards really that evil? If we had
just random URIs, that would indeed be the case. But it's my impression
that, at least for most things, we have pretty well structured URIs...

/{type_of_resource}[/{id}][/...]

So, if we restrict the wildcard usage to the sub-{id} level of the URI,
that would allow much simpler policies without compromising security
(and actually even strengthening it, since it's less likely you'd miss
to protect some elusive component of the resource).

Of course this isn't quite an universal solution, but if it works for
most (and most important) things, and if they could be easily defined so
that we're able to apply the wildcard usage to them only, then probably
that is the way to go. Then again, I might be missing the whole point,
so feel free to correct me in this case.

Cheers,
Luchesar

P.S. To make things clearer, I imagine defining policies for just two
URIs when you create a resource...

/{type_of_resource}/{id}
/{type_of_resource}/{id}/*

At the same time, you wouldn't be allowed to create policies for...

/{type_of_resource}/*
/*

Again, this might be an oversimplification of the problem on my side.