Leaving a comment

Since one of my goals is to introduce people to Information Cards – and because I used to get mountains of spam comments and worse (!) – I require people to either write to me or use an Information Card when leaving comments on my blog. 

(This blog is hosted for me by Joyent, and it runs on open source software (WordPress, PHP, MySQL, Apache, OpenSolaris).  For Information Card support, it uses Pamelaware, an open-source project offering an Information Card plugin for WordPress and other popular programs.)

Information Cards use an “identity selector”.  Vista has the CardSpace V1 selector built right in.   (If you  don't use Vista please continue here.   Also, if you are wondering about our new beta of Windows CardSpace Geneva – V2 if you want – I'll deal with that in a separate post.)

How you register at my site

1. Click the Information Card logo or the “LOG IN” option in the upper right hand corner of the blog.  (Clicking the logo saves you the step where you can learn about Information Cards).


2. If you clicked the logo, go to step 3.  If you have clicked “LOG IN”, you will see this page and can explore the ‘Learn More’ and other tabs.  When ready, click on the Information Card logo to proceed.


3. CardSpace will start (it may be a bit slow the first time it loads).  It will verify my site's certificate, and present it t you so you can decide whether or not to proceed.  Click “Yes, choose a card to send”.


4.  If you are trying CardSpace for the first time, you don't have a “Managed” card yet.  So just create a “Personal Card” that serves a bit like a username / password – except it can't be phished and protects your privacy by automatically using a different key at every site. 


5. You'll be asked to create a Personal card.  Name it with something you'll recognize, and I recommend you put a picture on it (the picture will never be sent).  The name and picture prevent many attacks since if someone tries to fool you with a CardSpace “look-alike”, they won't know what your Cards look like and you will immediately notice your cards aren't present! 

Use an email address that you control – you will have to respond to a confirmation email.  Then click SAVE.



6.  Now you'll see your saved card, and click SEND.


7.  The information from your card will be used to log in to my site, but I'll notice you haven't been here before and send you an email that you must click on to complete registration (I want some way to prevent spammers from bothering me).


8.  The email I send looks like the one below.  IMPORTANT NOTE:  this email might be “eaten” by your spam protection software (!) , so don't overlook your spam folder to find it.  (On Hotmail, it doesn't ever get delivered – haven't sorted that out yet.  It doesn't seem to like my little mail server.)  

9.  When you click the embedded link you'll be taken back to my blog as a verification step.  Click on the Information Card logo to log in.


10.  CardSpace will come up, and will recognize my site.  Just click send.


11.  Et voila…

Press “Go to Blog” and you can leave your comment.

In the future, logging in will just be a two-step process.  Click on the CardSpace logo, click on your personal card, and you will be logged in.  No password to remember.


Published by

Kim Cameron

Work on identity.

13 thoughts on “Leaving a comment”

  1. You forgot to mention that this whole thing is IE only. Firefox reports a missing plugin that it can't find. And I wasn't expecting the UAC UI kicking in either. But I did make it work, hence this comment.

  2. Hi Kim – just a couple of corrections from your favourite pedant 🙂

    1. ‘SUN’ is just ‘Sun’. It's not an acronym. OK – it was, years ago (from Stanford University Network), but it's probably been Sun for as long as MicroSoft has been Microsoft 🙂

    2. Joyent actually run OpenSolaris (in fact, they have arguably the biggest OpenSolaris deployment in the world – see http://joyent.com/accelerator and http://www.sun.com/customers/servers/joyent.xml) – so you do, in fact, run on an all open source stack 🙂

  3. The title of the blog looks ‘dirty’ – it has excess pixels, probably from too much compression. If size is an issue, how about just using HTML text instead of an image of text?

  4. Thanks Bryan – I'm looking for the Firefox plugin link and will post it when I rack it down. By “the UAC kicking in” I assume you refering to the darkened screen when CardSpace comes up. We're trying to make that more subtle (!) in V2.

    Pat, thanks for the corrections – Gee, I guess I've got to update my acronym list. As an old UNIX guy I found it had a few little quirks but I've enjoyed using it.

    Bruce, I should probably do that. But can you also tell me what browser you are using?

  5. Just for completeness, DigitalMe and Firefox (with appropriate plugins) work on both Macintosh and Linux (Fedora 9) systems.

    DigitalMe and Safari fails here, but works elsewhere. Pam has been notified.

  6. Kim,

    CardSpace under Vista X64 SP1 dies (CardSpace window flashed on screen and then disappears)when invoked from your site. It also dies when invoked from the Control Panel!
    I've tried it both from my primary desktop, and a clean install. It works fine under Vista x86 SP1, which is how I'm now posting a comment.


  7. OK.

    I did dome investigation. Killing the Acronis scheduler task (Acronis had been unistalled!)cleared the problem.

    But an issue still remains. Why is ardSpace so sensitive to other tasks running in parallel?


  8. Kim,

    Since I've now got it working under Vista x64, I tried migrating the self-generated infocard I had created under Vista x86 to my Vista x64 systems, by backing up the card on x86 and restoring it on x64. Unfortunately, the site-specific card id got changed to a new value (repeatedly). Reversing the path had the same effect. Is there any way to employ a single self-generated infocard across systems?


  9. I have the habit of leaving unique email addresses on every site I visit (http://pascal.vanhecke.info/2007/10/09/master-of-your-mailbox-an-email-alias-for-every-site-you-leave-your-address/).

    If I want to keep this habit with infocards, I would need to create an infocard for every site I register at… at least when those sites keep requiring an email address at registration.

    I assume that the required email address is a relic of the way WordPress registers users, because in itself I do not see any reason why an email address should be necessary to register at this blog?

  10. Kim,
    Good to see you again. As we started to discuss at TSCP yesterday, the concept of assigning a LOA to an attribute is, frankly, bizarre and can only lead to the End Of The World As We Know It (except that certain political forces may get to that endpoint before this idea does). Seriously, though, the idea of LOA for attributes is a very bad idea. It makes AuthZ even more massively burdensome than it can be and it does nothing but confuse both Users and Relying Parties.
    The simple, basic logic is this: An attribute issuer is authoritative for the attributes it issues. If you ask an issuer if a particular user�s asserted attribute is valid, you�ll get a Yes or No answer. If you ask that issuer what the LOA of the user�s attribute is, it will be confused � after all, the issuer issued it. The answer is binary: 1 or 0, T or F, Y or N.
    But wait, the fans of attribute LOA say, what if you ask a secondary source if that same user�s same attribute is valid? This is asking an entity that did not issue the attribute to assert its validity. Here�s where complications ensue, since the RP has to decide how much it trusts the secondary source and then how much it trusts the secondary source to assert the true status of the attribute. Putting aside questions of why one would want to rely on secondary sources in the first place, implicit in this use case is the assumption that the RP has previously decided who to ask about the attribute. If the RP has decided to ask the secondary source, which is a trust decision which one would assume would be based on an evaluative process of some sort and that the RP had decided to trust the answers of the secondary source. After all, why would an RP choose to trust a source just a little bit? Really doesn�t make sense and complicates the trust calculation no end. Not to mention raising the eyebrows of both the CISO and the corporate/agency lawyer (very bad things).
    Thus, the RP decides to trust the assertion of the secondary source. Thus the trust decision is binary and the response back to the RP from the secondary source would be binary. A federation operator (or Trust Framework Provider, take your pick) could serve as a repository of trusted sources for attribute assertions as a member service and in that case it, too, would explicitly trust the attribute sources it lists for its member RPs. If it chose not to trust certain secondary sources, it simply wouldn�t add them to the white list, table, FAT, whatever.
    RP or TFP make a binary trust decision about who to trust and the example reduces to the original situation.
    Another circumstance where attribute LOA might be considered is the �what�s my bank account balance� kind of question, which is, querying about an attribute that itself changes rapidly in real time. An attribute is valid at the time of issuance. A query from an online business to an end user�s bank would want to know if the user had sufficient funds to cover the transaction. Does the business ask if there�s $813.63 in the user�s account? At the time of the query the answer is binary, yes or no. The business that queries the bank for the total of the account violates all kinds of privacy and appropriateness and will likely get a phone call from a bank VP or, worse yet, attorney. Same thing holds for credit purchases. The point here is that, even for ephemeral attributes, the answer is directly relevant to the state of the attribute at the time of query and that answer is binary, Y or N. I guess I can imagine a situation where an online entity asks the attribute provider if the user will have $4,000 in assets a month hence, but I can�t imagine any attribute being created for that kind of question.
    The business makes a binary decision about whether to trust the user�s worth at the time of purchase � and of query – and concludes the sale or rejects it. The case resolves back to binary again.
    Admittedly, things can get complicated when the identity of the attribute issuer is obscure, such as US Citizenship for the native-born. In this case, as an example, the RP would have to make an up-front decision on what source it�s going to ask about that attribute. Doesn�t matter what the answer is, the point is that the RP will make a decision on which source it deems authoritative and it will trust that source�s assertion of that attribute. Okay, so the RP chooses two sources, the State Department � if the user has been issued a US passport that�s a priori proof of citizenship � and or some other governmental agency which keeps a record of State of birth, another a priori proof of citizenship. On a query, the two disagree, that is, the State department says the user has a valid US Passport while the other agency says state of birth is Colombo, Sri Lanka. Just sayin�. So now the application has to choose between the two, or query the INS to see if the person is a naturalized citizen. Or assign a degree of trust � the LOA idea sneaking in. Wow, FUBAR. The user gets tired of waiting and hangs up. And at the end of the whole process, the application is going to make a binary decision about whether to trust that the user is a US citizen and all that intermediate drama that had to be dreamed up to justify attribute LOA again resolves down to the original case, though in this one the RP decides which source is both primary and authoritative.
    I hate to beat this dead horse but in each case I�ve listened to over the past few years, every single one of them reduces to a binary decision. Sure, people can create Rube Goldberg-ian use cases that require attribute LOA or even plop them in (to increase billable hours, one suspects), but they�re essentially useless and a waste of time and effort. The bottom line is that the RP makes policy decisions up front on who to trust about the validity of attributes and the individual decisions lead to binary assertions of attribute validity.
    Soon, we go fishing together: a nice, relatively safe analog event.
    Best regards,
    Peter Alterman

Comments are closed.