In Context

June 29, 2009

Azigo’s new CEO

Filed under: — paul @ 2:59 pm

I’m very happy to announce that we’ve hired Jeff Carter, Bank of America veteran and the founder of MIT’s Center for the Future of Banking as CEO of Azigo. I’ll continue on as Azigo’s CTO with as much enthusiasm as ever. Even more! The press release about Jeff was covered in yahoo finance, CNBC, here and in Mass High Tech article

Jeff is flying back today from keynoting at Amplify 09 in Sydney. Here is a writeup of some of what Jeff had to say about the future of banking.

June 22, 2009

CyberSecurity Review Paper

Filed under: — paul @ 4:36 pm

The White House has completed its 60 day Cyber Policy Review and published it as a 76 page PDF. This was announced on the whitehouse.gov blog post Securing Our Digital Future. I co-authored with Kim Taipale, Bill Coleman and John Clippinger of an invited paper entitled Identity and Resiliance (PDF), one of the 100 papers mentioned in that blog post that informed their recommendations.

Slowly but surely the understanding is growing in various pockets within our government that a user-centered, distributed, open identity layer (bus or metasystem, pick your poison) is critical infrastructure for both security and collaboration.

June 19, 2009

Privo Information Card

Filed under: — paul @ 10:15 am

privoPrivo, Microsoft and Azigo have announced Privo Puts Parents in Charge Online with Information Cards.

Denise Tayloe (CEO of Privo) is friend, colleague and an expert in the field of protecting children online. Denise has created web services for major online businesses that other experts have told me “can’t be done” while adhering to COPPA.

Azigo and Microsoft, each in different ways, have been very supportive of Denise, Privo, and the general concept that child-protecting solutions could be based Information Cards as a technology foundation. For our part, Privo’s new card issuing site is powered by Azigo CardPress. But our relationship goes much further. For example, last year Denise and I co-authored a paper that we submitted to the Berkman Center’s Internet Safety Technical Task Force. [I should dig that up and put a link to it]. Their final report is here. I blogged about it here.

Acxiom Information Card Announced

Filed under: — paul @ 9:45 am

acxiomAcxiom is now an Information Card issuer! See Acxiom Launches Online Identity Card to Help Businesses for the press release. More info from Acxiom. I’m proud to say that the site is powered by Azigo CardPress.

[A nit. I'm not wild about calling these things "identity" cards, because they don't necessarily identify you. If the relying site (or local app) only requires non-identifying claims, then even if the Acxiom card supports identifying claims, these identifying claims won't be released to the relying party. Equifax chose the same language. Maybe they both know something I don't.]

June 8, 2009

The “no-name” protocol

Filed under: — paul @ 10:15 pm

Problem statement

We have no name for the “protocol that defines the interaction between a card selector and a relying party Website (or a local relying party application) that was originally defined by Microsoft in the “Identity Selector Interoperability Profile” (ISIP) documents, is now being standardized at the OASIS IMI TC and was first implemented by CardSpace™ (and later independently by others).”

[BTW, we also lack a name for the set of protocols (centered on WS-Trust, but including WS-MetadataExchange, and others) that define the interaction between a card selector and an STS (IdP), but I think calling this WS-Trust or WS-* will probably suffice for most cases. Since only IdPs care about this protocol suite, and since there are so many fewer of these than RPs this naming problem is a less pressing issue.]

Three candidates found in the wild

  • Some folks call the <no-name> protocol “Information Card” (or InfoCard or I-Card). For example, major websites are telling us that they would like to support both the “OpenID” protocol and the “Information Card” protocol. The problem is, this usage confuses a user metaphor with a protocol. Information Cards (and selectors) will ultimately work with lots of protocols (e.g. <no-name>, OpenID, and SAML) as well as a with a perenial favorite of mine “username/password!”
  • Some folks refer to the <no-name> protocol as “IMI” after the name of the OASIS Technical Committee mentioned in the problem statement above.
  • Many folks (especially in Europe) refer to the <no-name> protocol as “CardSpace.”

My two cents…

In formal documents (e.g. at the ICF) we could refer to it as “IMI Protocol” and informally we could call it the IMI(CardSpace) Protocol.

Apologies all around

If this is the direction we as a community take, then I want to apologize to Stefan at Fun Communications and lots of other folks for my earlier confusion on this matter.

June 3, 2009

Life before you have a selector

Filed under: — paul @ 10:13 pm

Having worked on selectors for so long I’ve needed to remind myself that there really is life before you have a Card Selector installed on your machine. And now that I look into it, I see that this selector pre-existence could use some improvement.

The Problem

Imagine a person without a selector goes to a website that displays three ways to log in: (1) username/password fields, (2) the purple I-Card Icon:

infocard_120x80

and an OpenID NASCAR (NASCAR) like this (courtesy of JanRain’s very cool RPX):

nascar-rpx

The OpenID NASCAR consumes a vast amount of real estate and it has other issues that have been widely discussed. But compared to the purple icon, it’s much better. Why? The user might recognize some of the logos and best of all, if you click on one of them you’ll begin the process of getting an OpenID, and eventually logging in. By contrast the user probably doesn’t know what that purple icon even is and what to do next. There are no familiar logos, and no instructions as to what to do. It seems like the Information Card community has focused so much on the UX AFTER you have a selector, that the user’s life BEFORE they have a selector installed has been ignored.

Some Suggestions

The rest of this post gives some suggestions as to what might be done to help the selector-less user. First, perhaps the purple icon should always have some “hover” text that pops up. Something like this:

selectorless-hover

The hover text is there to try to make you click on the darn thing. When you click on it, what happens next depends on what cards the site trusts. If it only trusts one site then you might see this:

selectorless-click-v1

Or if it trusts a bunch of issuers, it might look like this:

selectorless-click-v2

And of course if you click on a card image from card issuer “A”, then you are redirected to site A and walked step by step through a card issuance process. Then, when you’re done getting the card, you can download site A’s recommended selector or click through to this page on the ICF’s site. [That page needs work too!]. And then when all of this is done perhaps site “A” could redirect you back to the original website with the purple icon, where you could try clicking it again. Armed with a selector the purple icon should have different hover text. And as we all know when you click it, it WILL launch your spanking new selector.

Powered by WordPress