Loading ...
Sorry, an error occurred while loading the content.

170RE: [bacnet-it-wg] Thoughts on a common foundation for web services and NTB binary services

Expand Messages
  • Isler, Bernhard
    Mar 27, 2013
    • 0 Attachment

      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.


      -----Original Message-----
      From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
      Sent: Monday, March 25, 2013 4:23 PM
      To: IT-WG
      Subject: [bacnet-it-wg] Thoughts on a common foundation for web services and NTB binary services

      IT-WG members,

      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
    • Show all 4 messages in this topic