11 messages in org.foaf-project.lists.foaf-protocols[foaf-protocols] [OpenID] making Open...| From | Sent On | Attachments |
|---|---|---|
| Story Henry | Jan 19, 2010 6:23 am | |
| Santosh Rajan | Jan 19, 2010 7:06 am | |
| Story Henry | Jan 19, 2010 7:27 am | |
| ਸੰਜ੍ਯ | Jan 20, 2010 1:12 am | |
| Allen Tom | Jan 20, 2010 6:48 pm | |
| Pat Cappelaere | Jan 20, 2010 7:24 pm | |
| Melvin Carvalho | Jan 21, 2010 1:06 am | |
| Story Henry | Jan 21, 2010 1:50 am | |
| Story Henry | Jan 21, 2010 2:05 am | |
| Allen Tom | Jan 21, 2010 10:12 am | |
| Peter Williams | Jan 21, 2010 3:42 pm |
| Subject: | [foaf-protocols] [OpenID] making OpenId RESTful | |
|---|---|---|
| From: | Peter Williams (home...@msn.com) | |
| Date: | Jan 21, 2010 3:42:00 pm | |
| List: | org.foaf-project.lists.foaf-protocols | |
Isn't this just identical to the saml attribute query - the one profiled to take a name from the client cert in the ssl handshake released by user to a grid computing endpoint and query the the idp, which in turn makes an ldaps query (whose server may return a referall ldaps URL or a partial resultset -to be further chased by this now "proxy" resource guard "acting for" the rp (partial resultsets often manifest from type inference in the object schema for the named entry, which can mean different mutiple inherited documents are associated with the name claim to obtained from different endpoints when doing insert/select posts))?
On Jan 21, 2010, at 1:50 AM, Story Henry <henry.story at bblfish.net> wrote:
On 21 Jan 2010, at 09:07, Melvin Carvalho wrote:
A longer term and more scalable approach would be to define an Artifact Binding for OpenID - where an artifact (aka a short token) is returned to the RP in lieu of the AX data. The RP then makes a backend direct server call back to the OP with the Artifact to get the actual data. Only the artifact is sent on the browser redirect.
This sounds like what I was suggesting in "Making OpenId RESTful" [1] that started this thread.
Essentially the OpenId provider returns a URL where more information about the user is located. This URL could indeed be a bitly url.
Interesting idea, though it adds another connection, it may be worth it. In this case you could be agnostic of the data format, returning key/ value pairs, FOAF/RDF or ATOM as necessary.
Indeed the web server at that URL can do content negotiation to serve back the URL most desired by the client (The Relying party in this case)
Henry
[1]
http://lists.foaf-project.org/pipermail/foaf-protocols/2010-January/001477.html
_______________________________________________ foaf-protocols mailing list foaf-protocols at lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols