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

Akbar Hossain akkiehossain at googlemail.com
Fri Nov 20 10:16:48 CET 2009 

Hi

You may find looking at the html source of this example identity page helpful.

Http://openid4.me/http://bblfish.net/people/henry/card%23me

You will see the rdfa markup of a few attributes extracted from henrys
foaf file. As well as the openid link discovery markup. So this page
or something similiar could be used as your openid identity page and
foaf file. A hAtom version should be very doable.

There is a link at the bottom of the page to show its contents in rdf/xml.

Thanks


On 11/20/09, Santosh Rajan <santrajan at gmail.com> wrote:
> Thanks for the hint Peter. I need to study this in more detail. Looks
> promising.
>
> 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
>>
>>
>>
>
>
> --
> http://hi.im/santosh
>

-- 
Sent from my mobile device

More information about the foaf-protocols mailing list