<br>On Thursday, May 7, 2015, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>On 05/06/2015 06:54 PM, Hu, David J
      (Converged Cloud) wrote:<br>
    </div>
    <blockquote type="cite"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#843c0c"><span style="color:windowtext">david8hu> One of the first thing
          we have to do is get all of our glossary straight </span></span><span style="font-size:11.0pt;font-family:Wingdings;color:#843c0c"><span style="color:windowtext">J</span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#843c0c"><span style="color:windowtext">  I am starting to hear about
          “capability”.  Are we talking about “rule” in oslo policy
          terms? Or “action” in nova policy terms? Or this is something
          new.  For example, “compute:create_instance” is a “rule” in
          oslo.policy enforce(…) definition,  “compute:create_instance”
          is an “action” in nova.policy enforce(…) definition.</span></span></blockquote>
    <br>
    By capability, I ( think I ) mean  Action in Nova terms, as I am
    trying to exclude the internal rules that policy lets you define. 
    However, to further muddy the water, you can actually enforce on one
    of these rules./  For example, the Keystone server enforces on
    "admin_required"  for the V2 API.<br>
    <br>
    The term capability has been thrown around a few times and I picked
    it up.  Really what I want to delineate is the point in the code at
    which  policy gets enforced.<br>
  </div></blockquote><div><br></div><div>I completely agree with Adam. Capabilities are the "actions" a user is allowed to perform. But I'd rather talk in terms of authorized HTTP API calls.</div><div><br></div><div>I've tossed around the idea of something like GET /capabilities where the response included something analogous to a list of APIs where the user (i.e. current token / authorization context) match the relevant policy rules -- but implementing that concept in more than one service would be a huge challenge.</div>