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

Fri Nov 20 03:05:11 UTC 2009

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> 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> 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/ -- 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/> .
>> @prefix : <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, then according to the semantic web folks
>>> 1) http://example.com/john#me is John's OpenID
>>>
>>
>> It is simpler that that: the openid is simply <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>
>>
>>  2) 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> .
>>
>>  3) 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> 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" is a URI that identifies <
>> http://example.com/john#me>, ie John.  Dereferencing "
>> http://example.com/john#me"
>> with HTTP, results in a representation of the document <
>> 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
>>
>>  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>. 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> 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
>> photo.com service so that it can return it the correct subgraph of
>> information. Well clearly photo.com has to log into facebook.com, ie,
>> 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> 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
>>
>> 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
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091120/362083d6/attachment.htm>