[OpenID] JanRain library licensing (was: Re: On OpenID 2.0)

[Marius Scurtescu]

On 11-May-07, at 8:16 PM, Chris Messina wrote:

> Just to add a point from related experience and how critical it is to
> have uniformity in library behavior... Think about web browsers and
> how difficult it's been for web designers to deal with conflicting
> rendering engine a)intrepretations of the speck and b) proprietary
> extensions.

Not sure if this is a good example for our case. The technologies  
that browsers need to implement are orders of magnitude more  
complicated than OpenID, so it should be orders of magnitude easier  
to have consistent implementations of OpenID. Also, the browser  
compatibility issues are mostly political imo, not technical.

Mono-cultures are dangerous, and generally they do not survive for  
long. If a specific library was used in most implementation then a  
bug with security implications will suddenly affect a huge number of  
sites. Probably it was mentioned here that this is what happened with  
Drupal and an XML-RPC library (library that was used in many other  
projects). Such an incident will reflect negatively on both this  
widely used library in particular and on OpenID in general. Diversity  
is definitely good.

If creating solid implementations is difficult then we should look at  
improving the spec and provide proper test suites.

My 2c.

Marius



>
> The result has been a pretty miserable experience for web designers
> and oftentimes worse for website end users with non-dominant browsers
> or user-agents.
>
> While I appreciate Walkah's point and think more implementations can
> lead to better specs, long term, if there aren't guidelines, shared
> priorities and measureable ways to gauge compliance (test suites) --
> brought about through strong leadership and a self-imposed mandate to
> clarify but ultimately implement to a uniform experience -- I think
> we'll end up with a fractured OpenID universe, susceptible to the
> typical criticisms of open source and distributed development.
>
> At the very least, we should respect each party to choose for her or
> himself, but we must also force this decision to be made plainly, with
> eyes wide open to the potential consequences of creating duplicitious
> and/or deviating work.
>
> Chris
>
>
> On 5/11/07, Christopher St John <ckstjohn at gmail.com> wrote:
>> On 5/11/07, Jonathan Daugherty <cygnus at janrain.com> wrote:
>>>
>>> # Generally, it will be completely obvious which implementation to
>>> # pick, since it will be at the top of any Google search,  
>>> followed by
>>> # things like my imaginary Haskell implementation.
>>>
>>> Sure, it will be pretty clear which one is more mature, etc.  That's
>>> *already* true.  And yet, it hasn't stopped broken implementations
>>> from being created or used.
>>>
>>
>> Well, rather than trying to stop people from implementing
>> the spec, it might be better to work on making the spec
>> easier to implement and verify. That involves clarifying
>> wording, adding  addenda, and lots of non-normative
>> text giving the experience of previous implementors. Plus
>> conformance tests. It's a lot of work, but, you know, it's kind of
>> traditional.
>>
>> What ended up happening for SOAP (an absolute interop
>> nightmare) was the implementors hosted latest-and-greatest
>> code on known endpoints.
>>
>> There was a more-or-less standard set of conformance
>> tests that exercised known tricky areas. The tests showed
>> the exact sequence of calls and content, so it was easy
>> to verify behavior. (That's trickier with nonces and such,
>> but there are ways around it) Tricky areas in this case
>> might be having a set of "should be rejected" tests with
>> bad hashes, for example.
>>
>> It was all very low-overhead but made it very obvious who
>> was with the program in terms of conformance (comparison
>> against the spec) and interop (comparison against other
>> implementations) Writing the conformance tests was a huge
>> help in clarifying the spec, since it forced people to confront
>> ambiguous areas and holes.
>>
>> There's no defense against people who refuse to RTFM,
>> but it is possible to make it easier for conscientious
>> implementors and developers.
>>
>> Just a thought.
>>
>> -cks
>>
>> --
>> Christopher St. John
>> http://artofsystems.blogspot.com
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
> -- 
> Chris Messina
> Citizen Provocateur &
>   Open Source Ambassador-at-Large
> Work: http://citizenagency.com
> Blog: http://factoryjoe.com/blog
> Cell: 412 225-1051
> Skype: factoryjoe
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>