Including the whole spectrum of use cases

Mathew Martin, who writes Mostly Mr. SQL, clearly detests PKI certificates more than almost any living person.  He finds CardSpace guilty by association in a piece called GRRRR!  CardSpace.  What a useless steeming pile…

Ok. Cardspace/Infocard is like OpenId.  Password-less access to websites (or password-fewer access).

BUT

1. You must use SSL.  Even if you just want to secure your application against your clueless neighbor.  That is a minimum of $40.

2. You must decrypt the response on an account with NTFS access to the private key.  The NT Network Service account is not likely to have read access to the private key on a hosted account.  Good luck explain how and getting co-operation from your hosting provider.

3. Decryption must be done under FULL TRUST.  Many hosted accounts only let you run in medium trust and don’t let you create COM+ dlls, put stuff in the GAC, etc.

[Items 2 and 3 might not even be a good idea.  If the world at large manages to use your web application to maliciously download your SSL cert, I suppose they could do something evil, like pretend they are you]

4. To get rid of the “the website isn’t secure for banking or ecommerce” you have to spend $1000 on an EV SLL cert.  Oh, sure, pocket change.

5. And who is issuing managed cards? I can get an SSL based cert from Thawte that says I am the person that controls my email account, but I can’t find anyone who issues managed infocards anywhere.

I’ve about realize that I–a computer profession and programmer, will not be able to implement InfoCard/Cardspace in any form, not for my blog, not for my hobby website, nothing.  Either one has $1040 and ones own entire server or nothing.

If only the top 10 biggest websites can overcome the hurdles posed by infocard, what we are going to see is 5 websites accept infocard and everyone else (mom & pop websites) continue to use passwords and user ID’s. InfoCard will have a minimal impact on how authentication is done.

This is going to drive small websites into using OpenId.  Consumer will rapidly gain a few dozen OpenId cards.  The rising ubiquity of OpenId–which doesn’t try to be a waterproof authentication method–will take over the world, relegating InfoCard to “that way you logon to Live.com services”.

Come on Microsoft, when are we going to be able to run CardSpace/Info card in “real world” mode?

[Thanks to Self-issued.info for the logo]  [Actually, I take that back, it is a Microsoft trademark. The purple box is has a substantial amount of IP self legislation that goes with it.  According to MS’s lawyers, I am currently in violation of usage guide lines for the icon.  Let’s see how Microsoft silences critics of InfoCard.]

Let's start with the CardSpace requirement that a relying party support SSL.  I agree with Mathew that requiring use of SSL and PKI is overkill for the type of blogging and hobbyist use cases he describes.  While my identityblog certificate is fairly inexpensive (thanks to godaddy.com), the extra cost associated with it at textdrive (which hosts my system) is around $100.00 per year because of the need to have a dedicated outward facing IP address.  I don't mind the cost too much, since I know there are people who will hit on my site and I like the extra protection.  But this really isn't appropriate for everyone. 

This underlines the fact that identity and the identity metasystem involve a continuum of use cases and technologies – and we have to embrace the whole continuum.  By making certificates mandatory, we cut the continuum in half.  Luckily, we can fix that before we get into the wide deployment phase.

My conclusion is that rather than hard-wiring the requirements for identification of a relying party into the identity selector, we should have allowed each identity provider to decide what minimal requirements were appropriate. 

This ends up having advantages both at the low value and high value ends of the spectrum. 

For example, a bank's IP might decide to only release information to a relying party with an Extended Validation (EV) certificate.  If so, CardSpace would not illuminate the associated information card if an EV certificate were not in use at the relying party site.   [EV certificates are only granted to companies or other organizations after they follow an extensive procedure for proving their legitimacy.]

Meanwhile, a blogging reputation identity provider might be happy to release reputation to any site the user proposes, certificate or no certificate.

Of course, the relying party is always free to use a certificate and gain the extra protection that provides.

This change is actually part of CardSpace 1.1 – which people should be able to start experimenting with very soon now.  When combined with the release of great toolkits for all the important languages, I think this will bring quite a bit of lift-off.

As for point 4), let's look at what the CardSpace advisory actually says:

I think there's a big difference between “a major internet business” and a site doing “ecommerce”.  When I buy a tee-shirt from Mathew I don't expect him to be EV.  If he were trying to sell thousand dollar cameras, I would feel differently.  I'd want him to either be well identified, or to work through a site like eBay that would provide another way of establishing his reputation.  And in this case, I want to make sure I'm really talking to eBay, so once again would like to see an EV cert.

I don't think any “major internet business” or bank will have any difficulty whatsoever covering the cost of an EV cert.  The idea of using the superior certs came directly from them, since they're the ones whose users get phished.  I don't understand why, given his earlier rant against the poor validation proceedures in conventional certificates, Mathew rails against our support for EV.  Part of his earlier criticism of EV certs is that the browser doesn't show the meaning of the cert properly, a problem CardSpace has solved. Consider this recent Anti-Phishing Working Group report:

As for who is issuing managed cards, you'll be seeing many outfits doing it as we move toward the InfoCard tipping point.  We're in the sockets and ecosystem phase of Information Cards, but I can tell you many players get the potential of the technology and are integrating it into product.

As for OpenID versus Information Cards, I don't see them as opposites.  Go to signon.com today and you'll see it supports use of Information Cards for OpenID authentication.   This is nice because it gets you InfoCard safety along with OpenID long-tail support. Going forward, I think you'll see most OpenID vendors supporting OpenID managed cards that work with OpenID sites.

As for the Information Card Icon, our intention is that it be available to everyone who supports the technology.  There has been pushback on the language around the icon, and we'll be figuring out how we can get this thing right.  In the meantime, I wouldn't be worried about using it on a teeshirt or to criticise us – but I would be worried about using it at a phishing site. 

Charles Fitzgerald doing “platformonics”

I just discovered that Charles Fitzgerald, General Manager of Platform Strategy at MS, has started a blog called Platformonics.  I know a lot of industry people will be interested – Charles has really been around the block at the highest level.  I think he learned more from “Hailstorm” than anyone else who I've spoken to.  Beyond that, he's a great business person, well-read and beautifully wry.  Here's a piece full of implications called There is no free lunch (especially in France):

The BBC reports the French security service has told French government officials not to use Blackberries because their data is stored in foreign countries and could be susceptible to prying eyes. Expect many more such awakenings going forward to the tradeoffs to putting data in the cloud.  Not just national security concerns, but trade secrets, privacy and compliance requirements will all require people to think more explicitly about the risks and tradeoffs of where you put your data and what can happen to it.  Today's all or nothing approach is a crummy way to do it. Three contenders for the most amazing part of this story:

  1. They're just realizing this now?  Did they just figure it out or did some incident precipitate this decision?  There is probably a pretty good spy novel in if you combine this with almost any headlines from France in recent years.
  2. French officials are “flouting the ban”.  I predict the upcoming ban on smoking in public places in France takes “flouting” to a whole new level.
  3. RIM insists the US National Security Agency can't read content on their service.  Disciples of Taleb might call that epistemological arrogance.

Oh yeah, I almost forgot.  Charles has been a great supporter of the Laws of Identity – ribbing me by somehow learning to recite the title with reverb.  He was also one of the first to see the potential of Information Cards.

Catalyst Interopathon reveals sea change

Here are the logos of the projects participating in the Information Card Interopathon at the Burton Group's Catalyst Conference. Beyond that, people told me about at least half a dozen new open source projects (each with a unique mission) that are sitting in the wings getting ready to go public.  I'll try to keep you posted on these. 

We had a rehearsal for this a couple of months ago at Internet Identity Workshop, but something has changed since then:  many of the players seem to have made strides in getting concrete about how the technology would be used in their products.  That's the key.

According to the press release:

Participants include projects groups Eclipse Higgins Project, Internet2 Shibboleth Project, The Pamela Project, Ian Brown (OpenInfoCard), XMLDAP, and SocialPhysics and vendors BMC Software, CA, FuGen Solutions, IBM, Microsoft, NetMesh, Novell, Nulli Secundus, Oracle, Ping Identity, Sxip Identity, VeriSign, and WSO2.

The demonstration will be centered on a photo sharing application and will show the breadth and maturity of user-centric technologies by executing a variety of information card-based component capabilities including:

  • Protocol and wire format interoperability
  • Card format interoperability
  • Policy interoperability
  • Platform interoperability 

The interop event was organized by OSIS and identity commons and hosted by The Burton Group.  Thanks to all involved.

Dave's mother

During one of the hospitality parties at the Burton Group's Catalyst conference I came across the SXIP folks showing their cool new application service “outsourcing appliance” that lets enterprises outsource HR or mail and calendar to companies like Salesforce.com and Google.  When employees are inside the firewall, they can just leverage Active Directory or some other LDAP server or authentication system to automatically create a SAML token that will log them into the service.

One of the requirements SXIP has encountered is for employees to be able to securely access these resources from their homes and hotel rooms without introducing the risk of password leaking. 

After all, most companies don't want employees revealing their enterprise username and password to service suppliers – but also don't want to support a separate username/password outside the firewall…  SXIP's solution:  use Information Cards.  It's a very simple and nice solution.

While looking at what they've done, I met David Huska, the incredibly fast and energetic engineering guy behind the project.  He started telling me about CardSpace and his mother, and I could see he had a great potential CardSpace “elevator pitch” – meaning a way to explain a technology while riding an elevator up a few stories.  So I cut him off, pulled out my phone, and asked him to start again.  Here's what he said:   

Kim:  So you were talking about your mother…

Dave:  What were you saying about my mother, Kim?  Were you talking about my mother?

Kim:  I love your mother.

Dave: Alright.  CardSpace is an analogy my mother gets.  She doesn't understand what I do in a million years, but CardSpace she gets.  She sees the cards.  Everything else stops.  Everything goes away.    She can't do anything else until she chooses a card. 

When she pulls our her purse, she sees her cards.  And with CardSpace, she sees her cards.  She can see what card they want from her.  She can see the information they're looking for from her.  She can decide what she wants to use, or not – what she wants to approve or not. 

It's like being in the supermarket.  She can decide which card she wants to give – and if she wants to.  It makes sense for her.  It's simple.  Its a clean UI.  It's well done. 

Kim:  (Referring to SXIP's cool new system – that supports Information Cards.)  So has your mother actually seen this?

Dave:  Yes, she's seen it running on my test machine.  She said, “Oh this is what you do.  I finally get it.”  And I had to say, “Well, this isn't exactly what I do – it's what another company does.”  But you got her closer to understanding what I do than just about anything else I've ever shown her.  So thank you.

Dave is great – and I love his mother too.  Any thanks should be directed to all the people on the CardSpace team who did all the work and refinement and threat modelling and studies, and who are coming out with a nice update in the very near future.

Trustworthy Computing Privacy Award

While working on the Laws of Identity and CardSpace, it seemed that each new idea led inevitably to the next.  I really had no choice in arriving at the concepts that arose.  There was no other way to create an identity layer for the internet.   

But as the issues unfolded, it became clear that the road to be travelled wasn't going to be easy.  In fact, it was going to be hard.  It involved risk.  It required people and organizations to rise to challenges that seemed almost impossible.  It needed profound goodwill.  Do we dare say it required trust?

In the early days, as I shared my conclusions, my colleagues in the blogosphere and the conference rooms would say, “Kim, we don't doubt your personal integrity, or your vision; but surely you can't expect us to believe that Microsoft is really going to back you on this stuff…”

And when I looked coldly at what would be required of Microsoft, I could see that there was probably no large company in the world that could do all the counter-intuitive things necessary for success. 

  • In a world where the erosion of privacy was becoming endemic, I would need a Microsoft relentless in championing privacy. 
  • In a world where you are normally lucky just to get your research funded, I would need a Microsoft that would not only fund but then freely share every aspect of the new technology. 
  • In a world polarized between open-source and inventor-owned software, I would have to ask both sides to work together in a single community for the good of everyone. 
  • Having concluded that the original thinking about Passport broke the laws of identity, I would need a Microsoft willing to admit to the mistake, and show it could learn from it. 
  • Above all, I would need a Microsoft that would let me be completely open about what I was thinking, despite my internal role as an architect.  That was the only way I could speak both to Microsoft and to the rest of the industry, to argue for the changes everyone would need make if we were to be successful. 

The project could not succeed if we failed to achieve any of these.  And then, only after that, you had all the uncertainty associated with the introduction of any new paradigm, and any new product.  I would need a team willing to buy fully into all the architectural tenets, and to defend them with passion while building something eminently usable.

Other than love, there is little that is higher in my estimation than authenticity.  To actually be the architect of identity I was supposed to be, I would have to express what was required, try to find the language, try to build the context.   That's what this blog has been about, transforming itself so that more and more it became a place for me to learn and to work.  

If this has all been a voyage, this week was a milestone.  The interoperability event at the Burton Group's Catalyst conference was stunning (more later).  The combined impact of the open source community and Microsoft and many other companies charging into this new world of Information Cards and claims-based computing was intoxicating.   

But there was a second milestone as well – one which I had never predicted.  And although it seems like a personal one, it really isn't, so I hope you will let me share it with you.

I received an award from my colleagues at Microsoft.  Here's the congratulatory letter:

To: Kim Cameron
From:  Bill Gates and Scott Charney
Re: 2007 Trustworthy Computing Privacy Award

On behalf of Microsoft, we want to congratulate you for your outstanding contributions to Trustworthy Computing during the last year.

In recognition of your efforts – which stem from your passion, determination and leadership – you have been chosen to receive the Trustworthy Computing Privacy Award.  Your work is having a tremendous impact across the company, and has significantly improved customers’ interactions with Microsoft.

Specifically, your Laws of Identity, and the work you are leading on the Identity Metasystem, is establishing the foundation for electronic credentials in the virtual world, and is leading a renaissance for identity solutions.  By placing individuals at the center of trust decisions and establishing contextual frameworks where credentials can be recognized, these laws are able to address security requirements while respecting the privacy needs of individuals.  These seven laws, and the identity metasystem, governed the design of the potentially game-changing functionality of Windows CardSpace.

The Trustworthy Computing Privacy Award is a key achievement that recognizes outstanding contributions in advancing an important company tenet. It acknowledges and rewards individuals and teams who have pioneered noteworthy process improvements and innovations in their pursuit of trustworthy computing.  Receiving the Trustworthy Computing Privacy Award is a level of recognition that only few of our finest employees achieve.  Everyone involved in this project should be extremely proud of this accomplishment.

Congratulations again on your achievement, and congratulations on your efforts.

Sincerely

Bill Gates, Chairman, and

Scott Charney, Corporate Vice President, Trustworthy Computing.

Not only had Microsoft supported my work.  It had risen to the extreme challenges my work set for it.  And this would not have been possible without the contribution of many others, like Scott Charney, who were working to guide Microsoft in the same direction I was. 

I was especially happy to receive the award from Bill Gates, whose vision reaches across every aspect of technology.  He, above anyone else, is the symbol of a Microsoft that “gets” identity, and I thank him very deeply.

I don't normally get into a lot of stuff about Microsoft on the blog, but this award thing has made me stop and think about what she has been willing to do, OSP and all.  I congratulate her on what she has done already, and will continue to do, to move us closer to the identity big bang.

Control, not nagging

In a piece called Pleading down the Charges, Jeff Bohren of talkBMC  refers to the discussion I've had with Conor about invisible redirection as ‘inflammatory’, and adds: 

“In subsequent exchanges Kim and Conor plead the charges down from a felony to a misdemeanor. Kim allows that the redirection is OK so long as the IdP is completely trusted, but he is concerned about the case where the IdP is not trustworthy…

It's probably true that my “hand in wallet” metaphor was a bit stark.  But how can I put this?  I'm doing a threat analysis.  Saying everything is OK because people are trustworthy really doesn't get us very far.  Even a trustworthy IdP can be attacked;  threats remain real even in the light of mitigations. 

When we put on our security hats, and look at the security of a system, we try as hard as we can to explore every possible thing that can go wrong, and develop a complete profile of the attack vectors.  No one says, “Hey, don't talk about that attack, because we've done this or that to prevent it.”  Instead, we list the attack, we list what we do to mitigate it, and we understand the vulnerability.  We need to do the same thing around the privacy attack vectors.  It is revealing that this doesn't seem to be our instinct at this point in time, and reminds me of the days, before the widespread vulnerability of computer systems became apparent, when people who brought up potential security vulnerabilities were sent to stand in the corner.

Jeff continues:

What is missing from this discussion is the point that “automatic redirection” is not mandated by SAML. Redirection, yes, but automatic redirection is not required. The SP could very well have presented at page to the user that says:

“Your browser is about to be redirected www.youridp.com for the purposes of establishing your identity. If you consent to this redirection, press Continue. If you do not consent, press Cancel….

Correct.  This could be done.  But information can also be made to fly around with zero visibility to the user.  And that represents a risk.

Jeff concludes:

Nobody does this kind of warning because the average user doesn’t want to be bothered and isn’t concerned with it. Not as concerned as, for instance, having a stranger reach into their pocket.

Actually, thanks to “invisible system design”, the “average user” has no idea about how her personal information is being sent around, or that with redirection protocols, her own browser is the covert channel for sharing her identity information between sites.  This might be all right inside an enterprise, when there is an implicit understanding that the enterprise shares all kinds of personal information.  It might even be OK in a portal, where I go to a financial institution and expect it to share my information with its various departments and subsidiaries.  But in the age of identity theft, I'm not so sure she would not be concerned with the invisible exchange of identity information between contextually unrelated sites.  I think she would probably feel like a stranger were reaching into her wallet. 

To be clear, my initial thinking about the “hand in wallet” came not from SAML, but from X.509, where the certificates described in Beyond maximal disclosure tokens are routinely and automatically released to any site that asks for them without any user approval.  SAML can be better in this regard, since the IP is able to judge the identity of the RP before releasing anything to it.  In this sense, not just any hand can reach into your wallet – just a hand approved by the “card issuer”…  This is better for sure.

Do we need to nag users as Jeff suggests might be the alternative? No.  Give the user a smart client, as is the case with CardSpace or Higgins, and whole new user experiences are possible that are “post nagging”.  The invisibility threat is substantially reduced.

In my next post in this series I'm going to start looking at CardSpace and linkability.

Beyond maximal disclosure tokens

I concluded my last piece on linkability and identity technology by explaining that the probability of collusions between Relying Parties (RPs)  CAN be greatly reduced by using SAML tokens rather than X.509 certificates.  To provide an example of why this is so, I printed out the content of one of the X.509 certificates I use at work, and here's what it contained:

Version V3
Serial Number 13 9b 3c fc 00 03 00 19 c6 e2
Signature Algorithm sha1RSA
Issuer CN = IDA Enterprise CA 1
Valid From Friday, February 23, 2007 8:15:27 PM
Valid To Saturday, February 23, 2008 8:15:27 PM
Subject CN = Kim Cameron
OU = Users
DC = IDA
DC = Microsoft
DC = com
Public Key 25 15 e3 c4 4e d6 ca 38 fe fb d1 41 9f
ee 50 05 dd e0 15 dc d6 2a c3 cc 98 53
7e 9e b4 c7 a5 4c a7 64 56 66 1e 3d 36
4a 11 72 0a eb cf c9 d2 6c 1f 2e b2 2a
67 4f 07 52 70 36 f2 89 ec 98 09 bd 61
39 b1 52 07 48 9d 36 90 9c 7d de 61 61
76 12 5e 19 a5 36 e2 11 ea 14 45 b1 ba
12 e3 e2 d5 67 81 d1 1f bb 04 b1 cc 52
c2 e5 3e df 09 3d 2b a5
Subject Key Identifier 35 4d 46 4a 13 c1 ae 81 3b b8 b5 f4 86 bb 2a c0 58 d7 ad 92
Enhanced Key Usage Client Authentication (1.3.6.1.5.5.7.3.2)
Subject Alternative Name Other Name – Principal Name=kc@microsoft.com
Thumbprint b9 c6 4a 1a d9 87 f1 cb 34 6c 92 50 20 1b 51 51 87 d5 a8 ee

Everything shown is released every time I use the certificate – which is basically every time I go to a site that asks either for “any old certificate” or for a certificate from my certificate authority.  (As far as I know, the information is offered up before verifying that the site isn't evil).  You can see that there is a lot of information leakage.  X.509 certificates were designed before the privacy implications (to both individuals and their institutions) were well understood.

Beyond leaking potentially unnecessary information (like my email address), each of the fields shown in yellow is a correlation key that links my identity in one transaction to that in another – either within a single site or across multiple sites.  Put another way, each yellow field is a handle that can be used to correlate my profiles.  It's nice to have so MANY potential handles available, isn't it?  Choosing between serial number, subject DN, public key, key identifier, alternative name and thumbprint is pretty exhausting, but any of them will work when trying to build a super-dossier.

I call this a “maximal disclosure token” because the same information is released everywhere you go, whether it is required or not.  Further, it includes not one, but a whole set of omnidirectional identifiers (see law 4).

SAML tokens represent a step forward in this regard because, being constructed at the time of usage, they only need to contain information relevant to a given transaction.  With protocols like the redirect protocol described here, the identity provider knows which relying party a user is visiting. 

The Liberty Alliance has been forward-thinking enough to use this knowledge to avoid leaking omnidirectional handles to relying parties, through what it calls pseudonynms.  For example, “persistent” and “transient” pseudonyms can be put in the tokens by the identity provider, rather than omnidirectional identifiers, and the subject key can be different for every invocation (or skipped altogether). 

As a result, while the identity provider knows more about the sites visited by its users, and about the information of relevance to those sites, the ability of the sites to create cross-site profiles without the participation of the identity provider is greatly reduced.  SAML does not employ maximal disclosure tokens.  So in the threat diagram shown at the right I've removed the RP/RP collusion threat, which now pales in comparison to the other two.

As we will see, this does NOT mean the SAML protocol uses minimal disclosure tokens, and the many intricate issues involved are treated in a balanced way by Stefan Brands here.  One very interesting argument he makes is that the relying party (he calls it “service provider or SP), actually suffers a decrease in control relative to the identity provider (IP) in these redirection protocols, while the IP gains power at the expense of the RP.  For example, if Liberty pseudonyms are used, the IP will know all the customers employing a given RP, while the RP will have no direct relationship with them.  I look forward to finding out, perhaps over a drink with someone who was present, how these technology proposals aligned with various business models as they were being elaborated.

To see how a SAML token compares with an X.509 certificate, consider this example:

You'll see there is an assertionID, which is different for every token that is minted.  Typically it would not link a user across transactions, either within a given site or across multiple sites.  There is also a “name identifier”.  In this case it is a public identifier.  In others it might be a pseudonym or “unidirectional identifier” recognized only by one site.  It might even be a transient identifier that will only be used once.

Then there are the attributes – hopefully not all the possible attributes, but just the ones that are necessary for a given transaction to occur.

 Putting all of this together, the result is an identity provider which has a great deal of visibility into and control over what is revealed where, but more protection against cross-site linking if it handles the release of attributes on a need-to-know basis.

CardSpace control for ASP.NET

Dominick Baier at LeastPrivilege has made leaps and bounds in his CardSpace control for the Microsoft ASP.NET environment (though it should work equally well for people using a Higgins identity selector or managed card).  It is very cleanly designed.  Amazingly, he's already added support for the new icon (does he ever sleep?).  His blog has an ongoing discussion around the control and related issues:

After I made some incremental changes and releases of my CardSpace control (found some bugs, got some feedback), I wanted to consolidate all the information along with a new version and some new features here. It now contains all the features I need and will be the last release for some time i guess.

If you have any feedback or suggestions feel free to write me or leave me a comment. If you want to add support for XHTML, contact me too 😉

Download here. Have fun!

PS. This was only possible with a little help of my friends…thanks Brock and JasonD!

Features

Easy to use syntax
One of my main goals was to have an easy to use markup syntax and intellisense support. I don't want to type in all those namespace URIs…

<lp:CardSpaceSelector runat="server" ID="_selector_sic" AutoPostback="true" 
    IssuerType="SelfIssued"> 

    <lp:ClaimType Name="givenname" /> 
    <lp:ClaimType Name="surname" /> 
    <lp:ClaimType Name="email" /> 

</lp:CardSpaceSelector>

Clean markup and independence of the server form
The emitted markup works with Firefox and IE. I also made sure that the <object> tag is placed outside of the postback form. This allows you to have multiple postback controls on the form without triggering the identity selector.

Support for standard InfoCard image
You can choose between all standard sizes of the official InfoCard image. You can also supply your own image and dimensions

Designer integration
I never use the designer – but I acknowledge the fact that some people do 😉 The control renders correctly in the designer and has an editor to setup the required/optional claims (including intellisense support).

Event driven
The control fires an event when a token is submitted.

protected void _selector_sic_TokenSubmitted(object sender, TokenSubmittedEventArgs e) {     string xmlToken = e.Token; }

Conditional rendering
You can choose to render the control only if the client browser supports InfoCards. You can specify an alternative <div /> that would render in that case (e.g. to tell the user how to get CardSpace).

Decoupling
I intentionally didn't couple the control with any user management semantics (like membership) or decryption clases (like the TokenProcessor). It is totally up to you how to proceed after you received the encrypted token. This is considered a feature 😉

Properties

InfoCard setup

IssuerType
This enum has two values ‘SelfIssued’ and ‘Managed’. If you select ‘SelfIssued’ then the issuer URI for self-issued cards will be emitted. If you select ‘Managed’ you have to set the issuer URI yourself. Defaults to ‘SelfIssued’

Issuer and IssuerPolicy
Specifies the URIs for the issuer and the issuer policy.

TokenType
Specifies the token type. Defaults to SAML 1.0.

PrivacyUrl and PrivacyVersion
Specifies to the URL and version of the associated privacy policy (if any).

Image

ImageUrl
Specifies a custom image to display. Defaults to the official InfoCard icon. 

StandardImageSize
Selects one of the standard images sizes for the official InfoCard icon. Defaults to 114×80.

Width & Height
Specifies the size of the image in pixels. Only relevant when a custom image is used.

Rendering

RenderOnlyIfSupported
When set to true, the control will only render if the client browser supports CardSpace. You have to embed the control into a <div /> and specify the name in the DivToRender attribute. Defaults to false.

DivToRender
Specifies which <div /> to render/make invisible based on client support.

UnsupportedDiv
Optionally specifies a <div /> to render when CardSpace is not supported on the client.

RenderMode
Choose between static and dynamic rendering. Static preserves the space for the control on the client. Defaults to Static.

Misc

HiddenFieldName
Name of the hidden field used to transmit the token back to the page. Defaults to __XMLTOKEN.

AutoPostBack
Specifies if the control posts back after a card has been selected. Defaults to false.

TriggerOnLoad
Specifies if the identity selector should be invoked directly after the page has finished loading. Defaults to false.

XmlToken
Holds the encrypted token after the user has selected a card.

Dominick also did a set of four videos on CardSpace for UK MSDN that I would recommend:

Implementation Strategies

Also find the sample code he used here

Report on EEMA e-Identity Conference in Paris

Marcus Lasance has a new blog called IdentitySpace that brings us a comprehensive piece on the EEMA e-Identity conference held recently in Paris.  Reading it will give you a feeling for some of the conversations that are going on around identity in Europe.  I'll quote randomly to pique your interest:

“Olivier Delos of SEALED gave a good example of how e-Id cards issued by governments can be used to facilitate electronic transactions in the private sector. However ‘anti’ the privacy lobby may make us want to feel against such applications, the presented use case of a Belgian Water Company clearly showed what savings can be made when users are allowed to use their Belgium Citizen ID card as an identity service provider. 150,000 address change notifications are now processed this way in a matter of seconds, with zero manual input, zero errors and a user satisfaction rating of ten out of ten.

“Unfortunately this type of example where businesses are allowed to benefit from an infrastructure provided by government remain rare and citizen to government transactions requiring an e-Identity to be presented amount to only 1.7 transactions per year according to one study. Hardly what you would call a ‘killer application’. So the barrier to acceptance remains a big concern about privacy, even though according to Kim Cameron the technology is designed to enable the relying party to remain hidden from the Identity provider when privacy is a concern. Before ‘Jo public’ readily accepts this is the case, a lot of water will flow under the bridge unfortunately.”

I need to make a clarification. Out of the box, current Citizen Cards use maximum disclosure certificates and omnidirectional keys – they are only suitable for completely “public” identity contexts. But by using them to authenticate to identity providers that support minimum disclosure tokens, we can end up with true privacy enancing systems. If we accomplish this, then working together with privacy advocates, academics and influentials from across society, we can win the trust of Joe Public, who in my view has every right to be suspicious.

“David Ramirez showed an application of Federation using SAML V2.0 in the world of the converged networks of Internet and Mobile data access. For me the example of how SAML could be used to give law enforcement agents or ‘spooks’ access to mobile phone records was a bit unfortunate in view of the earlier privacy discussions, but I guess its one application of this technology which can’t be ignored. [Hope Conor reads this… – Kim]

“Kieron Salt did his expose on European Union funded research project GUIDE, an acronym for Government User Identity for Europe. This project is driven by the objectives of the Manchester Declaration which states that by 2010 all European citizens and businesses shall benefit from locally-issued electronic IDs for use across the EU. But we had seen from previous presentations, that there is plenty of scope here for identity fraudsters until interoperability issues are sorted out.

“GUIDE is not about creating a meta directory of all member states’ Identity data, but rather about creating a gateway providing interoperability between the different standards chosen by the different member states. The gateway for instance should be able to handle transactions between SAML, Shiboleth and WS-Federation schemes, if those are the three standards commonly used in Europe…

“Dr. Ruth Halperin of the London School of Economics and Political Science has conducted an in depth research project into the extent to which citizens across European Countries trust their authorities to exchange data in an appropriate manner across government departments, between governments and commerce…

“Dr. Halperin concludes from her research that in Europe citizens have far more trust in commercial organisations than in their respective governments, an opportunity that did not go unnoticed by the next presenter from Norway representing DNV – an independent foundation Established in 1864 in Norway for the purpose of independent assessment of the quality of ships to aid insurance companies in setting realistic insurance rates… So why not carry on this position to new areas like identity assurance in the digital value chains? PKI and digital signatures are key elements in securing such processes.

Marcus also covers the keynotes, including mine.

Announcing the Information Card Icon

I want to congratulate Mike Jones and my other colleagues for all their work in creating and figuring out how to protect an Information Card icon that can be used by everyone worldwide who supports InfoCard technology.  Creative people, legal people, and marketing folks all helped bring this to fruition.  Here's Mike's post:

I’m very pleased to announce that, as of today, there is now a graphical icon freely available for people to use to indicate that “Information Cards are accepted here”. This icon is intended to provide a common visual cue that Information Cards can be used to provide information to a site or program, similarly to how the RSS icon is used to indicate the availability of syndicated content.

The guidelines for the use of the icon, a frequently asked questions document, a set of png images of the icon rendered in a range of sizes, and the original artwork in Illustrator format are all available together in a download package. Please consult the guidelines and the FAQ before using the icon.  [You can also download the icon package here – Kim]

You’ll notice that the login page for my blog now uses the icon. Hopefully your sites will soon too!

And just for fun, because the icon is, after all, a graphical element, here’s a gallery of the renderings of the icon that we included in the downloads package. Enjoy!

OK Mike – I just updated my login page too.  I used to have the picture of my heroine Elastigirl as my InfoCard icon, but it's time to move on.  I'll continue to honor her through the quote at the top of my blog.

For the curious, Mike's posting includes the definitive series of icon variants – an outstanding display of Warholian excess.