[OpenID] stacking up Openid Innovation compared to Liberty

[Peter Williams]

On Tuesday last , I listened at DIDW to the folks who won the Liberty competition for noteworthy or innovative applications of Liberty-style WebSSO. 

The Liberty winners covered: 

(i) a merchant payment-services aggregator (rather old SET server-side merchant aggregator story, revisited). The winning feature seemed to be its application of an SP-centric federation to payment.

(ii) a govt inter-agency trust network (rather old NIST FPKI story, revisted). The winning feature seemed to be about the use of Attribute Authorities.

(iii)  an interesting dynamic-outreach methodology for building federations (SXIP related). The winning feature seemed to be about the onboarding properties of the pargticular trust model, and what seemed to be an application of SP affiliations.

(iv) a plugin for a phone handset/SIM, producing SAML responses (rather simplistic compared to Sonera's product-grade work on PKI-capable SIM applets that work properly with actual SIM provisioning, GSM interchanges and roaming/billing protocols that do the same thing (and did in in 2001-era WAP gateways)). The winning feature in this "innovation class" seemed to be about programming a handset applet producing a SAML assertion and having a WAP-like gateway act as a Liberty client relaying SAML flows and DoCoMo proprietary signaling.

-------

I tried to imagine how just some of the playful ideas with FOAF that we played with here would stack up. Im pretty convinced we would  simply outclass all of the above - doing nothing else than exploiting the web for what its good at.

It would be fun to find a competition that admitted OpenID in an open "all-comers" WebSSO initiative that doest restrict entrants to using Liberty-related messages and flows. 

One could imagine a submission that focussed on using the delegation model of OpenID, and addressed claim transforming via AX. 

The delegation OpenID can be an encoded SPARQL http request, that contains FROM references that are https, allowing the SPARQL resolver to handle CA trust-point whitelists and OP whitelisting (for walled gardening). Using a custom namespace in the ns extension mechanism in Auth 2.0, the RP can signal to an suitable OP that it wishes the OP to act as an SPARQL endpoint, and determine AX attributes using that SPARQL data source. The requested attributes on the Auth for that custom namespace would play the role of WS-SecurityPolicy, and thereby signal which "claims" the RP requires, using the namespace and attribute syntaxes it desires.

If one were to now show that such an innovation addresses the calim tranformers that seem to be at the heart of the Microsoft Identity Metasystem, I supposed we could easily leverage the SemWeb induction rulebases so that attribute values resolved by SPARQL endpoing associated with the OP in one vocab can be recast  as cliams in the claim language defined in the Auth extensions namespace. I see nothing in the notions os WS-Fed STS claim transformers that cannot be played out using AX,SPARQL, and OWSL-specified induction.

I think we could easily outclass the Liberty showcases of excellence , with just a little bit of intelligent collaboration between web technologies.