[OpenID] card space and openid. Peter just doesn't get it, yet.

[Peter Williams]

________________________________


But, I still don't get cardspace + openid.
 
________________________________

 
So, since writing that,  Ive been through one semi-commercial experience, attempting to see the messages on the wire.
 
In one deployment, there are OpenID Provider and Consumer agents. The Provider of course redirects to a local user authentication page on that website - a matter that is defined in the OpenID spec as "local matter" not subject to normalization. At this point, all issues of OpenID protocol compliance end.
 
In that same deployment, the implementor of "the local matter" happens to exploit a cardspace-complying protocol entity to complete the local matter of : user authentication. At this point, all issues of ws-trust protocol compliance begin.
 
This means, that the IDP web application is a classical framework, with two co-resident agents that the webapp bridges at layer 7: OpenId provider, and ws-trust layer entity. The entity diagram has 2 or more STS, one OP discovery mechanism, one OP Provider, one OP Consumer, and a potential role for a an OP Reputation agent. That OP Reputation  agent could well be ws-trust enabled itself, and be supported by 2 or more STS that may or may not overlap with those used to which ws-trust interfaces the OP Provider.
 
This instance of the cardspace+OpenID architecture at the OP Provider is a simple, protocol mapping bridge. For years, folks at my university ran a bridge, before SMTP was made natively available. The so-called GreyBook mail standard was bridged into DARPA SMTP arcoss the NASA FatPipe, under the atlantic to Norway, just as it was bridged into X.400, as it was bridged into UUNET relaying. This is jus the classical layer7 gateway model, with inter-gateway layer7 routing to let layer7 addressing route the mail to a site with the right set of multi-protocol translation capabilities, e.g. find the longlost decmail-capable host. Each gateway always enforced its own federatio-style or bilateral-style trust model on its gatewaring function, where trust was expressed through the layer7 routing/addressing graph. between connected gateways.
 
Is there anything more to "cardspace + OpenID" than this example of a "simple gateway" architecture, where one sp-initiated WebSSO protocol (OpenID Auth) is mapped into another sp-initiated flow (using ws-trust)?
 
As the cardspace intitiative specifically sells itself, given ws-trust, as addressing (wsdl) metadata-spec'ed web methods (both SOAP and non-SOAP) and uses ws-policy to express attribute contracts... and ws-policyassertions to control inter-STS relaying...., I think I'm a little disappointed. The OpenID movement is not evidently focussing yet on WS-* hookups of any sort (despite some early-phase concept work that I did read up on, given someone's pointers). 
 
Given the mighty marketing buildup, I had been expected "Cardspace+openid" to be meaning that -- at an architectural level -- there was an explicit linkup in the OpenID architecture for ws-trust's model of using STS networks to fashion trust models, for applications.  The linkup seems to be, however, merely a "local matter".
 
Can anyone enlighten me with better news: truth, halftruth, rumor, idea?