- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 04 Apr 2013 10:13:20 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: public-webid <public-webid@w3.org>, Mark Nottingham <mnot@mnot.net>
- Message-ID: <515D8A80.1000105@openlinksw.com>
On 4/4/13 9:53 AM, Melvin Carvalho wrote: > > > > On 4 April 2013 15:45, Kingsley Idehen <kidehen@openlinksw.com > <mailto:kidehen@openlinksw.com>> wrote: > > On 4/4/13 6:11 AM, Melvin Carvalho wrote: >> >> >> >> On 4 April 2013 03:32, Kingsley Idehen <kidehen@openlinksw.com >> <mailto:kidehen@openlinksw.com>> wrote: >> >> On 4/3/13 7:01 PM, Mark Nottingham wrote: >> >> On 04/04/2013, at 4:18 AM, Kingsley Idehen >> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> >> wrote: >> >> All, >> >> I think the HTTP "From:" header [1] is now truly >> archaic circa. 2013. If the range of this particular >> predicate was a URI it would really aid our quest for >> a RWW. >> >> It's in active use by spiders and robots. >> >> Suggestion: >> >> As part of our RWW bootstrap effort, we could >> consider an "X-From:" header that basically takes a >> URI or Literal value. >> >> I think we can flesh this out across WebID and RWW >> via implementations before moving up to TAG and IETF. >> >> Mark: what do you think, anyway ? :-) >> >> If you want something that takes a link, we have a Link >> header. >> >> Whatever you do, don't prefix it with X-. >> >> Cheers, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> >> >> Okay re. not taking the X- route. >> >> With regards to "From:" I am saying it should accept literals >> or URIs instead of just literals. Net effect, I can then use: >> kidehen@openlinksw.com <mailto:kidehen@openlinksw.com> or >> <mailto:kidehen@openlinksw.com >> <mailto:kidehen@openlinksw.com>> or >> <http://kingsley.idehen.net/dataspace/person/kidehen#this> . >> >> "Link:" is also a good idea, I'll maul this over as it could >> also work from the desired bootstrap perspective. >> >> >> +1 >> >> In fact we could call this "WebID Simple" perhaps? > > The name should reflect use. Here we want to place a WebID in the > "From:" header in an HTTP request. We then seek to have a server > verify the WebID in "From:" using: > > > Whether the server wants to verify or not is up to the server. > > > 1. a simple profile lookup -- no TLS > > > Yes, This is the power of the follow your nose pattern. > > 2. a more secure lookup -- using TLS i.e., WebID+TLS (this would > mean using HTTP redirection to an HTTPS URL that forces the client > to present a Certificate with a WebID watermark). > > > Yes > > There are many more options for auth e.g. cookies, unguessable > strings, one time tokens, security by obscurity. These can be part of > > A) the headers > B) the URL > C) a cookie > D) the protocol handshake (eg wss) > E) the profile page (e.g. you put a token in your page as auth) > > All of these are well established methods for auth. The game starts > with identification. Yes, and we want to enable browser users to denote themselves using URIs or Literal values placed in the "From:" header of HTTP requests. Mark: I've mauled over "Link:" and it does provide a solution. The only problem with said solution is that it lacks the intuition of "From:" by forcing folks to comprehend entity relationship semantics expressed in "Link:" based triples. If we can just have "From:" accepting literals or URIs, we lay the foundation for solving many of today identity and identification problems on the Web. Note, adding URIs as a value option will not break crawler and other users that process literal values. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 4 April 2013 14:13:48 UTC