I received plenty of feedback and emails on my first posting; thank you – keep in coming!  Also, thanks to Kim who mentioned my blog on his and for his kind words. It is really an honor and pleasure working with him. Let me tell you that all design meetings that I have been with him were always filled with laughter, energy and very productive. If you have a chance to meet him in person (he normally goes to plenty of conferences), you should, I guarantee you that you’ll have plenty of fun talking to him.

 

Back to InfoCard,  before I jump into coding, it is important to understand end-to-end scenarios, not at 5000 ft, but say at 500 ft – before we descend to 50ft level (for fun, easy programming).

Let’s take a simple scenario:

 

Fabrikam Corp sells fine wines on the Internet; to purchase wines you’re required to present a proof that you’re over 21. An ID issued by government is sufficient as a proof.   Take a scenario where Bob visits fabrikam.com to purchase a wine.

Before going into the data flow, let’s identify the roles:

·         Fabrikam as a Relying Party(RP), 

·         Government as an Identity Provider (IP),

·         Bob as a Subject,

·         And InfoCard takes a role is an Identity Selector.

Relying Party:  my requirements are…

Fabrikam defines its security policy requirements (using WS-SecurityPolicy). Its policy would be something like this:

    1. Issuer:  Government (it actually defines as URIs)
    2. TokenType: SAML (or any other token type that IP could generate and RP to consume)
    3. Required Claims:  Age.   Notice here that Fabrikam.com does need to know about other personal data; it only needs to know Subject’s age that will be asserted by issuer (in this example, government).  This is inline with Law of Identity #2 (Minimal Disclosure for a Constrained Use).
    4. Other requirements such as proof key type (symmetric, asymmetric), key size, which part of messages need to be signed, etc could also be specified.

 

Identity Selector, the match maker…

The policy requirements are read by the Identity Selector (InfoCard).  InfoCard will match the policy requirements (issuer, tokenType, claims, etc) with cards that Bob currently has.  Let’s say Bob has 5 cards; two are self-issued cards, one is a book club membership, one is credit card, the last one is his driver license.  Based on this, let’s say only his driver license matches with all RP’s requirements. This card will be presented by the InfoCard System to the user (Bob) as a card that can be used to satisfy RP. 

How this card (3rd party card, in general) is provisioned is a separate discussion that we could explore later.  But, in the case of a self-issued card, Bob could create using “Digital Identity” control panel applet.   

Now, Bob selects this card…

  

Identity Provider, create the token for me, please.

As mentioned in my previous posting, that card does not hold claim values. IP owns the data, not the Identity Selector. The card contains only metadata enough to communicate to IP for acquiring the token.  Identity Selector will contact IP (the IP’s end-point-address is specified in the card that Bob selects). Bob will authenticate to the IP, passes along the RP’s security policy requirements (tokenType, issuer, claim set, etc).  The protocol used in this exchange is WS-Trust.  The request message for a token is called RST (Request for Security Token), while the IP’s response to this message is called RSTR (Request for Security Token Response). 

If everything goes well, Bob will receive the token signed by the issuer (in this example, government), which contains only one claim (e.g age=32).  

Please note, RP’s identity may or may not be sent to IP, depending on policy and user’s willingness to disclose RP to IP.

 

Decision time for Bob

Identity Selector displays the information (e.g his Age) that Bob is about to be released to the RP.  It’s, now, up to Bob to approve it.  This is inline with Laws of Identity #1 (User Control and Consent). 

Bob approves the release of the token to IP….


(…token submitted will be encrypted to the RP)

 

Relying Party consuming the token

Once it was approved, the token is submitted to the relying party.  The relying party decrypts, and checks the signatures, token validations, etc.  RP will examine the claim (age), and make a determination that the sender (at least 21 years old), could purchase wines.

  

This is just one of many, many different scenarios; but roughly, this flow is still pretty much applicable.