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

Thanks for your input, Kjetil.  I’ll take a deeper look at your ideas...

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. 
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.
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.
4. Reads can also be sensitive, of course.  For example, consider a camera or microphone...
5. We’re trying to avoid inventing new security protocols.  Rather we want to make it easier to use existing ones.

(From: Michael McCool)

> On Apr 24, 2018, at 5:47, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
> 
> Dear all,
> 
> I hope you don't mind me jumping in here a bit:
> 
> Michael McCool wrote:
>> So, if a property is *potentially* writable, with the right access 
>> rights, it should be marked as writable, and (with my proposed security 
>> metadata) the metadata would indicate what authentication methods should 
>> be used to access the resource. 
> 
> This is part of the braindump I've made at 
> http://kjetil.kjernsmo.net/2018/01/read-write-rdf-hypermedia-tech-alpha/
> http://kjetil.kjernsmo.net/2018/03/discussion-on-my-rdf-hypermedia-proposal/
> 
> My idea was that any potentially writeable (information) resource would 
> have a predicate that point towards a resource that would challenge the 
> client to authenticate, check what the client is authorized to do, and then 
> provide near natural language sentences in the form of triples that tells 
> the details. 
> 
> Say, for example that you have a lamp, described as
> </my/livingroom/lamp> rdfs:label "Lamps in my living room"@en .
> </my/livingroom/lamp/data> rdfs:label "Data about them"@en ;
>  hm:toEditGoTo </my/livingroom/lamp/controls> .
> 
> The hm:toEditGoTo predicate is what is there whenever there is a potential 
> for a write. The agent will then dereference the resource at </my/
> livingroom/lamp/controls>, be challenged to authenticate, and then have a 
> triple e.g.
> </my/livingroom/lamp/data> hm:canBe hm:replaced .
> 
> ...meaning, the client has been authorized to replace the data about the 
> lamp. Those are the primitives.
> 
> The next step would be to apply TD, SHACL, or similar to say that the 
> client may only adjust the brightness, and then, that can be exposed to the 
> client as a triple 
> </my/livingroom/lamp/data> hm:canBe hma:brightnessAdjusted .
> ...instead of the hm:replaced. Not sure how that would work in practice, 
> but that was the idea, that I thought I'd share in case someone finds it 
> intriguing.
> 
> Cheers,
> 
> Kjetil
> 
> 
> 
>

Received on Monday, 23 April 2018 22:17:06 UTC