- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Thu, 26 Apr 2018 23:00:38 +0200
- To: "Mccool, Michael" <michael.mccool@intel.com>
- Cc: "public-wot-wg@w3.org" <public-wot-wg@w3.org>
On Monday, 23 April 2018 22:16:33 CEST Mccool, Michael wrote: > Thanks for your input, Kjetil. I’ll take a deeper look at your ideas... Great, thanks! > I should mention a few issues/constraints and design decisions we have > made: > 1. In practice authentication will be “lazy” and authentication > will only be attempted when an attempt is actually made to access a > resource. Right. > 2. However, one reason to have metadata “in advance” is so > that M2M systems (or M2M developers) can collect the necessary > authentication rights in advance of an actual access attempt. This may > be an involved process given that clients wanting access may not have > traditional UIs. In some use cases, when you need to make an access, > you may not have time to go chase down an authentication server etc. OK, I can see the case for this! > 3. > The flow you describe is a lot like OAuth. Also, in OAuth, you gave > “scopes” that can assign different rights to different resources and > users. ACE (as used by OCF) has access control lists with similar > capabilities. One M2M factor here is the need for manageability: you > have to be able to update access rights for clients and users without > touching the devices themselves. Yeah! So, this was developed with the ACLs that are in use by Solid in mind, where the main idea is that an application that requires a comprehensive view of what can be expected from a data source would download the ACLs and use that. I think that your point 2 and 3 would be best served by doing that, not going through my ideas. However, there are some niches that are better served with the stuff that I have in mind: 1) The human hackers coming into a data source wondering what they can do with it. 2) Machines that are doing arbitrary or serendepitious accesses, because they have been pointed to this data source by a different source and are likely to be interacting only with a small number of resources. > 4. Reads can also be sensitive, of > course. For example, consider a camera or microphone... Absolutely! But from my perspective, that's the easy case. :-) If you restrict all interactions, you just put up a challenge at the first access, and respond with affordances. Also, if you restrict no interactions, you don't need to challenge, you just respond with all affordances. The tricky case is when you allow access to a subset of the properties of the resource or restrict only certain interactions, that's when you have to put up some hoops to first challenge to authenticate, so that you can check against the ACL and figure out what affordances to respond with. > 5. We’re trying > to avoid inventing new security protocols. Rather we want to make it > easier to use existing ones. Absolutely! The actual protocol has to be completely orthogonal. Cheers, Kjetil
Received on Thursday, 26 April 2018 21:01:17 UTC