<br>so we've got two cases, caller-id and federation.<br><br>to implement caller-id, the receiving site just has to publish what<br>their caller-id convention is. The openID protocol does not need<br>to define this, but could repeat the suggestion you have made as
<br>a suggestion. If openID site creation toolkits provide a primitive<br>to create the properly formatted link, that would be cool.<br><br>The use-case I have in mind for federation is something like<br>services that add information to identities, for instance a
<br>reputation service (such as a credit rating service.) Such a service<br>would associate identies with additional information. To reduce<br>load on identity providers, and simplify software that is a client<br>of the reputation service, the reputation service might provide
<br>identities.<br><br>That kind of thing could be built on openID as it is now, with additional<br>integration instructions provided by the service. Federation also does<br>not need additional complexity added to the core openID specification,
<br>but adding such might have benefit for standardizing and easing openID-based<br>additional services.<br><br>The addition might be to provide a multi-level caching system similar to<br>the way DNS servers work.<br><br>
If my service is hosted at a hosting service and I want to use openID, I<br>would make calls to the local openID cache rather than directly to the<br>user's IDp.<br><br>That imagined additional layer again does not need to be part of the openID spec,
<br>but might be mentioned as a possibility, or described in a separate document.<br>(unless it's already in there -- it might be)<br><br>-- <br>pre-Á, Á, Â, rc, release.