[foaf-protocols] OpenId4.me -- Re: [OpenID] Should Openid's resolve to their descriptors in v.next?

Santosh Rajan santrajan at gmail.com
Fri Nov 20 04:32:06 CET 2009

Thanks for the hint Peter. I need to study this in more detail. Looks

On Fri, Nov 20, 2009 at 8:46 AM, Peter Williams <home_pw at msn.com> wrote:

> The only thing I see as viable alternative to rdfa would be some hatom
> microformat.
> If the major content mgy systems such as drupal become rdfa capable, the
> complexity of the rdf triple model becomes a non issue.
> Using the triple model for the data model also aligns with the xri/Xdi
> Model - which is a custom rdf vocabulary tuned to fine grained access
> controls and data contracts. ( just like tagset allow one to use XML to
> define markups providing custom languages, so one can define rdf vocabs -
> that let custom graph meta-structures similarly characterise custom data
> meshes (ie security models with specific lattices for authorization or
> obligation structures, ...).
> On Nov 19, 2009, at 6:29 PM, Santosh Rajan <santrajan at gmail.com> wrote:
> Yes indeed Peter. More than anything, it has cleared my confused head (as
> you can make out from my original post).
> We need to seriously look at RDF + RDFa. Or may be something analogous to
> it.
> I am beginning to believe cows will lay eggs too :-)
> On Fri, Nov 20, 2009 at 7:39 AM, Peter Williams < <home_pw at msn.com>
> home_pw at msn.com> wrote:
>> I have to say santosh, I find the story that henry tells to be very
>> compelling.
>> It didn't quite work last year. But now with rdfa expressing the triples
>> in html files and with foaf+ssl enabling  a (photo) server to retrieve
>> access controlled subgraphs of data attributes the sheer parsimony of
>> required identity concepts and the  sheer consistency of just a few axioms
>> in the underlying identity logic makes it all quite impressive. The subject
>> identifier model in the I&a space has merged with the object identifer model
>> in the data world
>> On Nov 19, 2009, at 5:04 PM, Story Henry < <henry.story at bblfish.net>
>> henry.story at bblfish.net> wrote:
>>  Hi Santosh,
>>> After commenting on your mail below, I realised that my latest blog post
>>> would be of interest to you " <http://openid4.me/>http://openid4.me/ --
>>> OpenId ♥ foaf+ssl" .
>>> But there is more to my answer below than that...
>>> On 19 Nov 2009, at 15:54, Santosh Rajan wrote:
>>>> This is something that has me stumped. I am sure this subject has been
>>>> discussed in various forms before. But i think we need to clarify this,
>>>> now
>>>> that we are talking about openid v.next.
>>>> Let us start with the semantic web folks.
>>> I am really pleased that you are bringing up the semantic web here. You
>>> have things mostly right. They are in fact a bit simpler that what you make
>>> them below.
>>> let us first define two prefixes using the N3 notation
>>> @prefix foaf: < <http://xmlns.com/foaf/0.1/>http://xmlns.com/foaf/0.1/>
>>> .
>>> @prefix : < <http://example.com/john#>http://example.com/john#> .
>>>  According to them the answer is no
>>>> (if i have understood them correctly)! eg. if John's OpenID was
>>>>  <http://example.com/john>http://example.com/john, then according to
>>>> the semantic web folks
>>>> 1) <http://example.com/john#me>http://example.com/john#me is John's
>>>> OpenID
>>> It is simpler that that: the openid is simply < <http://example.com/>
>>> http://example.com/john>
>>> OpenIds are indirect identifiers for people. They identify a resource
>>> that is a document. This resource has a unique agent, whose OpenId it is.
>>> :me foaf:openid < <http://example.com/john>http://example.com/john>
>>>  2) <http://example.com/john#home>http://example.com/john#home is John's
>>>> homepage
>>> A homepage is a document. There is no need to use the hash indirection to
>>> identify the document. In the case you are describing the OpenId is the same
>>> as the homepage. So:
>>> :me foaf:homepage < <http://example.com/john>http://example.com/john> .
>>>  3) <http://example.com/john#RDF>http://example.com/john#RDF is John's
>>>> resource descriptor. (I am using
>>>> RDF, or Atom if you may) instead of XRD because I am pissed off by XRD).
>>> yes, but to be consistent with the above let us make that
>>> < <http://example.com/john#me>http://example.com/john#me> a foaf:Person
>>> .
>>> The above are minor but important details to get right. :-)
>>>> Also they have another solution called content negotiation, (but it does
>>>> not
>>>> matter as far as this discussion is concerned).
>>>> Next is OpenID 1.0. According to which John's OpenID resolves to his
>>>> html
>>>> homepage, which will contain his resource descriptor information.
>>>> Then we have directed identity, which resolves to nothing really, other
>>>> that
>>>> some "BIG EGOS". This should be dumped, and we should assuage the big
>>>> ego's
>>>> with an acct: URI. Which is actually fair.
>>> I have not followed the discussion on directed identity. Can you fill me
>>> in?
>>>> Then we come to the final problem of OpenID's and acct: URI's. Both
>>>> should
>>>> resolve to something, and the same thing. The resource descriptor.
>>>> Now I firmly believe that identifiers should resolve to their
>>>> descriptor's.
>>>> It is only fair that identifiers resolve to something meaningful. This
>>>> is
>>>> where i disagree with the semantic web folks.
>>> Here I am not sure where you disagree with semantic web folk. What are
>>> descriptors?
>>> In the above " <http://example.com/john#me>http://example.com/john#me"
>>> is a URI that identifies < <http://example.com/john#me>
>>> http://example.com/john#me>, ie John.  Dereferencing "<http://example.com/john#me>
>>> http://example.com/john#me"
>>> with HTTP, results in a representation of the document <<http://example.com/john>
>>> http://example.com/john> being returned, which indeed describes John.
>>> Ah ok! I get it. You are thinking that the OpenId document should contain
>>> the description about the person! Yes, why not that could be done in RDFa,
>>> for example.
>>> A couple of years ago, as RDFa was not yet finalised I showed how you
>>> could use the link relation in the OpenId page to point to an rdf/xml foaf
>>> file, and then put information there about the user:
>>>  <http://blogs.sun.com/bblfish/entry/foaf_openid>
>>> http://blogs.sun.com/bblfish/entry/foaf_openid
>>>  Then we come to the final question. Do we dump the idea of OpenID's
>>>> resolving to the document page? And make it mandatory for OpenID's to
>>>> resolve to  the descriptors? Or we need a descriptor format that is
>>>> compatible and can be merged in to the html? Or we solve the problem
>>>> with
>>>> content negotiation?
>>> So I think you can have the OpenId refer to the descriptor, as you say.
>>> With RDFa that can work well. It should not be any problem either for the
>>> OpenId page to return an RDF/XML representation too...
>>> Now I think once you have that, then the final problem that Attribute
>>> Exchange architects will find to critique to this set up, and quite
>>> correctly I would like to add, is that the information about the user seems
>>> to be completely public.
>>> But content negotiation can help here too. Essentially all one would need
>>> to do is to enhance the OpenId resource - the Identifier Resource - to
>>> return different rdf enhanced representations, depending on who connects to
>>> the page. Imagine for example that FaceBook made my OpenId be <<http://facebook.com/bblfish>
>>> http://facebook.com/bblfish>. Then when you look at my page all you will
>>> see is just my name and my friends. But if you are logged in and a friend of
>>> mine you will see a lot more about me: my address, my latest posts, my
>>> latest music habits, etc, etc...
>>> Now all that we need to do, is do the same as Facebook, but in a
>>> distributed fashion. So that means that when the Relying Party - the service
>>> that wants to verify my identity, and get some attributes - connects to my
>>> page, it has to simultaneously identify itself, so that this enhanced <<http://facebook.com/bblfish>
>>> http://facebook.com/bblfish> resource can return it a bit more
>>> information - perhaps not as much information as it returns for good friends
>>> of mine, but the type of information that I am willing to return to services
>>> like photo printing services. Ok, for the sake of making this example more
>>> real, let us imagine the Relying Party is a photo printing service.
>>> So the question is how does this enhanced Facebook, identify the
>>> <http://photo.com>photo.com service so that it can return it the correct
>>> subgraph of information. Well clearly <http://photo.com>photo.com has to
>>> log into <http://facebook.com>facebook.com, ie, <http://photo.com>
>>> photo.com has to have it's own OpenId. This could be done by simply
>>> having a pointer in the Identifier page, < <http://facebook.com/bblfish>
>>> http://facebook.com/bblfish> to an OpenId login point. That type of
>>> relation would be easy to create.
>>> The problem is that the above will then require the Relying party to
>>>  1. fetch the openid page
>>>  2. search for that OpenId login page
>>>  3. login using openid
>>>  4. refetch the OpenId page, to get the new more complete representation
>>> This can be done, but this is where foaf+ssl shines: because it can do
>>> all of the above in 1 connection. Ie. the same connection the requests the
>>> page, can be the connection that does the identifying.
>>> Well it should do. This is what I was looking at recently when I proposed
>>> to look at how to build a photo printing service using foaf+ssl.
>>>   <http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo>
>>> http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo
>>> This requires some more thinking about. But I think it does provide a
>>> beginning of an answer for how one can have attribute exchange be RESTful.
>>> Henry Story
>>>> --
>>>>  <http://hi.im/santosh>http://hi.im/santosh
>>>> _______________________________________________
>>>> general mailing list
>>>>  <general at lists.openid.net>general at lists.openid.net
>>>>  <http://lists.openid.net/mailman/listinfo/openid-general>
>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>> _______________________________________________
>>> foaf-protocols mailing list
>>>  <foaf-protocols at lists.foaf-project.org>
>>> foaf-protocols at lists.foaf-project.org
>>>  <http://lists.foaf-project.org/mailman/listinfo/foaf-protocols>
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> --
> <http://hi.im/santosh>http://hi.im/santosh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091120/80272fbf/attachment.htm 

More information about the foaf-protocols mailing list