<br><br><div class="gmail_quote">On Sat, Feb 19, 2011 at 8:55 AM, 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 15:48, Nat <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 bgcolor="#FFFFFF"><div><div><div>Inline. </div><div><div><br>On 2011/02/18, at 14:53, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank"></a><a href="mailto:breno@google.com" target="_blank"></a><a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div><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" target="_blank"></a><a href="mailto:breno@google.com" target="_blank"></a><a href="mailto:breno@google.com" target="_blank"></a><a href="mailto:breno@google.com" target="_blank">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>On Fri, Feb 18, 2011 at 08:24, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank"></a><a href="mailto:sakimura@gmail.com" target="_blank"></a><a href="mailto:sakimura@gmail.com" target="_blank"></a><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></blockquote></div></div></blockquote><div><br></div></div>Single access token to all the different endpoints? <div>
I thought that we agreed that the authz server returnes an access token which can be exchanged to others at the userinfo ep. (Cirrent core does it at the authz ep).</div><div><br></div><div>At the very least, shared access token across the serves is not a very good idea, IMHO. <br>
</div></div></div></div></blockquote><div><br></div></div><div>The two servers are behind the same ASP. The UserInfo is probably hosted by the ASP itself. Any additional privileges granted for UserInfo endpoint are probably far less interesting than what's protected under other resources. However, use of the OAuth2-standard token downscoping endpoint could be used in a higher security profile.</div>
</div></blockquote><div><br></div><div>I think you are mistaken. I am not talking about the access token that is consumed by the endpoints controlled by the same ASP. </div><div>Remember the talk about the distributed data sources all over, to which the user is granting the access for a service? We talked about it at the end of the meeting. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div><div><div><div><div><br><blockquote type="cite"><div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><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></blockquote></div></div></blockquote><div><br></div></div>This is exactly the iss of the JWT, I am just showing that it simply is the matter of adding id field to it. <div><div><br><blockquote type="cite">
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div><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 "ds". 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></blockquote></div></div></blockquote><div><br></div></div><div>It is a representation of the delegation relationship as a claim. The delegating server must be able to indicate that it is delegating authoritatively. So he has to state it as this claim and sign as in step (3) below. </div>
</div></div></div></div></div></div></blockquote><div><br></div></div><div>Ah, ok. You make it sound far more scary than it is. I read below and the example is clear.</div></div></blockquote><div><br></div><div>Sorry about that. It is just a standard JWT claim with "id" and "ds" as additional items. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div><div><div><div><div><div><br><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
<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"></a><a href="http://example.com/certs.pem" target="_blank"></a><a href="http://example.com/certs.pem" target="_blank"></a><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"></a><a href="http://www.sakimura.org/en/" target="_blank"></a><a href="http://www.sakimura.org/en/" target="_blank"></a><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"></a><a href="http://twitter.com/_nat_en" target="_blank"></a><a href="http://twitter.com/_nat_en" target="_blank"></a><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>
</div></blockquote></div></div></div></div></div><div><span></span></div></div><div><span></span></div></div></blockquote></div></div><br><br clear="all"><br>-- <br><font color="#888888">--Breno<br>
</font></blockquote></div><br><br clear="all"><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>