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

Thoughts on a common foundation for web services and NTB binary services

Expand Messages
  • Dave Robin
    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
    Message 1 of 4 , Mar 25, 2013
    • 0 Attachment
      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.

      Dave
    • Isler, Bernhard
      Dave, 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
      Message 2 of 4 , Mar 27, 2013
      • 0 Attachment
        Dave,

        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.

        Bernhard


        -----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.

        Dave



        ------------------------------------

        Yahoo! Groups Links
      • Dave Robin
        Bernhard, 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
        Message 3 of 4 , Mar 27, 2013
        • 0 Attachment
          Bernhard, 

          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:

          GET /.auth/ext/servers/1
          GET /.auth/ext/servers/2

          PUT /.auth/int/enable
          PUT /.auth/int/user/1
          PUT /.auth/int/pass/1
          PUT /.auth/ext/servers/1
          PUT /.auth/ext/servers/2
          PUT /.auth/ext/keys/1
          PUT /.auth/ext/keys/2

          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".

          Dave



          On Mar 27, 2013, at 10:14 AM, "Isler, Bernhard" <bernhard.isler@...> wrote:

           

          Dave,

          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.

          Bernhard

          -----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.

          Dave

          ------------------------------------

          Yahoo! Groups Links


        • Isler, Bernhard
          Dave, Sorry for creating confusion here. The first common is about common functionality (e.g. TLS, Certificate Management, OAuth) The second common means
          Message 4 of 4 , Mar 28, 2013
          • 0 Attachment

            Dave,

             

            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.

             

            Bernhard

             

            Bernhard Isler

            Siemens Switzerland Ltd
            Building Technologies Division

             

            From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
            Sent: Wednesday, March 27, 2013 9:33 PM
            To: IT-WG
            Subject: Re: [bacnet-it-wg] Thoughts on a common foundation for web services and NTB binary services

             



            Bernhard, 

             

            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:

             

            GET /.auth/ext/servers/1

            GET /.auth/ext/servers/2

             

            PUT /.auth/int/enable

            PUT /.auth/int/user/1                                      

            PUT /.auth/int/pass/1                                      

            PUT /.auth/ext/servers/1

            PUT /.auth/ext/servers/2

            PUT /.auth/ext/keys/1

            PUT /.auth/ext/keys/2

             

            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".

             

            Dave

             

             

             

            On Mar 27, 2013, at 10:14 AM, "Isler, Bernhard" <bernhard.isler@...> wrote:



             

            Dave,

            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.

            Bernhard

            -----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.

            Dave

            ------------------------------------

            Yahoo! Groups Links

             




          Your message has been successfully submitted and would be delivered to recipients shortly.