Re: Archaic HTTP "From:" Header

On 4 April 2013 15:45, Kingsley Idehen <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> wrote:
>
>>  On 4/3/13 7:01 PM, Mark Nottingham wrote:
>>
>>> On 04/04/2013, at 4:18 AM, Kingsley Idehen <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 or <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.


>
> Kingsley
>
>
>
>>
>>
>> --
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
> --
>
> 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
>
>
>
>