Request for Position: Web Thing API about standards-positions HOT 11 CLOSED

I'm unhappy to see that this involves JSON-LD. Earlier this year, I got baited into writing about namespaces in JSON. For reasons stated in that post, I don't want us to end up with JSON-LD processing code in Firefox and I don't want to make developers who are doing server-side integration and who've escaped from the world of XML to the world of JSON get JSON-LD imposed on them. (Mozilla has been there already, and we still haven't managed to get rid of all the RDF code that was introduced when RDF was a thing at Netscape.)

In the initial comment here, I view "without requiring knowledge of RDF" as a suspicious thing to say, because it looks like it isn't saying that there's no RDF and seems to say that RDF is somehow hidden for later discovery. (See the "But You Can Ignore the Complexity!" section in the above-linked post.)

I'd prefer steering clear of RDF and JSON-LD completely.

I don't see the words "security", "authentication" or "access control" in the Mozilla submission even though "security" appears in the initial comment here. Are the sensors meant to be accessed over the public Internet? Are they meant to be accessed over a LAN such that the LAN is presumed not to have rogue hosts? It seems worrying that it isn't immediately clear how the sensor data is to be exposed only to legitimate readers. Does this work involve solving the problem of TLS certificate provisioning in home networks whose hosts don't have globally-visible DNS names?

from standards-positions.

I think there are two questions to answer here:

• what is Mozilla's position on the Web of Things (WoT) work happening at W3C?
• what is Mozilla's position on the Web Thing API proposal, which I believe is intended as an alternative to part or all of the Web Thing Model spec.

Both of these documents seem to be a bit lacking in the sort of high-level overview or explainer that says how the pieces fit together, although the clearest definition of how they fit together is in the conformance section of the Web Thing Model spec, making it clear that the API need not be on the thing itself. If Web Thing API is intended to replace Web Thing Model, then it seems like that sort of prose should also be present in it.

I think it's also worth noting that both specifications read more like feature lists than specifications. They don't have sufficient detail to lead to interoperability (and I think it's probably insufficient by a decimal order of magnitude). Some simple examples of what I mean are:

• the Web Thing Description describes a format and (to some degree) what is allowed in a valid instance, but doesn't describe how consumers of the format should deal with unexpected data. Error handling behavior needs to be defined both to achieve interoperability and to allow for future expansion.
• the Property object doesn't describe the format of the things inside it
• the description of a Property resource doesn't describe how unexpected data or missing data in a PUT request should be handled, or what responses should be returned when writing a read-only property, or a property that doesn't exist

But despite that the specifications aren't particularly clear on how these specifications fit together into an ecosystem, I think that's a key part of what needs to be evaluated as part of finding a Mozilla position here. These issues include:

• When are the Web APIs intended to be exposed to the internet as a whole, or only to a local network?
• How is encryption (and the authentication needed for it) handled?
• How is authentication to the API handled?
• Do the specifications provide for good error handling and reliability in the presence of poor network conditions, devices changing state (off/on line, in range of network or not), etc.?
• Do the specifications provide any obstacles to good software updating practice (such as unclear or undefined behavior that might need to be changed in response to vulnerabilities), which is important for keeping devices secure in response to new threats?

So my inclination is that this should lead to two entries in the Specification Positions dashboard:

• Specifically for the Web Thing API proposal as a change proposal to the existing work in the group, I think we should mark it as participating. As a modification to the existing work, this seems like a good proposal in that it removes unneeded complexity and unneeded ties to other technologies.
• For the overall Web of Things work, I think we should mark it as defer (although I'd maybe be inclined to change the description of defer below the table to be a little bit more neutral). I think we should evaluate it again in the future after we've learned:
  • How much does the ecosystem it's building settle on good solutions to the questions above?
  • How much does the work progress from being a research effort to a standards effort with the level of stability or detail to achieve interoperable implementations?

Though perhaps it makes sense to have just one particpating entry?

from standards-positions.

I note that we still haven't sorted #14. That would really help in figuring out what to say here.

from standards-positions.

@dbaron wrote:

I think this is in some sense a request for dual Mozilla positions, both on the work of the WoT interest group, and of Ben's proposal to change that work.

Actually my request was simply to add a named representative to the Web of Things Interest Group, of which Mozilla is already a member as an organisation, in order to participate in the discussion there. I'm not looking for feedback on the output of that participation, which hasn't officially started yet. I answered the questions David sent me because he said he needed that information in order to make that decision (which has taken 11 weeks so far).

We have already decided not to participate in the Web of Things Working Group due to the formal objections we made to the charter.

Since then I was invited to join a conference call with the Working Group (meeting minutes here) to figure out a way to move forward which addresses those concerns, using a draft member submission from Mozilla as the centre of that discussion. We agreed that although Mozilla is not willing to join the Working Group with its current charter, we would start a new task force in the Interest Group to work on a plain JSON serialization of the abstract data model proposed in the Working Group's Thing Description draft specification.

This work has now started unofficially in collaboration with other members of the Interest Group. The purpose of the request to name a representative is to formalise participation in the Interest Group, whose charter can be found here.

Both of these documents seem to be a bit lacking in the sort of high-level overview or explainer that says how the pieces fit together

It may make more sense if you read the third document linked to, Web of Things (WoT) Thing Description. The Web Thing Model member submission from the EU funded COMPOSE project and the Web Thing API draft member submission predate that work, but are being used as a basis to work on a plain JSON serialisation of the Thing Description data model.

I think it's also worth noting that both specifications read more like feature lists than specifications. They don't have sufficient detail to lead to interoperability (and I think it's probably insufficient by a decimal order of magnitude).

The documents you're referring to are not standards track specifications and have not been submitted as such, they are simply incubation work on a JSON-based data format and a REST + WebSockets API. Any standards track specification may be suggested by the Interest Group but would need to be created by a Working Group.

When are the Web APIs intended to be exposed to the internet as a whole, or only to a local network?
How is encryption (and the authentication needed for it) handled?
How is authentication to the API handled?
Do the specifications provide for good error handling and reliability in the presence of poor network conditions, devices changing state (off/on line, in range of network or not), etc.?
Do the specifications provide any obstacles to good software updating practice (such as unclear or undefined behavior that might need to be changed in response to vulnerabilities), which is important for keeping devices secure in response to new threats?

These all sound like questions which could be addressed through participation in the Interest Group.

from standards-positions.

@annevk wrote:

I note that we still haven't sorted #14. That would really help in figuring out what to say here.

A "Firefox position" on the Web Thing API would be irrelevant. It's a server side technology which is independent of a web browser and wouldn't require any implementation work in Firefox (which could use the existing fetch and WebSocket browser APIs). We will of course welcome feedback from the Firefox back end team along with anyone else who wishes to comment, once there's something to comment on.

from standards-positions.

@hsivonen wrote:

I'm unhappy to see that this involves JSON-LD.

Good. The purpose of Mozilla's involvement here is to steer the work away from the current over-complex approach being taken by the WoT Working Group (with an abstract data model based on RDF and an unnecessary language-agnostic Scripting API) towards a simpler, more pragmatic and concrete approach using existing web technologies like HTTP, JSON, REST, WebSockets and TLS.

I don't want us to end up with JSON-LD processing code in Firefox

No implementation work of any kind is required in Firefox.

I don't see the words "security", "authentication" or "access control" in the Mozilla submission even though "security" appears in the initial comment here. Are the sensors meant to be accessed over the public Internet? Are they meant to be accessed over a LAN such that the LAN is presumed not to have rogue hosts? It seems worrying that it isn't immediately clear how the sensor data is to be exposed only to legitimate readers. Does this work involve solving the problem of TLS certificate provisioning in home networks whose hosts don't have globally-visible DNS names?

Most of this is orthogonal to defining a JSON-based data format and I wouldn't have thought should impact whether or not Mozilla participates in the Interest Group.

However, these are all issues being addressed by Mozilla's implementation of a Web of Things gateway. Every gateway gets a unique subdomain with an SSL certificate automatically generated via Lets Encrypt and uses an (optional) SSH tunnel from the cloud to the gateway if the user doesn't want to have to configure their home router to open a port on their firewall. Requests are authenticated using JSON Web Tokens and third party applications will be able to request access via OAuth.

from standards-positions.

@dbaron FWIW I think you're overcomplicating this. We have a seven person Web of Things team in Emerging Technologies who want to participate in the Web of Things Interest Group at the W3C. We're not asking for a Mozilla position on a standards track specification, just to be part of the conversation. There will be ample opportunity for the Firefox team to comment on any output of that Interest Group or Working Group if they want to.

We have already objected to the Working Group Charter. The Interest Group Charter is not perfect, but I would prefer us to be part of that conversation rather than sit on the sidelines and do nothing. We have already agreed a way forward with the Interest Group and waiting 11 weeks for a response to this request is preventing us from doing our job.

from standards-positions.

I would make several points:

1. I share the concerns I've heard raised by MT, Anne, and Henri about some of the work in this area. I'm glad to hear from Ben that our implementation makes some progress on this, but: I note that (a) the Web Things API proposal doesn't actually seem to address these, which is troubling. These absolutely do seem to be the kinds of things that would need to be addressed by anything calling itself a Web of Things API, certainly in light of the document containing a WebSocket binding (b) it seems to be just a member submission, so it may not even be adopted.

2. I think this is actually revealing a potential defect in the taxonomy here, which is that it's oriented towards specifications, this isn't a specification, it's just a work effort which might lead to some future specification. So, it's less like saying "what's our position on HTTP/2" than "What's our position on the HTTP WG". Now, I could imagine that there are WGs that we would have strong positions on because they are mostly devoted to efforts we find worthy (e.g., HTTP) or unworthy (no names mentioned here) but even within the former category there might be specifications we don't think much of or vice versa for the latter category. So I think we should retain the focus on specifications and not weigh in on groups at this time, though at some point in the future we might find it useful to respond to entire efforts.

As an amendment to @dbaron's comment, then, I think we should proceed as follows:

1. Ben (or whoever) should join the IG. I believe @dbaron handles the mechanics here.
2. We should create a participating entry for the Web Thing API proposal.
3. We should record nothing for the Web of Things effort more generally because it's not in scope for this process.

Separately, I think that this Web Thing specification does need to adequately capture security, and address the questions that @martinthomson raises. If the document continues significantly further -- and in particular is adopted by the WG -- without these issues being addressed there or in some companion specification, then I think we would need to reconsider our view of the document and potentially reclassify it in some more negative category, as it would then probably not be a good thing.

from standards-positions.

Thank you @ekr, I agree with the points you've made here. I would very much welcome your input on an as-yet unwritten "Security Considerations" section of any document this group produces, as I would welcome input from @hsivonen and anyone else on the JSON serialisation.

Sounds like we have a positive way forward.

from standards-positions.

@benfrancis wrote:

A "Firefox position" on the Web Thing API would be irrelevant. It's a server side technology which is independent of a web browser and wouldn't require any implementation work in Firefox (which could use the existing fetch and WebSocket browser APIs). We will of course welcome feedback from the Firefox back end team along with anyone else who wishes to comment, once there's something to comment on.

This statement assumes that the WoT will end up with a particular security and authentication solution that I'm not at all confident is what it will use (although I'd be happy if it does). In particular, access from Firefox without any implementation work requires either than (1) the access be over unencrypted channels, which I think is unacceptable or (2) that the servers being accessed all have valid certificates for their hostname, which generally requires that they be accessible on the global Internet for at least some period of time in order to get those certificates (or that the certificate infrastructure be made less secure in a way that is also probably unacceptable). If access over TLS using the existing certificate infrastructure is actually what's intended in the ecosystem, that should be clearly documented, and would remove one of the concerns.

I'd also point out that Mozilla participation in standards efforts, particularly at W3C, has in the past led other participants to assume that Firefox is being represented, and can lead them to be upset and publicly angry if it wasn't. That's one of the reasons that it's valuable to have this discussion, publicly, prior to joining, so that there is clear public documentation about our intent in joining the group.

(I'd also note that your use of the term "Firefox back end team" (a term only you use) seems to minimize the value of the knowledge and experience of the Web and of building interoperable and secure systems on it by many of the people on that team that works on Gecko. This is experience that we should be trying to use as the Web expands in other areas, not minimize.)

@benfrancis wrote:

These all sound like questions which could be addressed through participation in the Interest Group.

I think they're substantially broader than that. They're questions that attempt to investigate whether the interest group participants have a strong enough understanding of how to build a large scale hardware and software ecosystem in a way that avoids easily forseen security problems and privacy problems for their users and interoperability problems (and ensuing competition problems) for the creators of the software. I think failure to consider these issues early and build solutions into the design of the system is a very poor signal about the chance that the group will succeed in a way that Mozilla can be proud of.

@benfrancis wrote:

I would very much welcome your input on an as-yet unwritten "Security Considerations" section of any document this group produces

I'd note again that I think this is broader than a "Security Considerations" section; it's about how the ecosystem being designed by this and related specifications fits with the security model of the Web. That reaches deeply into the normative statements in the specifications, and is not just a security consideration that can be addressed on the side.

In any case, I've added @benfrancis to the interest group now that we've at least started this discussion.

from standards-positions.

I'm going to call this fixed by #48.

from standards-positions.