<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    +1 from me.<br>
    <br>
    <div class="moz-cite-prefix">On 13.02.2015 22:19, Morgan Fainberg
      wrote:<br>
    </div>
    <blockquote cite="mid:etPan.54de6a53.1190cde7.173@nullptr.local"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <style>body{font-family:Helvetica,Arial;font-size:13px}</style>
      <div id="bloop_customfont"
        style="font-family:Helvetica,Arial;font-size:13px; color:
        rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On February
        13, 2015 at 11:51:10 AM, Lance Bragstad (<a
          moz-do-not-send="true" href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>)
        wrote:</div>
      <div>
        <blockquote type="cite" class="clean_bq" style="color: rgb(0, 0,
          0); font-family: Helvetica, Arial; font-size: 13px;
          font-style: normal; font-variant: normal; font-weight: normal;
          letter-spacing: normal; line-height: normal; orphans: auto;
          text-align: start; text-indent: 0px; text-transform: none;
          white-space: normal; widows: auto; word-spacing: 0px;
          -webkit-text-stroke-width: 0px;"><span>
            <div>
              <div>
                <div dir="ltr">Hello all, 
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>I'm proposing the Authenticated Encryption (AE)
                    Token specification [1] as an SPFE. AE tokens
                    increases scalability of Keystone by removing token
                    persistence. This provider has been discussed prior
                    to, and at the Paris summit [2]. There is an
                    implementation that is currently up for review [3],
                    that was built off a POC. Based on the POC, there
                    has been some performance analysis done with respect
                    to the token formats available in Keystone (UUID,
                    PKI, PKIZ, AE) [4]. </div>
                  <div><br>
                  </div>
                  <div>The Keystone team spent some time discussing
                    limitations of the current POC implementation at the
                    mid-cycle. One case that still needs to be addressed
                    (and is currently being worked), is federated
                    tokens. When requesting unscoped federated tokens,
                    the token contains unbound groups which would need
                    to be carried in the token. This case can be handled
                    by AE tokens but it would be possible for an
                    unscoped federated AE token to exceed an acceptable
                    AE token length (i.e. < 255 characters). Long
                    story short, a federation migration could be used to
                    ensure federated AE tokens never exceed a certain
                    length. </div>
                  <div><br>
                  </div>
                  <div>Feel free to leave your comments on the AE Token
                    spec. </div>
                  <div><br>
                  </div>
                  <div>Thanks! </div>
                  <div><br>
                  </div>
                  <div>Lance</div>
                  <div><br>
                  </div>
                  <div>[1] <a moz-do-not-send="true"
                      href="https://review.openstack.org/#/c/130050/">https://review.openstack.org/#/c/130050/</a></div>
                  <div>[2] <a moz-do-not-send="true"
                      href="https://etherpad.openstack.org/p/kilo-keystone-authorization">https://etherpad.openstack.org/p/kilo-keystone-authorization</a></div>
                  <div>[3] <a moz-do-not-send="true"
                      href="https://review.openstack.org/#/c/145317/">https://review.openstack.org/#/c/145317/</a></div>
                  <div>[4] <a moz-do-not-send="true"
                      href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</a></div>
                </div>
__________________________________________________________________________<span
                  class="Apple-converted-space"> </span><br>
                OpenStack Development Mailing List (not for usage
                questions)<span class="Apple-converted-space"> </span><br>
                Unsubscribe:
                <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><span
                  class="Apple-converted-space"> </span><br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span
                  class="Apple-converted-space"> </span></div>
            </div>
          </span></blockquote>
      </div>
      <p><br>
      </p>
      <p>I am for granting this exception as long as it’s clear that the
        following is clear/true:</p>
      <p>* All current use-cases for tokens (including federation) will
        be supported by the new token provider.</p>
      <p>* The federation tokens being possibly over 255 characters can
        be addressed in the future if they are not addressed here (a
        “federation migration” does not clearly state what is meant.</p>
      <p>I am also ok with the AE token work being re-ordered ahead of
        the provider cleanup to ensure it lands. Fixing the AE Token
        provider along with PKI and UUID providers should be minimal
        extra work in the cleanup.</p>
      <p>This addresses a very, very big issue within Keystone as
        scaling scaling up happens. There has been demand for solving
        token persistence for ~3 cycles. The POC code makes this
        exception possible to land within Kilo, whereas without the POC
        this would almost assuredly need to be held until the L-Cycle.</p>
      <p><br>
      </p>
      <p>TL;DR, I am for the exception if the AE Tokens support 100% of
        the current use-cases of tokens (UUID or PKI) today.</p>
      <p><br>
      </p>
      <p>—Morgan</p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>