<div dir="ltr"><div>Hi Steve,</div><div><br></div><div>Thanks for your explanation! I have some further questions:</div><div><br></div><div>You said that OS-OAUTH doesn't make Keystone a proper OAuth provider, so what is missing? Can name some of the missing parts?</div><div dir="ltr"><div><br></div><div>Another thing, a backlog started by you proposed to unify delegation features [1]. Its spec uses terms of "trustor" and "trustee". Can I say that the unified delegation workflow will be more like (or even the same as) the one in current OS-TRUST?</div><div><br></div></div><div dir="ltr"><div><span style="line-height:1.5">[1] <a href="https://specs.openstack.org/openstack/keystone-specs/specs/backlog/unified-delegation.html" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/backlog/unified-delegation.html</a></span><br></div><div><br></div><div>John</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">Steve Martinelli <<a href="mailto:s.martinelli@gmail.com" target="_blank">s.martinelli@gmail.com</a>> 於 2016年6月28日 週二 下午1:57寫道：<br></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" style="font-size:12.8px">So, the os-oauth routes you mention in the documentation do not make keystone a proper oauth provider. We simply perform delegation (one user handing some level of permission on a project to another entity) with the standard flow established in the oauth1.0b specification.<div><br></div><div>Historically we chose oauth1.0 because one of the implementers was very much against a flow based on oauth2.0 (though the names are similar, these can be treated as two very different beasts, you can read about it here [1]). Even amongst popular service providers the choice is split down the middle, some providing support for both [2]</div><div><br></div><div>We haven't bothered to implement support for oauth2.0 since there has been no feedback or desire from operators to do so. Mostly, we don't want yet-another-delegation mechanism in keystone, we have trusts and oauth1.0; should an enticing use case arise to include another, then we can revisit the discussion. </div><div><br></div><div>[1] <a href="https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/" target="_blank">https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/</a> </div><div>[2] <a href="https://en.wikipedia.org/wiki/List_of_OAuth_providers" target="_blank">https://en.wikipedia.org/wiki/List_of_OAuth_providers</a></div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 27, 2016 at 11:15 PM, 林自均 <span dir="ltr"><<a href="mailto:johnlinp@gmail.com" target="_blank">johnlinp@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>When I am searching for OAuth provider in Keystone, I found only OAuth 1.0. I am a little bit curious about the decision of 1.0 over 2.0. I failed to see the reason in the <a href="https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-oauth1-ext.html" target="_blank">documentation</a> and <a href="https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth" target="_blank">this blueprint</a>. Is OAuth 2.0 not compatible with design of Keystone?</div><div><br></div><div>John</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div></div></blockquote></div></div></div>