[OpenID] java libraries

[Peter Williams]

I too can see that, IF one reads the openid2 section as a continuation of the section on their Java SP, they could be talking about the insufficiency of their own java sp libraries.

This doesn't really account for (a) are the Java IDP libraries even up to it? (b) why not use the main c++ codebase in the SP case (other than the main developer probably thinks very little of the design of openid)?

Jack, consider moving over the openid specific code you partially wrote last year, as a shib plugin, on either IDP or SP side. Rather than abandon it, make your life easier by exploiting the excellent Shib platform. Its a wonderful piece of security engineering (probably based on certain US assurance doctinres about exploiting type theory to avoid the need for additional, after the fact, "descriptive" formal methods, when seeking high level evaluations of trusted subsystems).
________________________________________
From: Peter Williams
Sent: Tuesday, September 23, 2008 10:14 AM
To: Jack Cleaver; OpenID General
Subject: RE: [OpenID] java libraries

Obviously, the project's own java libraries are not un-usable for wsfed/saml1/saml2 (and soon infocard). But, under the working hypothesis that the reference is to their own code, they are uniquely unusable for openid!?!

So, I have not recently inspected the java libraries, which are on the IDP side. The SP side (which was written in C++) was very well structured as generics, and thus could and did adapt to particular protocols, profiles and standards easily by subclassing. It was producing sp-initiated websso for SAML2 and ws-fed fine (via the ws-fed plugin.) when I investigated the source code in detail, a few months ago. Its hard to believe it would fundamentally struggle (via the plugin architecture used to adapt to ws-fed equivalent to openid) to now be unable to produce the openid messages - mostly key-value pairs - or maintain the unique session state of openid auth.

At the same time, openid discovery (with XRI) by SP is quite different to the SAML2 model. This may be where the team is struggling.

But, one must respect them too.. This guys are export coders and are mostly focused on architecture. They understand websso backwards (pun).

If openid2 cannot fit into the shib technical framework, that is actually worth a pre-doc research-grade paper reporting analytically why not! Reading that would more be far more useful than reading a report stating the results of what happaned in a small pilot (show how openid does not fit culturally into any shib-cultured organization, say.)
________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Jack Cleaver [jack at jackpot.uk.net]
Sent: Tuesday, September 23, 2008 9:56 AM
To: OpenID General
Subject: Re: [OpenID] java libraries

Hans Granqvist wrote:
>> Some leading lights in the US academic community are essentially
>> claiming that certain Java OpenID2 libraries are essentially
>> unusable - to the point where they can only be entirely re-written.
>> Until they are rewritten (which will never happen), no Internet2
>> funds will be aimed at OpenID2.Its hard to know if the libraries
>> referred to are the XRI libraries or IDP or SP, or AX, or what?
>>
>
> I read it as the Shibboleth Java libraries are the ones that are
> unusable.

That's how I read it; but I suppose we're all guessing.

--
Jack.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general