<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? <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 class="webkit-indent-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 class="Apple-style-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 class="Apple-style-span" style="font-family: arial; white-space: normal; ">{"iss":"issuer_domain", <br> "id":"user_id""}</span></pre><div><span class="Apple-style-span" style="font-family: arial; white-space: normal; "><br>
</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 class="Apple-style-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 class="Apple-style-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><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 class="Apple-style-span" face="arial"><span class="Apple-style-span" style="white-space: normal;"><span class="Apple-style-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 class="Apple-style-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">http://example.com/certs.pem</a>"}</pre><div><br></div></span></div><div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;">The resulting JWT is as usually a three segment string with header.payload.signature. </span></font></div>
<div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;"><br></span></font></div><div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;">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 class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;"><br></span></font></div><div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;">Right? </span></font></div>
<div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;"><br></span></font></div><div><font class="Apple-style-span" face="'Courier New', Courier, monospace"><span class="Apple-style-span" style="white-space: pre;">=nat</span></font></div>
<div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; white-space: pre; "><br></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; white-space: pre; "><br>
</span></div><div><br></div><div><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>