Information Cards, WS-Trust and SAML and OAuth, oh my!

While reading Pat Patterson's blog post "WS-Trust and SAML and OAuth, oh my!" I noticed that this fits into the Information Card flow.

Pat describes Ping's Salesforce mobile flow:

1. Mobile app accepts the username and password, and submits them to PingFederate in a WS-Trust request.
2. PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
3. Salesforce.com validates the SAML assertion and responds to PingFederate with an OAuth access token.
4. PingFederate in turn replies to the Android app with a WS-Trust response containing the access token.
5. The Android app uses the access token to invoke the Salesforce.com REST API.

Now let's Information-Card-ify this:

1. The user visits the mobile version of his company's application page at Salesforce. (No extra App just HTML5 and CSS3. Which is probably easier to implement than an App for Android and Blackberry and iPhone! The web app is available anyway.)
2. The site offers to use Information Cards to authenticate and the user clicks the purple-i icon to do so.
   This click requests the browser to follow a link with an icard-https scheme.
   The browser/OS notices that this scheme is handled by Azigo's card selector for the iPhone. We, Deutsche Telekom Laboratories, have prototype selectors for iPhone and Android too.
   As it happens the card store contains an Information Card issued by the company and this card is the default card for this site. The selector contacts the card issuer (PingFederate) like in the other flow using WS-Trust.
3. PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
4. Salesforce.com validates the SAML assertion and responds to PingFederate with a session token.
5. PingFederate in turn replies to Azigo's selector with a WS-Trust response containing the session token.
6. The selector tells the browser to post the session token the Salesforce application and the user is "in session".

So, what is different for the user and his company:

• No App for each mobile platform!
• The user's credentials are entered at the company site (implemented by PingFederate)!
• If the card were backed by a self-issued card or by a certificate then we even get rid of username/password!

Using oauth to obtain a session token may sound unusual but then oauth is token agnostic... Or Salesforce would provide the oauth token and that would then be used by the webapp to authenticate it's calls to Salesforce's REST API... Life's good.

Thoughts?

Learn more about Information Cards at the Information Card Foundation!