-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider how to support object security #185
Comments
Maybe the first step here is to make a list of existing object security schemes and review them. Here is a start: |
I'm thinking some next steps here would be to...
Before doing 2, though, we would have to justify the effort with use cases, etc. This could be the case if some major ecosystem we want to integrate with WoT requires object security (and ecosystem could be a platform/standard, e.g. OCF, or it could be a domain, eg Smart Cities). |
This is also mentioned in the Best Practices document but we may want to clean it up and provide specific guidance. It also relates to TD signing (a signed TD is basically object-level security on a TD, and a directory providing signed TDs is doing object-level security on them, and a Directory is ALSO a Thing, so...). Some use cases would be helpful (e.g. controlling a lock via a gateway providing a shadow...). Could also ask WebThings. Also there is a problem using TLS on .local domains (e.g. in a smart home), so object security might be... better than nothing. @benfrancis any thoughts on this? |
WebThings Gateway currently relies on:
We have never really explored signing Thing Descriptions. The assumption is basically that the client trusts the origin (e.g. a self-hosted gateway at https://example.webthings.io hosting a directory of web things, or a web thing hosting its own Thing Description at its own host) and TLS provides encryption in transit to guarantee the integrity of both metadata and data communicated with that origin. Finding a way to extend this level of trust to local networks has been an open issue since 2017. We have experimented with numerous approaches including Service Workers, WebRTC, Alt-Svc HTTP headers (RFC 7838), and even building a WoT gateway into a home router in order to have control over the DNS configuration of the network. Ultimately none of these approaches worked. Since this appears to be a fundamental limitation of the web rather than something WoT-specific, we have been waiting to see what comes out of the HTTPS in Local Network Community Group. Mozilla's Martin Thomson had one proposal but so far the Community Group hasn't reached any conclusions. Signing Thing Descriptions is an interesting idea, but that only really solves the metadata part, not the (arguably more sensitive) data exchanged with a device via interaction affordances. Note: As I understand it Apple solved this problem in the Wi-Fi version of their HomeKit specification by inventing a proprietary encryption scheme used for resources exchanged over HTTP. This is something we wanted to avoid, since all clients would need to support the encryption scheme (including web browsers using So in conclusion, for a thing or thing directory with a fully qualified domain on the internet we have found TLS to be sufficient. We haven't found a good solution for local networks, but the integrity of the metadata in Thing Descriptions is only one piece of the puzzle. |
Object security would apply to data returned by a Thing as well, directories are just a special case. Unfortunately the approach has big holes since headers and URLs are not protected, so (for example) in the case of a directory JSON Path queries in URLs would be visible (queries in bodies could be protected, but this implies we need to define ways to put queries in bodies for all forms of query...). I am grasping at straws here since what we REALLY REALLY want is just a way to use TLS in a LAN... however, I was thinking object security might be better than nothing. DID is one possible solution here if it provides a way to securely distribute certificates in a way that browsers will trust (but I'm not holding my breath). |
CoAP has some out of band methods in order to enable DTLS. |
Does object security (eg JOSE/COSE) need additional security schemes? Is contentType enough? Do we need more than one object security scheme? How do object security schemes combine with other schemes, eg OAuth flows? Do we have just one object security scheme (differentiated by contentType) or multiple ones? How do we document how these contribute to end-to-end security (eg should the schemes define the endpoints?)
The text was updated successfully, but these errors were encountered: