Logging into a Website
When signing into a website using CardSpace, the website has the choice of accepting two card types, Personal Cards or Managed Cards.
Personal Cards are ones that you create the claim values yourself, support only a fixed set of claims, and have the cryptographic keys and PPID generated for you.
Managed Cards are cards that are issued to you from an Identity Provider, they decide the claims, and they provide the Security Token Server that issues the token to the webiste. We'll cover this one in Part Two.
Personal Cards and the Protocols
When a website requests a personal card, it does so by putting an object element into the HTML of the page, and engaging the CardSpace Identity Selector:
<html xmlns="http://www.w3.org/1999/xhtml" >
<object type="application/x-informationcard" name="_xmlToken">
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" />
var thetextarea = document.getElementById("xmltoken");
thetextarea.value = xmltkn.value ;
<form id="form1" method="post" action="login4.aspx">
Click here to get the token.
Click here to send the card to the server
<textarea cols=100 rows=20 id="xmltoken" name="xmlToken" ></textarea>
This obviously does not use any WS-* protocols, it's just simply asking the browser to supply the token requested to the website. And, with no STS in the puzzle, where's the WS-*?
Well, there is an STS. It's built into the CardSpace Identity Selector. It's there to provide the Personal card to the Relying Party (the website). The communication between the Identity Selector and the STS should be WS-* right? Well, since they are tightly coupled in this case, the STS in CardSpace short-circuits some of that and delivers the token to the browser just using inter-process communication. But the STS is built as if it was going to go over a wire, just optimized for local use.
So, there really isn't WS-* involved here. Until CardSpace supports a Portable STS, which then would seperate the Idenity store from the Idenity Selector, thus requiring WS-*.