Content Comparison

...

1. Not Browser based.
2. Flow originates at the client (no Authn Request from the SP).
   1.  Client contacts IdP over SOAP, requests Assertions for specific SP.
   2. Client authenticates to IdP with Cardspace? As defined by ECP ?
   3. Client POSTs the Assertions to the SP (this is the first interaction with the SP)
   4. SP Validates the Assertions (what does it check? holder-of-key ?)
   5. SP returns a cookie to the client.
3. NOTE -- this is NOT Web Services Security -- itis NOT using SOAP message security or the WS stack.
4. As described, this is not yet n-tier. However, with a bit of recursion, it could be:
   1. Extend the IdP with a new endpoint that could "update" the presented token (similar in concept to the idea in Scott's original Delegated Credentials Profile)
   2. Embed a client in the mid-tier; have it present the received Assertion to the IdP for "updating".
   3. Modify the SP implementaiton to recognize tht an Assertion contains a second Subject (meaning a delegated Assertion).
      How #How might this be combined with REST ?

...