OpenID over WS-Trust?

In an interesting example of how the different identity systems around play together (or not), SXIP has proposed an “OpenID infocards” spec. Allegedly, there is a working implementation around; I haven’t tried it, though. OpenID Information Cards …

In an interesting example of how the different identity systems around play together (or not), SXIP has proposed an “OpenID infocards” spec. Allegedly, there is a working implementation around; I haven’t tried it, though.

OpenID Information Cards 1.0 – Draft 01
D. Hardt, J. Bufu
Sxip Identity
August 10, 2007

“Infocards” in this context effectively means “OpenID over WS-Trust.” Painting with a broad brush, this specification essentially takes OpenID’s colon-separated-tag-value assertion format and embeds it with WS-Trust.Signalling that a relying party supports this protocol variant is not interoperable with the signalling used traditionally in OpenID.An OpenId infocards relying party needs to understand an additional — though quite lightweight — protocol exchange which wraps the OpenId token into token XML pointy brackets, to Paul Madsen’s immense delight.An OpenId infocards provider needs to implement a WS-Trust Security Token Service.The protocol interchanges are not interoperable with the ones traditionally used in OpenID: Steps 1-6 of the OpenID protocol are replaced with WS-Trust based interactions. Step 7, in its “direct verification” variant, remains in place, and ensures that the identity (still a URI) remains bound to the overall transaction.Conversely, there are similar implications for Infocard enabled services that would want to support this scheme; for them, the OpenID infocards spec effectively introduces yet another token format. See Eric Norman’s blog.On its face, this proposal suggests splitting the OpenID protocol into two not mutually interoperable variants, one fitting into Microsoft’s cardspace framework, and one having all the lightweight RESTful karma that makes OpenID interesting to the parts of the Web community that are less than fond of WS-*. The URL as an identity paradigm is much less central to this variant of OpenID than to the classical one: For much of the protocol exchange, what matters is the endpoint that serves as the Security Token Service. The “identity” URL itself only ever plays a role in the final verification step.All this points to interesting times ahead, as the various camps in identity space will continue to perform tangled dances.