Andy Harjanto's InfoCard WebLog

InfoCard and Browser Integration

2006-02-20T08:42:00Z

This is the information you've been waiting for! You've seen the InfoCard -IE 7 demo at RSA Conference last week. If you missed it, not too worry - plenty of articles you can read.

Many have asked me, how does it really work?

In a simplest scenario, a web site could simply add an HTML tag (either using OBJECT tag or XHTML tag) as part of <FORM> element. When IE 7.0 sees this, the InfoCard experience lights up.

Here is a simple example of OBJECT tag and XHTML insider FORM tag.

<FORM method="post"
        action="https://www.fabrikam.com/Main.aspx" >
        <input type="submit" name="InfoCardSignin" value="Log in"
         id="InfoCardSignin" />
        <OBJECT type="application/infocard" name="xmlToken">
          <PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
          <PARAM Name="issuer"
            Value="http://schemas.microsoft.com/.../issuer/self">
          <PARAM Name="requiredClaims"
           Value="http://schemas.microsoft.com/.../emailaddress"
        </OBJECT>
   </FORM>

OR --------

Notice that the InfoCard OBJECT or XHTML tag will be part of POST message, just like any other element inside the <FORM>.

Once the InfoCard UI shows up, user selects the card, and token is generated by the IP, the token will be posted as part of specified field ( in the example above, the field name is "xmlToken") to the targetUrl (in this example, https://www.fabrikam.com/Main.aspx).

The login page above requires SSL connection. InfoCard will use this certificate to (1) display the trust dialog for first time visit (2) encrrypt the token to the targetUrl. InfoCard also supports High Assurance certificate, just like IE7.0.

You also notice that inside the <OBJECT> tag or XHTML (implement as binary behavior), you could specify RP's policy such as issuer, token types, claim set (either optional or mandatory), etc.

The POST message will look like this:

POST /test/s/TokenPage.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 6478
Content-Type: application/x-www-form-urlencoded
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Host: www.fabrikam.com
Referer: https://www.fabrikam.com/login
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
UA-CPU: x86

InfoCardSignin=Log+in&xmlToken=%3Cenc%3AEncryptedData+Type%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23Element%22+xmlns%3Aenc%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23%22%3E%34WVfaItHJTYU%2BsxIR1T25fi9k%2FOc%2FMX7Q%2B6NSDs4nGqkn4rzqpez9BUWNZw7caVOrDeao
...
diZwfj0w06g199qlAqUMZEWxh0%3D%3C%2Fenc%3ACipherValue%3E%3C%2Fenc%3ACipherData%3E%3C%2Fenc%3AEncryptedData%3E

If you look at closely, the un-escaped version of the token is an XML fragment which includes information such as the encrypted token, the method of encryption, token signature etc.

Of course, this is only one scenario. Other scenarios could involve one or more STS (security token services) owned by RP. In this scenario, the target page will process the token, and it can make authentication and authorization decision, or it can also return another token (for example setting the cookie, if appropriate)

It's simple, isn't it? I think it's enough for one post to digest. Please send your comments, feedback.

New! InfoCard Guide and Technical Reference

2005-11-22T08:27:00Z

By now, you may already know that we have shipped WinFX November 2005 Community Technology Preview (which includes the latest InfoCard). Today, we just published InfoCard Guide to Integrating with InfoCard and Technical Reference for InfoCard v1.0. These documents explain how InfoCard uses WS-SecurityPolicy, WS-Trust, and WS-MetadataExchange in a great detail; they also explain the card schema and our implementation of STS that produces a self-issued card. If you have questions or feedback, please post your comments here.

Change a topic a little bit - OK, I can't top XBox360 launch, but what's new in WinFX November 2005 Community Technology Preview, specifically InfoCard?

Improved UI, you'll see better graphics, control pannel applets
Improve handling import and export .crd and .crds
Better, cleaner OM and App.Config.
Managed Card scenarios are enabled.
Tighter security model around the "Trust" dialog.

I would highly recommend you to try this (especially now that we also have ship VS.NET 2005).
Install the following order:

WinFX November 2005 Community Technology Preview -- (uninstall previous CTP bits, if any)
Install Visual Basic Express or Visual C# 2005 Express.

That's it! -- You're ready to go to do a real programming. To make sure InfoCard installed properly, please open your control pannel and click on "Digital Identities" -- do you see what I see?

More Materials on InfoCard

2005-09-22T08:20:00Z

For those of you who missed PDC, now you can download "InfoCard" PDC presentations from PDC ComNet. One presentation (Identity, Access, "InfoCard," and the Identity Metasystem) was given by our architect, JohnShew, and the other talk (Developing Federated Identity Applications Using "InfoCard" and the Windows Communications Foundation) was given by me.

On the side note, even if you’re not planning to install WinFX Runtime on your machine to try InfoCard, it is still useful to download the Sept 2005 CTP Resource Kit. In this resource kit, you will find “InfoCard” technology walkthrough; step by step instructions on how to build client and service which use InfoCard.

Announcing: Microsoft Federated Identity and Access Resource Kit for Sept 2005 CTP

2005-09-20T07:28:00Z

What a great week, last week! I met many of you at PDC, discussing InfoCard, Identity Metasystem. I learned plenty from you, understanding the scenarios, your customers' requirements, or discussing how other technologies could use "InfoCard". Thank you!

As I promised at the PDC, we'll make the resource kit available for public this week. This resource kits contains a document and samples, describing step-by-step instructions on how to build "Indigo" (WCF) applications/services that use "InfoCard". In addition, it also includes Security Token Services (STS) samples that you can customize. Now, you could build an end-to-end scenario, and play a role of Identity Provider, or Relying Party or both.

As the name indicates, this release only works with WinFX Sept 2005 CTP and VS 2005 Extensions for Sept 2005 CTP. Please install in the followin order:

If you'd like to use the STS samples, please install IIS prior to installing WinFX Sept 2005 CTP.
WinFX Sept 2005 CTP (http://www.microsoft.com/downloads/details.aspx?familyid=ffd636f0-86e9-41e8-9e1c-100a4cc4888f&displaylang=en )
Visual Studio Extensions for Sept 2005 CTP (http://www.microsoft.com/downloads/details.aspx?familyid=EDE1A645-2A53-42E1-8482-3BF1FADADE06&displaylang=en ).
WinFX and VS 2005 are installed, please download the resource kit here (http://www.microsoft.com/downloads/details.aspx?FamilyID=66734401-4988-4ded-9876-3dc10223052c&displaylang=en ).

Since you'll be using pre-release versions, I recommend using a test machine.

Enjoy, and I'm looking forward to hearing your feedback!

PDC 2005 is coming!

2005-09-07T08:05:00Z

I'm back! We're a week away from PDC. A few members in the InfoCard team (including me) will be there at the PDC. For those of you who will be at the conference, we're looking forward to meeting and hearing your feedback. I'll also present one technical session specifically on InfoCard.

There is so much stuff to cover. I promise I'll be posting more technical articles in this blog after PDC.

I'll see you in LA!

RP : "I would like a token to go, please!"

2005-07-07T09:25:00Z

Now, that you, as the user, let the RP in (please see my previous posting) based on RP’s certificate and logos, RP, in turns, could express its security token requirements to you before it grants you some access.

Consider the following xml fragments that RP could specify in its App.Config.

                <wst:TokenType>
                     urn:oasis:names:tc:SAML:1.0:assertion
                 </wst:TokenType>

</xmlElement>

<wst:Claims>

<wsid:Claim wsid:URI="http://.../identity#E-Mail-Address"/>

</wst:Claims>

</xmlElement>

                   <wst:Issuer>
                      http://schemas.xmlsoap.org/ws/2004/10/identity/issuer#Self
                   </wst:Issuer>

</xmlElement>

</tokenRequestParameters>

</federationParameters>

</security>

This App.Config will be translated automatically by Indigo runtime in the form of WS-SecurityPolicy. The client could retrieve this information using WS-MetadataExchange – more later.

Note: In subsequent beta release, it’s very likely that the format of this app.config will change.

As you seen above the xml fragment, the RP specifies:

1. The authentication mode to be “IssuedToken”. If the Indigo runtime on the client sees this, it will call InfoCard System.

2. Token Type is SAML:1.0. The interesting thing to note here is InfoCard could work with any type of token, as long as Identity Provider (IP) could satisfy the request. InfoCard is token agnostics. In the future, if a claim based token format is invented, InfoCard system could still work, provided that RP asks and consumes the token and IP produces the token. The role of InfoCard, as an Identity Selector is to be a match maker between RP and IP.

3. Claims requested by the RP. In this example it’s E-mail address. Note the claim is identified by the URI. Other company could in, theory, define Email Address with a different URI, for example http://schemas.fabrikam.com/2005/07/claims#E-Mail-Address.

4. Finally, the RP specifies the issuer of this token. In this example, RP would like a self-issued token. RP could also omit this, indicating any issuer is acceptable. Or RP could specify a specific issuer; for example,
http://services.contoso.com/products/sts

To retrieve this RP’s policy, the client could use svcutil.exe (for design time), or it could also use MetadataResolver (for runtime).

EndpointAddress mexAddress = new
EndpointAddress("http://.../mex");

MetadataResolver mexProxy = new MetadataResolver(mexAddress);

ServiceEndpointCollection endpoints = mexProxy.RetrieveEndpoints();

// for simplicity, brevity, assume only one serviceEndpoint
ServiceEndpoint ep = endpoints[0];

// Create a channel based on the the end point
ChannelFactory<IHello> cnFactory = new
ChannelFactory<IHello>(ep.Address, ep.Binding);

IHello chn = cnFactory.CreateChannel();

That’s it. The client points to RP’s MetadataExchange endpoint, and retrieves RP’s WSDL (including the security policy) to form a serviceEndPoint collection. Once the client finds the serviceEndPoint it wants, it calls Indigo to create the channel.

What happen under the hood (on the client side)?

1. Indigo calls InfoCard System, since RP asks for “IssuedToken”

2. Let’s assume user has a few cards issued by different companies, government, and self-issued. InfoCard System will match the RP requirements with the cards that are capable of satisfying the RP’s requests (please see point 1-4 above)

3. User is presented with the qualified cards. User selects a card.

4. InfoCard System will read the card (remember it only contains a metadata about how to get the token), and contact IP.

5. InfoCard uses WS-Trust to get the token from IP, passes the RP’s security policy along with it.

6. InfoCard gets the token from IP, asks the user for her approval prior to submitting the token to RP.

7. Token is sent to RP, encrypted with RP’s public key.

We’ll examine InfoCard and IP interaction in later postings.

Oh…, one more thing – I’ll be taking three week vacation starting in a few hours…J; it could be challenging to get Internet connection in some remote areas – so I won’t be updating this blog for a while. I plan to capture some of interesting, real-life IP – Client – RP and STS scenarios, in the form of ---what else - pictures. I just picked a new hobby of digital photography; it’s great to learn the “language of photography” like metering, white balance, parameters, af-points, shutter, aperture, depth-of-field, etc; I could always use some advice.

See you in a bit ...

Knock, knock…, who’s there?

2005-06-30T09:04:00Z

RP? …. RP Who? …. RP, the good guy, really!

Would you open the door to a stranger? Probably. Would you give up some valuable information to him? Probably not without checking his identity; and of course you won’t take any of his identity, like his business card; you would only honor IDs that were issued by authorities that you trust.

A similar problem exists in Identity Metasystem. The user MUST be in a full control over what data, for what purpose, to whom s/he discloses the identity information (Law #1).

When a user visits a RP’s web service, InfoCard System requires the RP to supply its identity in the form of X509Certificate which is part of Endpoint Reference (EPR)- (for more information about EPR, please see WS-Addressing). Of course, the RP must also prove that it has the possession of the corresponding private key (for example, via signature). The security token submitted to this RP is encrypted using the public key of the certificate. The virus could not just obtain the token, and decrypt the token, since it does not have the RP’s private key.

How does this translate to code/configuration? If you go back to my previous posting, the RP would add the following xml segment in its app.config (system.serviceModel/services/service/endpoint)

<endpoint ...>
<addressProperties identityType="Dns" identityData="Fabrikam">
    <endpointHeaders>
       <dsig:X509Certificate xmlns:dsig="http://…/xmldsig#">
              MIIDwzCCAqugAwIBAg ...
              ... 4-5 line of base 64 encoding string …
              ...93rQOBW/BjHqg==</dsig:X509Certificate>
   </endpointHeaders>
</addressProperties>
</endpoint>

The X509Certificate specifies in the service’s endpoint SHOULD contain URL links to the subject and issuer logos. The identity selector (i.e InfoCard) displays these logos prominently when the user must make a trust decision whether to trust the RP and continue the conversation. The logos and the hash of the images are specified in 1.3.6.1.5.5.7.1.12 field in the certificate. The trust decision is recorded in the InfoCard system, so the next time s/he does not have to make the same trust decision again (of course she could revoke her trust to a specific RP).

Of course, the RP identification problem has been solved before with varying degree of success. If users visit to a secured site, they have been educated to look at the locked icon in IE. In InfoCard experience, during the first time visit to RP, the user MUST decide to trust (or not trust) the RP before it can continue the conversation with RP.

Next posting, – let’s look at how we could secure the conversation between RP and User.

Building InfoCard App, Part 1

2005-06-25T16:24:00Z

…Now the fun begins…, let’s code and we’ll get back to a few InfoCard concepts later…

Follow the following instructions:

1. Create a New Project. Choose the project type, for our walkthrough, let’s just pick a Console Application, and name your project "MyFirstHelloApp".

2. Add the references using Project | Add Reference…

3. Choose System.ServiceModel and Microsoft.InfoCards. Indigo and InfoCard applications primarily use System.ServiceModel, while Microsoft.InfoCard is normally used to catch a few exceptions thrown by InfoCard System.

4. Add the following "using" for C#:

using System.ServiceModel;
using Microsoft.InfoCards;

Now, you are ready to write your first hello world application. First, we’ll create the simplest HelloWorld Indigo client-service app; we’ll then add InfoCard binding that triggers the InfoCard UI on the client. To make it even simpler (for debugging purposes) we’ll even combine client and service code in one *.cs file. In normal cases, the service will be hosted by IIS.

For brevity, we will also omit catching exceptions. Note: There are many good Indigo samples in the WinFX SDK and other blogs; this exercise is just a stepping block to get into InfoCard.

What we’re building. We’ll be building a simple client and service app. Service will implement a contract in an interface called IHello. The client will call this interface. In the next posting, we’ll modify the app.config to trigger the InfoCard UX on the client.

Add the following code:

namespace MyFirstHelloApp
{

[ServiceContract]
interface IHello
{
[OperationContract]
string Say();
}

class Hello : IHello
{
public string Say()
{
return "Hello World";
}
}

class Program
{
static void Main(string[] args)
{

   /////////////////////////////////////////////////
   // Service Code
   /////////////////////////////////////////////////
   ServiceHost<Hello> sh = new ServiceHost<Hello>( new Uri("http://localhost:4123/myService"));
   sh.Open();
   Console.WriteLine("Listening....");

/////////////////////////////////////////////////
// Client code
/////////////////////////////////////////////////
ChannelFactory<IHello> cnFactory = new
ChannelFactory<IHello>("myClient");
IHello chn = cnFactory.CreateChannel();

Console.WriteLine(chn.Say());

// Clean up
cnFactory.Close();
sh.Close();

}

That’s it! for both the client and service. The service which implement IHello is listening at http://localhost:4123/myService (I just picked an arbitary port); The service implement IHello:Say(), which nothing more than returning "Hello World" string. The client’s channel information will be read from "myClient" configuration in the app.config.

Next step, add App.Config to configure the binding, address, and contract (since we combine the service and the client, this app.config is for both the service and the client)

To create App.Config:
1. From Project, select Add New Item…
2. Select "Application Configuration File", and click Add.

Add the following XML segments:

<configuration>
<system.serviceModel>
<bindings>
   <customBinding>
       <binding configurationName="myBinding">
       <httpTransport/>
</binding>
</customBinding>
</bindings>

Build and set break points, and debug…., you should see the following outputs:
Listening....
Hello World

You may want to set one break point on IHello:Say implementation, so you’ll see when the code transition from client to service (and vice versa).

As seen in the app.config, we’re using http as the transport binding, both the client and the service point to the binding. Since the address, binding and contract are the same, the client and the service will be able to communicate. One thing that I really like about this model is to separate code implementation from the infrastructure. Later, if I would like to change my transport ( for example, namepipe or tcp-ip), I do not have to change the code (in few cases, only minimal code modifications) – I just need to modify my App.Config.

It’s not too bad, is it?

Wanted: InfoCard OM

2005-06-23T01:57:00Z

Have you created your first self-issued card yet? Please see my first posting for instruction. Would you like to create, delete a bunch of cards programmatically? I have a good news and/or a bad news. The bad (or good) news is – you can’t. There is no programmatic access to InfoCard store, period. The cards that represent your digital identities are very closely guarded; a virus running in a user context won’t be able to enumerate cards, delete cards, or creating cards. User MUST be in control on card lifecycle management (create/delete/update,etc), as well as the release of token to the RP. User is an integral part of Identity metasystem. InfoCard as an Identity Selector interacts with the user closely. For those of you who are looking for InfoCard OM, well sorry, it is virtually non-existence.

So, how do you trigger InfoCard UX on the client to appear? It starts from a Relying Party. As an RP (and also an IP), you’ll get to choose what authentication mechanism you would like to use to grant access to your resource(s). For example, one could use UserNamePassword over SSL, or Kerberos, or X509Certificate, or others. The authentication mechanism that will trigger InfoCard experience on the client is called “IssuedToken”. All of these requirements are expressed in WS-SecurityPolicy.

So, here is the flow:

1. The client application gets a RP’s policy (which includes authentication mechanism). This can be done during design time or runtime. The protocol used is WS-MetadataExchange.

2. Based on this policy (to be accurate, policy is included in WSDL), the client has enough information on how to communicate to the web service (which, in this case, is RP’s). At this point, no connection has been established yet.

3. The client library parses the security policy requirements (along with other binding requirements). It learns that it requires “IssuedToken”; the library, then, will call InfoCard System to satisfy the token request, passes along the RP’s security policy requirement (such as issuer, tokenType, claim set, etc)

4. InfoCard System returns the token to the client library (after getting the requested token from IP using WS-Trust protocol)

5. The client library now is ready to communicate to the RP’s service. The issued token will be included as part of WS-Security in the initial communication.

Hmm… that sounds complicated, …. too many protocols to learn… ? Not really, with Indigo – you’ll see that this amounts to only a few lines of code. In fact, a client app that normally uses UserName/Password, or Kerberos, could suddenly support InfoCard without (or little) code modification.

In the next posting, let’s create (1) a client application and (2) RP’s service. The Identity Provider role will be played by InfoCard Local IP/STS. First, we’ll build a simplest Indigo hello world, and then we’ll enhance it with InfoCard. We’ll also introduce a few InfoCard concepts along the way. Sound good? Please stay tuned..

InfoCard - An End to End Scenario

2005-06-21T01:52:00Z

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:

Issuer: Government (it actually defines as URIs)
TokenType: SAML (or any other token type that IP could generate and RP to consume)
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).
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 (3^rd 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.

InfoCard, a Sneak-Peak

2005-06-17T17:48:00Z

A few articles have written about InfoCard in the past few months; now it's your chance to get a sneak peak of InfoCard.

First, I recommend reading these two articles: Microsoft Vision of Identity System and The Laws of Identity. I also enjoy reading Kim Cameron’s Identity Blog. Second, download Microsoft® Pre-Release Software Code Named “Avalon” and “Indigo”; it’s currently in RC Beta 1.
If you’d like to do some programming with InfoCard (I promise to show you how, in subsequent postings), you may want to install either Beta2 release of Visual Studio 2005 or Beta2 release of Visual Studio Express. Optionally, we could also download WinFX RC Beta 1 SDK documentation and samples here; I warn you the SDK download is huge (351MB), and for InfoCard walkthroughs, this is not required.

Ready, set, go…

Once you complete the WinFX Runtime installation, you’re ready…

1. First, you must start “InfoCard Service” manually; you could use the command prompt: net start “InfoCard Service”.
Note: this is Beta 1 behavior. In a subsequent beta release, it’s very likely that you don’t have worry about starting the InfoCard Service anymore.

2. Go to control panel, you will see a new control applet, call “Digital Identities” - double click it.

3. You will see the InfoCard Management UI. I’m going to warn you that this is a ‘wire frame’ UI, it is enough get basic ideas across, but it is no where close to the final UI, and it will be radically different in a subsequent beta release, so please don’t read too much into this.

What you see?

1. You see a separate, secured desktop was created.

2. UI that allows you to manage your digital identities. Note please do not confuse contact list/address book. Your digital identities are similar to what you have in your wallet (driver license, creditcards, membership club, frequent flier mile cards, student card, employee card, etc). You could also issue your own card, such as your own business card. Card issued by you is what we call self-issued card. In beta 1, we only support self issued card. In next beta release, we’ll include support for 3^rd party issuers.

3. Each user profile has its own collection of cards. Let’s say you share your computer with your daughter; and you create two user accounts (one for you, one for her); her digital identity collection will be separate from yours.

4. You could use this UI to create, delete, edit your self-issued cards. A limitation in Beta 1 is you have to fill in all the fields, before a self-issued card can be created.

As described in the Identity Metasystem article, InfoCard plays a role as an Identity Selector in the identity metasystem universe. In addition to this, InfoCard, in Beta 1, also ships with a local security token service (more later…), which plays role as an identity provider. Others could easily build an Identity Provider that will interopt with InfoCard. Others could also play role as Relying Party (consuming the token); and others could play multiple roles.

What’s in the Card?

The card (regardless of self-issued or issued by third party) contains only metadata information – the cards do not hold claim values (i.e your name, address, zip code, birthday). The metadata information has enough information for InfoCard System to communicate the Identity Provider to get the security token. So, who owns the data? Identity Provider; who consumes the data? Relying Party; and User, as the crucial player in the Identity Metasystem MUST approve the release of the data; and InfoCard’s role as the Identity Selector is to help the user communicating to Relying Party (RP) and Identity Provider(IP), as well as identity pickers for the user.

An Identity Provider hosts a security token service (STS); the primary function of this service is to exchange a token for another token. Applies this to our model, InfoCard System will authenticate to IP; the IP who owns the data will construct a new security token to you that you can present to RP. As said previously, InfoCard also ships with a local STS, which is capable of producing self-issued tokens.

Well, it’s enough concepts for now; let’s explore the fun stuff (aka programming) later…