[OpenID] ANN: OpenID Information Cards spec andworkingimplementation

[Peter Williams]

If the OpenID token changes this kind of behavior, this should be very 
clearly indicated to the user before he/she can use it.

--- This was why my first experiment simply made OpenID a protocol
converter in front of a SAML2 sp-initiated flow. That flow could then be
constrained to use the OASIS "transitive pseudonym" mode... to counter
IDP tracking.

-- but this doesn't get me the only bit I really want from cardspace -
the trusted path process, controlled by a trusted kernel, applying NT
Trusted Processes and signed drivers recognized by a HAL leveraging a
high-integrity motherboard (which means TPM). Sending SAML blobs to an
RP is trivial. Sending SAML blobs over https to the RP is trivial.
Standardizing 15 SAML claims is trivial.

-- its obviously easy to add the infocard selector process to a good old
SAML IDP local-login webpage. Yes, the cardspace process on the browser
host will (a) use trusted drivers in trusted path UI to access the
smartcard, say and (b) in due course will post back a SAML1.1 file to
the IDP host login page populated with values from the smartcard, over
https even! These "cardspace" claims then get mapped over into the SAML2
assertions, where NameID controls are added. The mapping can use the
identity schema for labeling attribute types and syntaxes.