W3C home > Mailing lists > Public > public-wot-wg@w3.org > April 2018

Re: A look at WoT specs from Linked Data and AWWW perspective

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>
Message-ID: <1617537.lcZil2fjg6@owl>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:49 UTC