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

Re: [bacnet-it-wg] RE: [bacnet-dm] Update to Web Services Addendum (rev 11)

Expand Messages
  • Dave Robin
    That was going out on a limb a bit just to get a straw man out there. In our call we had left it that the realms were required to be writable so sites could be
    Message 1 of 5 , Apr 30, 2013
    • 0 Attachment
      That was going out on a limb a bit just to get a straw man out there. In our call we had left it that the realms were required to be writable so sites could be in charge of those names.  And we decided that we should have some standard scopes that would be "under" those realms. 

      In this draft I got rid of the realm/scope confusion which left just scopes. But the idea that the site should be "in charge of names" still resonated and so it spilled over from realms to scopes. 

      Since it seemed on our last call that we wanted standard scope names, and yet on the call before that, we said we did *not* want standard scope names. So I got gun shy about enumerating a standard set and decided that it should be another "site policy" and this that they should be writable. 

      So... rather than saying "Since the auth server is now in charge of the scopes",  what I should have said is "Since the site is now in charge of assigning the scope identifiers..."  the auth server and the resource server shall both be configurable to use the site-specific scopes. 

      The reason for the "mapping" in the  server device is that the device might might support a very fine grained separation of data and actions internally but the site site doesn't care about that (let's say the site only wants to think in terms of gods and peons), and so the site assigns the same scope identifier to several of the fine grained slots in the server device. 

      But to bring sanity to the "normal" case, and to hint at the equivalent of a set of "standard" scope identifiers, I actually enumerated three scopes and said something like "unless the server device needs otherwise, use these three scopes". Hopefully that will be enough for most devices and sites and will make a good out of the box default. 

      But that might still be too much of a brain twister, so I'm happy to talk about simpler alternatives. But in any case, that's what I meant. 

      On Tuesday, April 30, 2013 at 5:59 PM, Carl Neilson wrote:

       

      Dave,

       

      Can you comment further on the pre-amble comment:

      •             It was felt that scopes were akin to roles and that there should be some kind of mapping.  Since the auth server is now in charge of the scopes for the most part, this mapping can be done by the auth server.

       

      Carl


      <image001.png>

      Chair, ASHRAE SSPC 135 (aka The BACnet Committee)

      direct:   +1.604.575.5913

       

       

       

      -----Original Message-----
      From: bacnet-dm@... [mailto:bacnet-dm@...] On Behalf Of Dave Robin
      Sent: Tuesday, April 30, 2013 7:15 AM
      To: bacnet-dm@...
      Cc: IT-WG
      Subject: [bacnet-dm] Update to Web Services Addendum (rev 11)

       

      Data Modelers (and IT-WG, only when we mess with the TLS/OAuth part)

       

      Here is the update based on last week's conference call.  Please join us this Thursday to discuss, or send email anytime.

       

      Dave

       

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

      The bulleted list of changes is too complex/deep for mail to handle gracefully this time, so please just see attached document for committee notes about changes

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

       

      --

      You received this message because you are subscribed to the Google Groups "bacnet-dm" group.

      To unsubscribe from this group and stop receiving emails from it, send an email to bacnet-dm+unsubscribe@....

      To post to this group, send email to bacnet-dm@....

      For more options, visit https://groups.google.com/groups/opt_out.

       

       


    • Carl Neilson
      I liked the idea of the OAuth scope being a mix of application area and role. With a site/deployment controlled application area and a standardized role, I
      Message 2 of 5 , Apr 30, 2013
      • 0 Attachment

        I liked the idea of the OAuth scope being a mix of application area and role.

         

        With a site/deployment controlled application area and a standardized role, I think that we will have a better chance at providing good directions to implementers along with the configurability that sites need to manage deployments.

         

        View

        Modify Runtime  (adjust setpoints)

        Runtime Control (write values for the purpose of controlling actions)

        Command Override (placing objects out of service, commanding at priorities that would limit runtime control, etc)

        Configuration and Programming (configuration, and programming actions, adding TLs, EVs etc)

        Installation (more technical configuration actions, adding IO points, uploading different application programs)

         

        I see the benefits as being:

        - to deploy product that use the standard role names, the assignment of allowable scopes to users is easy and does not need to be adjusted when a new product is added to the system.

        - there will be less chance of orthogonal role sets being created by different vendors (because we have provided descriptions that guide vendors on how to assign roles to data elements).

        - we would avoid problems like a product having 16 different slots for roles, which it mandates have 16 different names, and thus cannot be merged into the 2 roles that site X decided to deploy.

        - allowing additional proprietary roles allows for added granularity if a vendor deems it necessary.

         

        I can see no downsides to this approach.

         

        Carl

         

        From: bacnet-dm@... [mailto:bacnet-dm@...] On Behalf Of Dave Robin
        Sent: Tuesday, April 30, 2013 3:32 PM
        To: bacnet-it-wg@yahoogroups.com
        Cc: bacnet-dm@...
        Subject: Re: [bacnet-it-wg] RE: [bacnet-dm] Update to Web Services Addendum (rev 11)

         

        That was going out on a limb a bit just to get a straw man out there. In our call we had left it that the realms were required to be writable so sites could be in charge of those names.  And we decided that we should have some standard scopes that would be "under" those realms. 

         

        In this draft I got rid of the realm/scope confusion which left just scopes. But the idea that the site should be "in charge of names" still resonated and so it spilled over from realms to scopes. 

         

        Since it seemed on our last call that we wanted standard scope names, and yet on the call before that, we said we did *not* want standard scope names. So I got gun shy about enumerating a standard set and decided that it should be another "site policy" and this that they should be writable. 

         

        So... rather than saying "Since the auth server is now in charge of the scopes",  what I should have said is "Since the site is now in charge of assigning the scope identifiers..."  the auth server and the resource server shall both be configurable to use the site-specific scopes. 

         

        The reason for the "mapping" in the  server device is that the device might might support a very fine grained separation of data and actions internally but the site site doesn't care about that (let's say the site only wants to think in terms of gods and peons), and so the site assigns the same scope identifier to several of the fine grained slots in the server device. 

         

        But to bring sanity to the "normal" case, and to hint at the equivalent of a set of "standard" scope identifiers, I actually enumerated three scopes and said something like "unless the server device needs otherwise, use these three scopes". Hopefully that will be enough for most devices and sites and will make a good out of the box default. 

         

        But that might still be too much of a brain twister, so I'm happy to talk about simpler alternatives. But in any case, that's what I meant. 

         

        On Tuesday, April 30, 2013 at 5:59 PM, Carl Neilson wrote:

         

        Dave,

         

        Can you comment further on the pre-amble comment:

        •             It was felt that scopes were akin to roles and that there should be some kind of mapping.  Since the auth server is now in charge of the scopes for the most part, this mapping can be done by the auth server.

         

        Carl


        <image001.png>

        Chair, ASHRAE SSPC 135 (aka The BACnet Committee)

        direct:   +1.604.575.5913

         

         

         

        -----Original Message-----
        From: bacnet-dm@... [mailto:bacnet-dm@...] On Behalf Of Dave Robin
        Sent: Tuesday, April 30, 2013 7:15 AM
        To: bacnet-dm@...
        Cc: IT-WG
        Subject: [bacnet-dm] Update to Web Services Addendum (rev 11)

         

        Data Modelers (and IT-WG, only when we mess with the TLS/OAuth part)

         

        Here is the update based on last week's conference call.  Please join us this Thursday to discuss, or send email anytime.

         

        Dave

         

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

        The bulleted list of changes is too complex/deep for mail to handle gracefully this time, so please just see attached document for committee notes about changes

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

         

        --

        You received this message because you are subscribed to the Google Groups "bacnet-dm" group.

        To unsubscribe from this group and stop receiving emails from it, send an email to bacnet-dm+unsubscribe@....

        To post to this group, send email to bacnet-dm@....

        For more options, visit https://groups.google.com/groups/opt_out.

         

         

         

        --
        You received this message because you are subscribed to the Google Groups "bacnet-dm" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to bacnet-dm+unsubscribe@....
        To post to this group, send email to bacnet-dm@....
        For more options, visit https://groups.google.com/groups/opt_out.
         
         

      • Dave Robin
        I agree entirely. A good list of scopes/roles would greatly enhance plug and play with auth servers (your six is better than my three, but I don t anticipate
        Message 3 of 5 , May 1, 2013
        • 0 Attachment
          I agree entirely. A good list of scopes/roles would greatly enhance plug and play with auth servers (your six is better than my three, but I don't anticipate needing twenty). 

          As long as we have an escape hatch for exceptional cases (like "View Classified" for a DoD site I know of), the we have a good chance at interoperability while keeping the exceptional cases "in the tent" rather than making them go proprietary. 

          Dave

          On Tuesday, April 30, 2013 at 7:47 PM, Carl Neilson wrote:

          I liked the idea of the OAuth scope being a mix of application area and role.

           

          With a site/deployment controlled application area and a standardized role, I think that we will have a better chance at providing good directions to implementers along with the configurability that sites need to manage deployments.

           

          View

          Modify Runtime  (adjust setpoints)

          Runtime Control (write values for the purpose of controlling actions)

          Command Override (placing objects out of service, commanding at priorities that would limit runtime control, etc)

          Configuration and Programming (configuration, and programming actions, adding TLs, EVs etc)

          Installation (more technical configuration actions, adding IO points, uploading different application programs)

           

          I see the benefits as being:

          - to deploy product that use the standard role names, the assignment of allowable scopes to users is easy and does not need to be adjusted when a new product is added to the system.

          - there will be less chance of orthogonal role sets being created by different vendors (because we have provided descriptions that guide vendors on how to assign roles to data elements).

          - we would avoid problems like a product having 16 different slots for roles, which it mandates have 16 different names, and thus cannot be merged into the 2 roles that site X decided to deploy.

          - allowing additional proprietary roles allows for added granularity if a vendor deems it necessary.

           

          I can see no downsides to this approach.

           

          Carl

           

          From: bacnet-dm@... [mailto:bacnet-dm@...] On Behalf Of Dave Robin
          Sent: Tuesday, April 30, 2013 3:32 PM
          To: bacnet-it-wg@yahoogroups.com
          Cc: bacnet-dm@...
          Subject: Re: [bacnet-it-wg] RE: [bacnet-dm] Update to Web Services Addendum (rev 11)

           

          That was going out on a limb a bit just to get a straw man out there. In our call we had left it that the realms were required to be writable so sites could be in charge of those names.  And we decided that we should have some standard scopes that would be "under" those realms. 

           

          In this draft I got rid of the realm/scope confusion which left just scopes. But the idea that the site should be "in charge of names" still resonated and so it spilled over from realms to scopes. 

           

          Since it seemed on our last call that we wanted standard scope names, and yet on the call before that, we said we did *not* want standard scope names. So I got gun shy about enumerating a standard set and decided that it should be another "site policy" and this that they should be writable. 

           

          So... rather than saying "Since the auth server is now in charge of the scopes",  what I should have said is "Since the site is now in charge of assigning the scope identifiers..."  the auth server and the resource server shall both be configurable to use the site-specific scopes. 

           

          The reason for the "mapping" in the  server device is that the device might might support a very fine grained separation of data and actions internally but the site site doesn't care about that (let's say the site only wants to think in terms of gods and peons), and so the site assigns the same scope identifier to several of the fine grained slots in the server device. 

           

          But to bring sanity to the "normal" case, and to hint at the equivalent of a set of "standard" scope identifiers, I actually enumerated three scopes and said something like "unless the server device needs otherwise, use these three scopes". Hopefully that will be enough for most devices and sites and will make a good out of the box default. 

           

          But that might still be too much of a brain twister, so I'm happy to talk about simpler alternatives. But in any case, that's what I meant. 

           

          On Tuesday, April 30, 2013 at 5:59 PM, Carl Neilson wrote:

           

          Dave,

           

          Can you comment further on the pre-amble comment:

          •             It was felt that scopes were akin to roles and that there should be some kind of mapping.  Since the auth server is now in charge of the scopes for the most part, this mapping can be done by the auth server.

           

          Carl


          <image001.png>

          Chair, ASHRAE SSPC 135 (aka The BACnet Committee)

          direct:   +1.604.575.5913

           

           

           

          -----Original Message-----
          From: bacnet-dm@... [mailto:bacnet-dm@...] On Behalf Of Dave Robin
          Sent: Tuesday, April 30, 2013 7:15 AM
          To: bacnet-dm@...
          Cc: IT-WG
          Subject: [bacnet-dm] Update to Web Services Addendum (rev 11)

           

          Data Modelers (and IT-WG, only when we mess with the TLS/OAuth part)

           

          Here is the update based on last week's conference call.  Please join us this Thursday to discuss, or send email anytime.

           

          Dave

           

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

          The bulleted list of changes is too complex/deep for mail to handle gracefully this time, so please just see attached document for committee notes about changes

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

           

          --

          You received this message because you are subscribed to the Google Groups "bacnet-dm" group.

          To unsubscribe from this group and stop receiving emails from it, send an email to bacnet-dm+unsubscribe@....

          To post to this group, send email to bacnet-dm@....

          For more options, visit https://groups.google.com/groups/opt_out.

           

           

           

          --
          You received this message because you are subscribed to the Google Groups "bacnet-dm" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to bacnet-dm+unsubscribe@....
          To post to this group, send email to bacnet-dm@....
          For more options, visit https://groups.google.com/groups/opt_out.
           
           


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