<font size=2 face="sans-serif">I am a vote of Yes for the Authenticated
Encryption (AE) Token specification receiving a Spec Freeze exception.
  This approach has tremendous potential to significantly improve
Keystone and POC code already exists. I feel there is enough runway that
it is worth trying to move forward with this spec in this release cycle.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
<br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Kendra Witherspoon (919) 254-0680</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Lance Bragstad <lbragstad@gmail.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">02/13/2015 02:52 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[openstack-dev]
[keystone] SPFE: Authenticated Encryption (AE)        Tokens</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Hello all, </font>
<br>
<br>
<br><font size=3>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]. </font>
<br>
<br><font size=3>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. </font>
<br>
<br><font size=3>Feel free to leave your comments on the AE Token spec. </font>
<br>
<br><font size=3>Thanks! </font>
<br>
<br><font size=3>Lance</font>
<br>
<br><font size=3>[1] </font><a href=https://review.openstack.org/#/c/130050/><font size=3 color=blue><u>https://review.openstack.org/#/c/130050/</u></font></a>
<br><font size=3>[2] </font><a href="https://etherpad.openstack.org/p/kilo-keystone-authorization"><font size=3 color=blue><u>https://etherpad.openstack.org/p/kilo-keystone-authorization</u></font></a>
<br><font size=3>[3] </font><a href=https://review.openstack.org/#/c/145317/><font size=3 color=blue><u>https://review.openstack.org/#/c/145317/</u></font></a>
<br><font size=3>[4] </font><a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/"><font size=3 color=blue><u>http://dolphm.com/benchmarking-openstack-keystone-token-formats/</u></font></a><tt><font size=2>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>