<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">One hybrid option that has been discussed but not implemented to my knowledge.<div><br></div><div>A users public services should be in there XRD/S document that is publicly discoverable.</div><div><br></div><div>However the user could have a AX Attribute which is a XRD/S that contains private endpoint information.</div><div><br></div><div>In a sophisticated IdP they could also populate the private XRD/S with oAuth access tokens for those endpoints if desired.</div><div><br></div><div>John B.<br><div><div>On 2010-02-24, at 6:13 AM, Lukas Rosenstock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Chad!<div>There could be two approaches:</div><div>a) Discovering information along with the OpenID Endpoint.</div><div>b) Receiving data from the OpenID provider after authentication.</div><div><br></div><div>In a), the information to be discovered has to be public and can be read by anyone; it is not even required to actually use OpenID to authenticate. Right now, this can be done with XRDS and Yadis discovery though these may be replaced by the new XRD and/or Webfinger. If you are interested in these things, <a href="http://www.hueniverse.com/">http://www.hueniverse.com/</a> is a great site.</div>
<div><br></div><div>The b) method has the advantage that information is issued by the identity provider after establishing trust and identity; therefore the exchanged information is under the user's control. For this, Attribute Exchange is the way to go! This is extensible and other OpenID extensions could also be introduced. I don't know much about FOAF+SSL, but even this could be applicable.</div>
<div><br></div><div>Regards,</div><div> Lukas Rosenstock</div><div><br><br><div class="gmail_quote">2010/2/18 Chad Groneman <span dir="ltr"><<a href="mailto:chad.groneman@sirsidynix.com">chad.groneman@sirsidynix.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello all,<br>
<br>
I'm investigating the possibility of using OpenID as a way to convey<br>
service information to interested parties. In other words, if a user<br>
logs into a site that would like more specific details on a particular<br>
topic, it could query to get any information providers which are<br>
associated with the user. I imagine using the Attribute Exchange, but<br>
there may be a better solution.<br>
<br>
A very simple example would be if a user logged in to a site that would<br>
like to know the exact location of a user. There could be many<br>
providers of this information, so the site queries for the user's<br>
provider. It finds a provider, and from there is able to query the<br>
provider to find the user's exact location. All this is done without<br>
needing to have the user select their provider from a list and log in to<br>
that provider.<br>
<br>
It seems to me that OpenID would be a good way to do it, although it may<br>
be abusing the Attribute Exchange - especially as more types of services<br>
emerge.<br>
<br>
What are your thoughts? Is this in-line with the goals of OpenID? Is<br>
there anything else you would recommend investigating?<br>
<br>
Thank you.<br>
<br>
--<br>
<font color="#888888">Chad Groneman<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://lukasrosenstock.net/">http://lukasrosenstock.net/</a><br>
</div>
_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-general<br></blockquote></div><br></div></body></html>