<br><br><div class="gmail_quote">On Fri, Feb 18, 2011 at 14:52, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Fri, Feb 18, 2011 at 08:24, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>To everybody who was in the f2f this week, thanks very much. It was a very productive session. </div><div><br></div><div>Couple of questions to the decisions reached in the meeting: </div><div><br></div><div><b>1. UserInfo Endpoint as the access_token exchange. </b></div>


<div><br></div>If unlike the current draft the UserInfo Endpoint was to return the access_tokens for each endpoints instead of the AuthZ Server, i.e., the AuthZ Server just returns the access_token for the UserInfo Endpoint, then this access_token for the UserInfo Endpoint MUST contain all the attribute requests either explicitly or by reference. Is that correct? </blockquote>

<div><br></div></div><div>No. I think the plan is to have a single access_token or code that codifies access to everything.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
<br></div><div><b>2. Migration / Delegation</b></div><div><br></div><div>We did not quite get to talk about delegation explicitly but talked it in terms of the identifier migration. Well, identifier migration is a kind of Delegation really. When I thought a little about various use cases, I came to the conclusion that we probably want delegation, perhaps though in a limited manner. </div>


<div><br></div><div>In the Migration / Delegation scenario, there are three actors: </div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>(a) The identifier issuer (iss)</div>
<div>(b) The user (user) that this identifier (id) points to</div><div>(c) The delegated server (ds)</div></blockquote><div><br></div><div>To make it work, the following has to happen. </div><div><br></div><div>(1) The identifier cannot be any random string, but be a pair of the iss and the id string. It could be formed into a URI or can be a JSON structure. Per the previous discussion in November, we are probably taking the later approach. So, it will look like: </div>


<div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><pre style="font-family:'Courier New', Courier, monospace;font-size:small;text-align:left;padding-top:4px;padding-right:4px;padding-bottom:4px;padding-left:4px;color:rgb(0, 0, 0);background-color:rgb(204, 204, 204)">
<span style="font-family:arial;white-space:normal">{"iss":"issuer_domain", <br> "id":"user_id""}</span></pre><div><span style="font-family:arial;white-space:normal"><br></span></div>

</span></div></blockquote><div><br></div></div><div>Well, yes, but the JWT token already has a place for the issuer so there's no need to specify this beyond saying that this is a JWT token encoding the 'id'</div>
<div class="im"><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><div><span style="font-family:arial;white-space:normal">
</span></div></span></div><div>(2) The "iss" MUST authoritatively indicate that it wants to delegate to "as". This has to be indicated by another parameter, e.g., "ds". So, the structure will look like: </div>


<div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><pre style="font-family:'Courier New', Courier, monospace;font-size:small;text-align:left;padding-top:4px;padding-right:4px;padding-bottom:4px;padding-left:4px;color:rgb(0, 0, 0);background-color:rgb(204, 204, 204)">
<span style="font-family:arial;white-space:normal">{"iss":"issuer_domain", <br> "id":"user_id", <br> "ds":"delegated_server_id"}</span></pre>
<div><br></div></span></div></blockquote><div><br></div></div><div>I don't understand how the above follows. Let's re-structure the current core draft to capture the framework we discussed, then we can go into details such as this.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><div></div></span></div><div>

(3) The structure MUST be signed by the iss using its private key to show that "iss" is authoritatively delegating authorization to "ds": using symmetric key here will complicate things greatly, so asymmetric key crypto is the only viable way. In our current way of thinking, it will be a JWT, and the "iss" in the header MUST be the same as the "iss" in the full identifier. </div>


<div><br></div><div>So, the JWT claim (payload) segment now will look like: </div><div><pre style="text-align:-webkit-auto;font-size:small;padding-top:4px;padding-right:4px;padding-bottom:4px;padding-left:4px;color:rgb(0, 0, 0);background-color:rgb(204, 204, 204)">
<font face="arial"><span style="white-space:normal"><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><pre style="font-family:'Courier New', Courier, monospace;font-size:small;text-align:left;padding-top:4px;padding-right:4px;padding-bottom:4px;padding-left:4px;color:rgb(0, 0, 0);background-color:rgb(204, 204, 204)">
{"iss":"issuer_domain",
 "id":"user_id",
 "ds":"delegated_server_id",
 "alg":"RS256",
 "exp":"1300752001"}</pre></span></span></font></pre></div><div>And the JWT header segment will look like: </div><div><br></div><div><span style="font-family:verdana, charcoal, helvetica, arial, sans-serif"><pre style="font-family:'Courier New', Courier, monospace;font-size:small;text-align:left;padding-top:4px;padding-right:4px;padding-bottom:4px;padding-left:4px;color:rgb(0, 0, 0);background-color:rgb(204, 204, 204)">
{"alg":"RS256",
 "x5u":"<a href="http://example.com/certs.pem" target="_blank">http://example.com/certs.pem</a>"}</pre><div><br></div></span></div><div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap">The resulting JWT is as usually a three segment string with header.payload.signature. </span></font></div>


<div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap">The resulting JWT string is the delegation token. By sending this in the UserInfo Endpoint response, the receiver can verify that this delegation / migration is authoritative by first checking the validity of the delegation token, then comparing that "ds" is the server that it is talking to. </span></font></div>


<div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap">Right? </span></font></div>


<div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="'Courier New', Courier, monospace"><span style="white-space:pre-wrap">=nat</span></font></div>


<div><span style="font-family:'Courier New', Courier, monospace;white-space:pre-wrap"><br></span></div><font color="#888888"><div><span style="font-family:'Courier New', Courier, monospace;white-space:pre-wrap"><br>


</span></div><div><br></div><div><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>


</div>
</font></blockquote></div></div><br><br clear="all"><br>-- <br><font color="#888888">--Breno<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br>