- Dave, Sorry for creating confusion here. The first common is about common functionality (e.g. TLS, Certificate Management, OAuth) The second common meansMessage 1 of 4 , Mar 28 6:55 AMView Source
Sorry for creating confusion here.
The first ‘common’ is about common functionality (e.g. TLS, Certificate Management, OAuth)
The second ‘common’ means that the resource tree is common, for both BACnet IT and the web services. BACnet IT will have a minimal mandatory form of this tree, allowing hard coded implementations for those that just have BACnet IT (as shown below). But that minimal form shall be a proper subset of the full blown web services resource tree. In that sense, it is not a problem that OAuth etc. would require some specific resources, as long as accessing them is straight forward, not pulling in too much complexity and variations.
In addition, I would concur with the default representation be plain. This will support constrained devices by not requiring support of XML or JSON encoders/decoders on the server side.
Siemens Switzerland Ltd
Building Technologies Division
I'm not quite sure I follow you on your second paragraph. In the first paragraph, you seemed to leave out resources from the "common foundation", but then said they should be part of a "common resource/data model". So I'm not sure what the second "common" means. then. I certainly agree that the whole point of this effort would be to provide layers or slices that could be common between the two application stacks. But it would seem that at least some basic resources would be common to both.
Even if you want to leave out the /.sysinfo tree, the OAuth part is currently written to use "resources" in the /.auth tree. If a goal of the foundation is to avoid XML and JSON (I don't disagree), then these few resources could all be read and written in plaintext, one at a time. In other words, a pico-httpd could hardcode the following "paths" without actually having to parse them:
If we change the default representation to be plain text, as some have suggested, the we could even leave off the query parameter ?alt=plain and the above would literally be "PUT /.auth/int/enable HTTP/1.1".
On Mar 27, 2013, at 10:14 AM, "Isler, Bernhard" <bernhard.isler@...> wrote:
Out of the below list, I believe that "TLS certificates" and "OAuth 2.0" are general concepts that could be extracted from the web services draft and make up parts of a common foundation.
For the particular resources also required for BACnet IT, I propose to let them be part of the common resource/data model. BACnet IT should then come up with requirements on those particular resources relevant for BACnet IT.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Dave Robin
Sent: Monday, March 25, 2013 4:23 PM
Subject: [bacnet-it-wg] Thoughts on a common foundation for web services and NTB binary services
In Dallas, there was some discussion about trying to come up with a common foundation for BACnet web services and NTB binary services. This is because they are both based on TCP and HTTP, and they both need a good security solution.
One of the goals of "IT friendliness" is to use standard TLS certificates for base security, possibly layering on top of that OAuth 2.0 for authentication.
Would it be a worthwhile exercise to extract out the following parts of the web services draft into a separate "foundation" proposal?:
- TLS certificates (more work is needed on interoperable "certificate management")
- HTTP GET: only for optionless read-only "/.sysinfo" (fixed XML answer could be hard-coded by simple implementations, similar to the "CSML in Classic devices" discussions)
- HTTP PUT: only for optionless writes to "/.auth/..." fields (could be limited to one primitive at a time, no structured data requirements)
- HTTP POST: only for a "/.asn" path for binary service PDUs
- OAuth 2.0: basic internal authorization server (user/pass) with optional references to external authentication servers.
The idea is that for simple devices, the "paths" like "/.auth/int/enable" could really just be hard coded string identifiers for primitive data that are read and written with simple services without any fancy HTTP query parameters. But by using the standard "paths", this makes the client's view of the foundational aspects of server identity and security setup the same between the cousins.
The latest WS draft also adds numeric 'user-id' and 'role-id' fields, as defined in Clause 24, to the OAuth access token. This is hopefully the basis for a bidirectional mapping between OAuth and Clause 24 binary security, bridging the two security worlds as seamlessly as possible, without needing any new "concepts" when moving to OAuth.
Yahoo! Groups Links