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. ##NOTE
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).
5. How might this be combined with REST ?

Use Cases

1. Browser user uses Shibboleth to authenticate to Confluence. User goes to Space Admin pages. User wants to give an additional ldap group access to the Space. User goes to the manage Permissions page, and clicks "browse groups". Confluence forwards the user's Kerberos ticket to the ldap server; the user only sees groups they are authorized to see.
2. Browser user uses Shibboleth to authenticate to web-based email interface. The web-based email application forwards the user's Kerberos ticket to the local IMAP server, to authenticate the user, and open their Inbox.
3. Browser user logs in to the Brown Faculty gateway. The gateway application connects to a backend application, authenticates the user by forwarding a Kerberos ticket, and asks the backend application for the list of courses and projects that this person teaches or participates in. 
4.