Re: Federation protocols

On 1 June 2013 19:23, Simon Tennant <simon@buddycloud.com> wrote:

> You could reinvent the wheel by using HTTP, and then hope that all major
> browser makers start including your client side certificate code. I
> wouldn't hold my breath.
>

Im unsure what you mean, all browsers have had client side certs for 10
years+.  It's just the UX that is not compelling.


>
> Alternatively you could simply build on federated protocols that already
> include strong identity, encryption and dial-back authenticity like XMPP.
> And instead spend your energy on designing your interchange messages.
>

XMPP is a great system.  No problem with hacking on it.  But an HTTP
solution is also needed if you want to play in the same league as the big
guns.


>
> S.
>
>
> On 1 June 2013 18:49, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>>
>>
>>
>> On 1 June 2013 18:40, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
>>
>>> Melvin Carvalho wrote:
>>>
>>>>
>>>>
>>>> Yes, that's a nice idea, and something I have been doing for many
>>>> years.  But there are two issues with this going mainstream.
>>>>
>>>> 1.  Only a small minority of web servers run SSL with the option to
>>>> accept client side certificates.
>>>>
>>>> 2. The user experience for X.509 is not ideal in current browsers, and
>>>> there will be some lead time before that is improved.  I personally talked
>>>> to the head of services at canonical and mark shuttleworth about this very
>>>> idea, but it was felt it was not yet user friendly enough to be adopted.
>>>>
>>>> So in the short to medium term at least we need stop gap.
>>>>
>>>
>>> So... you consider:
>>> - modify HTTP to add a new header
>>>
>>
>> It's one route, but you need not modify HTTP, arbitrary headers are
>> allowed.  You just need consensus on a name and text.
>>
>>
>>> - modify HTTP in a way that makes very little or no sense from a
>>> protocol layering perspective
>>>
>>
>> Your opinion.  You did not state your preferred layer.
>>
>>
>>> - modify HTTP in a way that duplicates perfectly good existing mechanisms
>>>
>>
>> Please do let me know if you are aware of an existing header, that was my
>> original question.
>>
>>
>>> - push that all through at least some basic level of standardization
>>>
>>
>> Adding a header is a pretty easy thing to do.  You just need a name and
>> some text.  HTTP was designed to allow this.
>>
>>
>>> AND
>>> - expect browser makers to implement it
>>>
>>
>> They already do.  All AJAX requests allow a header to be set.
>>
>>
>>> - expect a significant number of web servers to implement
>>>
>>
>> All web servers do already support arbitrary headers.
>>
>>
>>>
>>> And you consider that a short term stopgap measure?
>>>
>>> The reality is that folks don't use the existing mechanisms because they
>>> don't care, not because it's difficult.  People who care, or who are
>>> required to, already have and use perfectly reasonable options, on huge
>>> scales.  In particular, I'll note:
>>> - MS Active Directory (pretty much universal in the enterprise space)
>>> - X.509 certificates w/ LDAP (pretty much universal in the Federal space)
>>>
>>
>> I'm totally for using X.509 certificates for this and have been arguing
>> several years for their adoption.  The bigcos are blocking it so far due to
>> UX.  We were unable to get status.net to support it even though we had
>> people ready to work on the code.  By all means do try and get X.509
>> deployed, I'll write code for it, and support your messaging, but expect
>> pushback due to the X.509 user experience.
>>
>>
>>>
>>> Creating yet another mechanism, to address non-existent demand, is a
>>> waste of time.
>>>
>>> Miles
>>>
>>>
>>> --
>>> In theory, there is no difference between theory and practice.
>>> In practice, there is.   .... Yogi Berra
>>>
>>>
>>>
>>
>
>
> --
> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
> goo.gl/tQgxP
>