Re: Sketch of a very simple identification protocol

Another idea in the ether these days is much the same thing, but with  
a different focus and nomenclature: it's typically described as doing  
service discovery in a way that doesn't require DNS changes.

How do I as a person, advertise my personal blog, my calendar, my work  
blog at all, let alone as them being related to me?   My calendar is  
probably hosted by my company or at Google, my personal blog at  
LiveJournal, my work blog by some IT team at my company that has  
nothing to do with the email/calendar team.  There's no way I can get  
those service providers to work together or do something that's  
specific to me.  The extensive work on S-NAPTR and DDDS isn't going to  
help because my company won't put a DNS record saying "Lisa's calendar  
is on google under this address".  Nor will anybody else except me.

But since I don't run a DNS server and don't pay GoDaddy to run one  
for me, I'd rather the information about these related resources be in  
an HTTP resource somewhere -- that's a technology I do have access  
to.  We do have a bootstrap problem, but to a certain extent that can  
be solved with well-known naming conventions.  Just like spiders  
recognize "robots.txt" today, there's a good chance that robots or  
other automated agents can recognize a well-known file name for  
information that advertises services.

Lisa

On Apr 1, 2008, at 8:47 AM, Story Henry wrote:

> By thinking about a use case involving Distributed Open Social  
> Networks we found the need for a light weight identification system  
> such as OpenId, but without the many redirects and better able to  
> work with REST web architecture and Linked Data. The main reasons  
> for needing such a protocol were laid out on the Semantic Web  
> mailing list [1].
>
> I summarized and illustrated a sketch of such a protocol on a recent  
> blog post.
>
> http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword
>
> It is very simple, and probably could be further simplified. Some  
> people have noted the similarity with HTTPS, and how this could be  
> thought of as an extension to that perhaps [2]. In any case I  
> thought that with some protocols experts on this list would be able  
> to fill in the gaps, suggest improvements or point to specs that  
> already do what is needed.
>
> Yours sincerely,
>
> 	Henry
>
>
> [1] http://www.w3.org/mid/37747504-ABB6-4074-8C98-2EB543F80993@bblfish.net
> [2] see http://www.w3.org/mid/62649.81.2.120.180.1206622777.squirrel@goddamn.co.uk
>

Received on Tuesday, 1 April 2008 20:39:23 UTC