[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