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!

Information Cards: More Subtleties

Another post in my new series (1,2) of posts related to things you never wanted to know about Information Cards:

• Why does the infocard.xsd define PositiveUnsignedInt when there is a XML standard positiveInteger already defined? Maybe I am missing a suble difference?
• Did you notice that the length of a claim's value is restricted to be less or equal than 684 in length?
  
  <xs:complexType name="ClaimValueType">
    <xs:complexContent>
     <xs:extension base="tns:BaseClaimType">
      <xs:sequence>
      <xs:element name="Value" type="tns:StringMaxLength684"/>
     </xs:sequence>
    </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  I am very interested to here the story who came up with this number and why (My guess is that a Windows UI component restricts the length...). People who suggest to store whole customer profiles in claims should be aware of this restriction.
• Did you know that the username/password credential hint is limited to 64 characters in length?! This makes Pamela's invalid Information Card (I4-badidp1.crd) even more invalid.

Relyingparty Best Practices

Some days ago I went to a kiosk to buy some ice cream for me and my family. I ordered four cones with one scoop of chocolate ice cream each. When I received the first cone I found a huge pile of chocolate ice cream on the cone. I reminded the seller that I had ordered only one scoop and got the answer that this mountain of at least five scoops was _one_ scoop. Hm.

The relying party now has a problem. Its subsystems (kids) already saw the offered claims so there is now no way to plainly reject the token. On the other hand the RP knows that the subsystems (4 5/12 and 5 11/12 years old) can not handle this token without maintainance afterwards. The RP rejects the tokens and asks the issuer to resend them in another format (cup and spoon) without changing the claim's value.

I don't want to stretch this too much but I think that it is not easy to write a best practices paper that is valuable for all RPs. I would have rejected this token because no part of the RP wants to handle strawberry claims.

Can People Learn?

It appears that the official identity data of many Germans was online readable for over three month... including religion and sometimes a photo.
How did this happen? Well, a software company that had successfully sold its eGovernment software to many German communities published the username and password of a demo version of their software on the internet. BUT this username and password happened to be the preinstalled standard username and password of the real application too. Ouch!
You don't need much fantasy to guess what some of the administrators of the sold software had failed to do...
I don't blame the administrators alone. Sure they probably violated the security policy of their organization but the bad security design of the application takes at least a quarter of the blame. Wait, let's put some blame on the German electronic signature laws too. The system of electronic signatures is so secure and expensive that nobody is willing to pay the price in Euros for it; not even or especially not the community and the government that made the laws.

This would not have happened had they used Information Cards.
Well, on the other hand it is not so complicated to use Information Cards in a way that is really stupid e.g. let anybody access the sensible data who presents a security token with the claim emailaddress == geheim@city.bund.de.