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

[Peter Williams]

Ok. Im not on the same plane as all you guys who the write these
standards - or the libraries. But, as simple a buyer and operator of a
major US national-scale ID system, I've been trying real hard over the
last 12 months to understand and apply all the internet-era identity
technologies out there - mostly by practicing with tools, libraries, and
actual servers.

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

About 10+ years ago, I did a (trivial) research experiment: a CGI
process made a https request  to an IDP site, presenting a
VeriSign-issued SSL client cert. The "IDP" site  sent back a
site-REsigned, short-life cert in the 302 http response. In the URI
naming field for subjects, the re-signing site stuck a
http://home.netscape.com/~peter style id ( a Unixy URL id practice that
was common, at the time, pre-LDAP takeoff). The HTTP library I used (and
customized) in the CGI then followed the 302 response, making a new
https connection to an "SP" website identified in the location header
and presenting the _RE-signed_ cert in the SSL handshake this time. This
worked fine as a demo; "federation" consisted of the SP site importing
the IDP site's public key into its certificate trust list, an obviously
simplistic form of bilateral trust. Ok. It was an experiment, back in
the days of CGIs, CGI doing their own http client requests, and home
directory URI naming for pointing to one's "personal page".

A decade later, about 15 months ago, we got to play a inter-domain
cookie SSO system from RSA. We got a great feel for modern webSSO. The
cookie issued on an "IDP" site could be applied to a "SP" site, once it
went through some fancy (trusted) inter-domain cookie translation -
circumventing the browser sandbox - based on ISAPI/NSAPI filters
installed into the web server stack. Ok. It was very vendor specific. It
didn't play well with open systems,  at all. But, it nicely isolated all
the very fancy interactions a IDP-site needed to make with the user of
an RSA OTP user auth device at an IDP web site, insulating the SP sites
from such. 

Then, a year or so ago we used the Microsoft WSE3.0 library and some
MSFT sample code - which I read about in some MSFT magazine: we got SAML
signed-XML tokens stuffed into SOAP headers accompanying a SOAP-based
webmethod. We thereby got a good feel for WS-Trust - and the "active"
profile of Ws-Federation. It was easy to see the http flow, the ws-trust
flows between sites and IDP STSs vs SP STSs, the headers used, and the
form of the XML object  bearing some name/value pairs. Cookies added to
SOAP headers avoided one needing to do the SAML/STS Process, in each and
every webmethod call.

Then, we played with the open source sourceid.org implementation of some
.NET handlers accomplishing SAML1.1 for browser flows (rather than SOAP
webmethods). We thereby got a good feel for SAML webSSO for browsers,
and saw how straightforward it was (by reading someone's code!) to
implement SAML protocol using a stack of handlers in the http pipelines
of the IDP and SP websites. It was easy to see and trace the core,
base64-encoded SAML blob, present in a simple form post message being
communicated between IDP and SP sites - and al the redirecting that goes
on up and down the handler layers, in each end. The cute auto-submit a
form-post via javascript reminded me a little of the Verified-By-Visa
protocol design.

Last year and this, we spent time investing ongoings at the Shibboleth
camp - installing and learning how very university data center folk
manage a particular SAML1.1 profile, for webSSO between university
campuses. But, their rather complex code turned out to only
functionally-accomplish what the easy to understand .Net handlers from
sourceid.org similarly did. Being dumb, I had never understood what a
SAML artifact binding was (in the SAML2 spec)... until I saw the trace
of the Shibboleth http flow using SAML1.1-era webSSO message flows. So,
this was well worth the investment of time. The whole concept of WAYFs
and identity provider discovery became very clear.

Then, we spent the last month or so trying to get our heads around
OpenID1.1. The JanRain libraries/portal provided what we needed to
generate the http traces, that proved so useful to see what actually
gets put on the wire. We even played with smartcard user auth, rather
than uid/password. The YADIS concept of identity provider discovery
contrasted nicely with what we learned from Shibboleth about WAYFs, and
SAML's cookie server concept. It was fun to see OpenID use a URI as the
core user-centric identifier. This kinda vindicated why I held out so
long trying and eventually persuading the ISO standards crowd to add a
URI name-form to the X.509 cert! Here we are, OpenID is now exploiting
URI name forms properly (where signed openid assertions play the role I
had envisioned for dynamically-issued certs).


Then, there is cardspace + openid, again.


Ok. Cardspace can send "tokens" - to the requesting website. The token
data structure can be any syntax/format, including the syntax this
community uses in the signed blob that underlies OpenID's means of
communicating assertions.

Is that what folks mean, when they say cardspace + openid? - leverage
the syntax of the OpenID signed blob?

Or, is there a role for the OpenID Auth protocol - where perhaps the
cardspace active control and supporting cardspace libraries in a trusted
OS can ask (using OpenID Auth protocol) a web-based third party "managed
infocard provider" - implemented as an OP - to provide the (Signed)
OpenID assertion token, which the control then relays to the peer
cardspace handler in the http listener at the SP site? 

If you've followed through all this "voyage of discovery", you might
feel like I do that something critical is missing from the story, in the
area of cardspace. I'm worried I'm could be entirely wrong track, when
it comes to understanding the role of cardspace, in the open world. For
example, its possible that OpenID + cardspace is just an implementation
issue - leveraging the 'trusted desktop" that comes when one applies
CardSpace. That's entirely valuable, but not earth-shattering.



I think this memo was way too long! Well done, if you got here without
hitting delete!