- From: bergi <bergi@axolotlfarm.org>
- Date: Sat, 18 Aug 2012 00:34:21 +0200
- To: Emmanuel Dreux <edreux@cloudiway.com>
- CC: Read-Write-Web <public-rww@w3.org>
Am 17.08.2012 12:16, schrieb Emmanuel Dreux: > You wrote: "Why No Deny? There is no uac:denyAccessToTriple property > because it would just cause trouble. Think about foaf:group provided > by a server which is temporary not reachable. If you would deny > access for this group you have a problem. A concept of deny just will > not work with distributed data." > > I'm discovering your technologies that look promising and my first > comment after reading your mail is that I will have a lot of pain to > adopt a model where the acls are not defined/stored at the same > location than the data. Typically for the reason you are exposing. > Indeed security is too important to let network issues and latencies > impact the result of the evaluation of the authorizations. It's up to you where you store your groups / which groups you use. Of course you can use only local groups and/or local copies. But a proxy server can do this for you. And it all depends on the use case. Here some examples: Access for friends of friends This is a well known feature on big social networks. People will ask for it and they are willing to give their friends indirectly control over some parts of their acls. A project leader maintains a list of project members In the enterprise market we will have scenarios with many different systems. A project leader maintains the list of project members in the DMS system. The company has also a special CAD system that has it's own file storage. Why maintain the group again in the CAD system? > > (Note that I might be very old fashion and intellectually sticked in > a Unix / Windows model where acls are placed "on" the object > protected). I understand your concerns, but in the linked data world there is no big difference if a group is on the same server/system/network or not. With the way how you define/use groups you can also define your technical/security/trust boundaries. If you like please join the Skype session I mentioned in the other mail 1h ago. > > -- > Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux
Received on Friday, 17 August 2012 22:35:01 UTC