<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">An example would be Equifax issuing a JWT with a subject that is an ID issued by Google.<div><br></div><div>In one of the recent connect proposals the subject was a combination of the local userID and the serverID.</div><div>That works until you want a third party to say something about the subject and the servierID changes.</div><div><br></div><div>We could have two different identifier formats, but that would be confusing.</div><div>I think it is better to have a fully qualified identifier and a separate serverID.</div><div><br></div><div>In the simple verification case the RP needs to check that the server part of the subject matches the serverID.</div><div><br></div><div>One of the other reasons for separating protocol endpoints from names is scaling.</div><div><br></div><div>We are likely to see deployments covering perhaps hundreds of Millions of users.</div><div><br></div><div>In those cases having multiple endpoints for the same logical name is a nice feature.</div><div><br></div><div>The problem is that the trust model of checking the host name for the SSL connection potentially breaks.</div><div>I understand the desire for RP simplicity. We should think through the issue.</div><div><br></div><div>John B.</div><div><div><div>On 2011-01-07, at 5:07 AM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I had a talk with JohnB. this morning. <div>Considering third party claims provider use case, it is handy to have a globally unique user identifier. </div><div>There are two ways of doing it. </div><div><br></div><div>1. Use the complex type identifier. e.g., treat the combination of the user_id and server_id/domain as the user identifier. </div>
<div>2. Pre-combine the two such as user_id@server_id OR urn:server_id/user_id etc. <br clear="all"><br></div><div>John's preference was option 2. above. </div><div><br></div><div>Also, we have talked a little bit over the domain transition use cases. </div>
<div>From time to time, the domain get switched. e.g., <a href="http://facebook.com/">facebook.com</a> to <a href="http://fb.com/">fb.com</a> etc. </div><div>To be insulated from it, it may be wise to use an abstract server_id instead of the domain. </div>
<div>(It certainly is the case for relying parties when PPID is being used.) </div><div><br></div><div>Should we consider this? OR should we stick with the domain? </div><div>Note: If we are to use an abstract server_id, verification will probably require signature verification. </div>
<div>-- <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>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>