[OpenID] foaf and openid

[Boris Erdmann]

On 7/20/07, Lukas Rosenstock <lukas.rosenstock at identity20.eu> wrote:
> Am 20.07.2007, 16:59 Uhr, schrieb Boris Erdmann
> <boris.erdmann at googlemail.com>:
>
> > Well,
> >
> > if we made
> >
> >   http://mydoma.in/myfoaf.rdf
> >
> > an OpenID2.0 consumer it could be accessed via
> >
> >   http://mydoma.in/myfoaf.rdf?openid_identifier=your.open.id
> >
> > and it would know how much foaf-data to reveal towards the requesting
> > identity. Not much protocol needed here to start with. (Thinking
> > further, this might be one of the first widely adopted use cases for
> > immediate Auth requests)
>
> It is not that simple, because that would work only inside the browser and
> usually it is a 3rd party site or webservice that accesses the resource.
> But I agree that this is a very good use case for enabling authenticated
> webservice requests. Martin Atkins was working on a spec for that and so
> was I, unfortunately I had to time to finish my work - I promise I will.

[foaf only people may skip this paragraph :-)]

Agreed. But then it's more a question of how these services would
authenticate to an OP, so these services could "play" UA towards
http://mydoma.in/myfoaf.rdf .
In addition to yours and Martins work I suggested (as part of
"ClaimOP" back in May on these lists) a method how OPs could publish
their login API, so that (user) agents would know what to post to a
login URL. I suggested two link rel's within the page header (so
theses could stay relative to the login page). Others suggested
Yadis/XRDS publishing here as well. Though my original intention was
to provide some phishing counter measure it would serve this purpose
as well. I could even envision merging this with Seatbelt if that was
OK for VeriSign.

All in all it seems we have another use case for standardized OP discovery.

                            Let's call it OpenOP :-)


As a side note: One could also simply *post* the openid_identifier
field to an (otherwise fully parametrized) FOAF URL. I'm not quite
sure which would be better: leave the URL unvaried or express the
different shapes of data behind the FOAF URL by appending the
requesters OpenID (ending up dealing with classes of equivalence). But
then I currently don't know if that was allowed: e.g. Yadis forbids
posting to a Yadis URL.


> > One would need to think about discovery (but see the sun article you
> > quoted, as this is the "officially" proposed method
> > http://www.foaf-project.org/2004/11/join.html). In an ideal world my
> > FOAF URL could be my OpenID, because every browser understands XSLT
> > and could render the foaf data into XHTML (but this would break simple
> > HTML discovery for OpenID). Or it could be done using Yadis.
>
> Possible, yes, but I would say that the conversion of FOAF to XHTML is
> something that should not be done client-wise but on the server-side. This
> avoids incompatibilities with browsers.
Of course. This was just me dreaming...

> However, XRDS-based discovery of OpenID (aka Yadis) should be the
> method-of-choice anyway.

I actually meant to talk about FOAF discovery at my OpenID URL (the
one I would like to print on my business card or link to). Two methods
come to mind: use the http accept header or html header to resolve
and/or request the XRDS file and find the FOAF URL published there, or
just use the http accept header to access the FOAF data directly at my
OpenID URL.

In the end I could access your FOAF data like this directly (dreaming again):

      http://your.open.id/?openid_identifier=my.open.id  (or the post variant)

by setting the accept header to "Accept: application/foaf+xml" (just like Yadis)

But this would have to be approved by the foaf people, wouldn't it?


Boris

>
> Lukas
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>