[OpenID] foaf and openid
Story Henry
Henry.story at bblfish.net
Tue Jul 24 18:05:11 UTC 2007
Sorry again for taking time to respond here. I have been reading the
spec [1],
and the book [2] carefully to get a better grasp of the vocabulary
being used.
On 20 Jul 2007, at 16:59, Boris Erdmann wrote:
> 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
>
That is indeed very close to what I was thinking of.
Perhaps your way of putting it is more general. Let me think out loud
using the openid vocabulary I am still learning.
1. I the End User, wants to use a service at dzone.com (the Relying
Party). So I click on the vote button in my browser (User Agent)
2. The service returns a representation asking me to enter my OpenId.
I enter http://openid.sun.com/bblfish and POST the result.
3. Dzone.com now downloads a representation returned by my OpenId
resource, which contains header information pointing to both my
OpenId Provider Endpoint URL
(https://openid.sun.com/openid/service) and to my foaf file (the
currently non existent http://openid.sun.com/bblfish/foaf.rdf) which
could of course be the same as my OpenId .
4. All the magic starts happening whereby dzone, the user agent, and
my OpenidProvider negotiate.
Now at this point it would be useful to identify the RelyingParty
with a URI, and to specify the realm of the relying party too. There
is a realm property (2.x protocol) or the openid.trust_root (1.1
protocol) which can be somehow used for this function. For dzone the
trust_root is http://www.dzone.com/openidauth . This allows the
Client (Relying Party) to ask for automatic authentications for a set
of urls once, and so reduce the number of services where the end user
is required to type his password into the user agent.
So I suppose my thought was that perhaps the foaf file could return
different representations depending on the requesting agent, by
somehow tying the request to the openid.trust_root of http://
www.dzone.com/openidauth . I was not sure how to ties these together.
A generalization of your suggestion would be that the foaf resource
itself be part of a realm of resources that end users can log into,
each resource of which can then return different representations
depending on the identity of the requester. In this particular case
we would like dzone.com to itself have an OpenId that is itself
somehow tied to the openid.trust_root or realm, perhaps this openid
could itself be the trust_root http://www.dzone.com/openidauth, so
that the realm that contains the foaf resource would know to return
more information on an HTTP GET of the foaf.
Here I have the feeling that we are in the presence of some strong
symmetries, and that perhaps this could be simplified somewhere.
Problem: How would we indicate in a machine readable manner to the
client that the foaf file is part of a realm that the client needs to
log into? After all there will be foaf files that are not part of
such realms.
Solutions:
1. Well this could somehow be transmitted as part of one of the
responses between the client and the Provider. Say with an extra tag:
openid.openid.service=http://openid.sun.com/bblfish/service,
openid.openid.realm=http://openid.sun.com/bblfish
2. It could be part of the foaf file itself.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix openid: <http://openid.net/ont#> .
<> a foaf:PersonalProfileDocument;
foaf:primaryTopic <#bblfish>;
openid:service <service> . #is this enough?
<#bblfish> a foaf:Person .
...
This would be useful so that people downloading the foaf file could
know that they might get more information if they could log into the
service (using their openid). Cool thing: you can imagine that people
who log into the openid:service with a foaf name that identifies them
as being a friend, will get all the foaf file.
Clearly both would be useful. One thing that may be useful would be
to create an rdf vocabulary for openid, btw. So that one can describe
these relations.
> 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)
>
Do you have a pointer explaining clearly what immediate auth
requests are for, I could not quite completely work out what they were.
> 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
Yes though if you want to use XSLTs you would also need to define an XML
crystalisation of a foaf:Document [3]. One can also imagine that the
openid
xhtml representation were foaf encoded using eRDF.
The foaf group have added a foaf:openid relation that is inverse
functional, ie
an openid will identify one agent uniquely even if indirectly, so
there is no trouble
having the openid and foaf representations be different. [4]
> and could render the foaf data into XHTML (but this would break simple
> HTML discovery for OpenID). Or it could be done using Yadis.
I don't know about yadis. Let me look. Mhhh. Looks like my suggestion
number 2 above can be thought
of as an initial sketch of an RDF equivalent. It should be easy to do
this with RDF btw...
>
> Just a few thoughts... Is this approach too simple?
Not sure. Are we on the same wavelengths here?
>
> Boris
>
[1] http://openid.net/specs/openid-
authentication-2_0-11.html#requesting_authentication
[2] http://openidbook.com/index.html
[3] http://blogs.sun.com/bblfish/entry/crystalizing_rdf
[4] run
cwm http://xmlns.com/foaf/0.1/ | less
and search for the openid relation
>
> On 7/20/07, Story Henry <Henry.story at bblfish.net> wrote:
>> Hi,
>>
>> It occurred to me recently that there was a nice and simple use of
>> foaf and openid, where the two could be made to mesh very nicely and
>> improove the user experience.
>>
>> http://blogs.sun.com/bblfish/entry/foaf_openid
>>
>> The idea is simply to add a foaf link to the html representations of
>> the openid resource, so that servers could use that information to
>> present more information to the client.
>>
>> Now a little more advanced question would be to specify for each
>> service what type of depth of access one may want to give them to
>> one's foaf file. This is where a little protocol tricks could come in
>> useful.
>>
>> Henry
>>
More information about the general
mailing list