Category: User centric

Separating the identity of users from services

Geoff Arnold added a comment to an earlier piece that helps tease out the issues around delegation:

In otherwords, there is no user-absent scenario. There is a user is present and delegates authority scenario. After all, how can a user delegate authority if she isn’t present???

That's fine as long as one of the rights that can be delegated is ability to delegate further. And I'm guessing that that's what Eve is really talking about. Not delegating 100% of her rights to some agent, but delegating sufficient rights that the agent can act as a more-or-less first class entity, negotiating and delegating on her behalf.

In fact the only (obvious) right that I should not be able to delegate is the right of revocation….

OK.  So delegation is recursive.  If we accept the notion that services operate within their own identity when they do something a user has asked them to – then if they want to delegate further, they need to create a Delegation Token that:

  • asserts they have the right to delegate in some particular regard; and 
  • defines exactly what they want to delegate further, and to whom.

They need to present this along with the user's authorization.  One ends up with the whole delegation chain – all of which is auditable.

In this scenario, the user's identity remains under her control.  That's one of the things we mean when we say, “user centric”.  By issuing an authorization for some service to do something, she actually asserts her control over it.  I think this would be true even if, given a suitable incentive, she delegated the right of revocation (there are limits here…)

Multiple tokens to capture these semantics 

CardSpace is built on top of WS-Trust, though it also supports simple HTTP posts. 

One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.  

This multi-token design perfectly supports strong identification of a service combined with presentation of a separate delegation token from the user.    It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.

I guess I find Eve's contention that, “By contrast, Liberty’s ID-WSF was developed to support both the ‘human present’ and ‘human absent’ modes” a bit triumphalist and simplistic.   

Going forward I'll write more about why I think WS-Trust is a step forward for these delegation scenarios.  And about why I think getting them right is so very important.

Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve: 

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.

Wrong-headed impersonation

James Kobielus's blog also includes a report on his interview with Eve Mahler.  I think there are two issues raised that deserve discussion.  The first concerns what Eve calls the “human absent” scenario:

“She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the “human present” interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the “human absent” interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

“She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the “human present” mode, which, as Eve stated memorably, means that the “user's policy is in their brain.” By contrast, she pointed out, Liberty's ID-WSF was developed to support both the “human present” and “human absent” modes.

The essence here is her notion that “an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on [the user's] behalf”.

On behalf of…

I'm going to make a categorical statement.  No one and no service should ever act in a peron's identity or employ their credentials when they're not present.  Ever.

It's not that there aren't use cases for which this might seem to be desireable.  For example, let's look at the problem of linkback spam, in which fake sites fill bloggers’ comment queues with garbage.  Suppose, one day, we come up with authenticated linkbacks.  Wouldn't you want the linkback service to be able to log in with your identity?

Another example – given to me by someone who thought it was really definitive – was that of the OnStar notification system.  Suppose you're driving, are involved in an accident, and lose consciousness.  You want your OnStar system to call on your behalf so help will be dispatched.  Clearly you can't participate.  Similarly, hospital scenarios provide all kind of grist for the “human absent” mill.  But should OnStar or a hospital system actually be acting “as you”?

Last-century systems supported exactly this kind of behavior.  We called it “impersonation”.  And anyone who has done practical security work will tell you how many problems this caused, and how wrong-headed it is.  If you give some service the ability to simply appear to be you, you are open to all kinds of attacks – and we've seen them all around us.

Put another way, I don't want OnStar to be be able to act on my behalf with respect to very many things.  I don't want it to be able to remove money from my bank account.  I don't want it buying gifts, or controlling my insurance, or doing anything else other than calling for help.

So what I really want is for OnStar to identify itself as Onstar, and for Kim to identify himself as Kim.  Then Kim can give OnStar a Delegation Coupon allowing it to call for help on my behalf.  The coupon should be very restrictive.  And if the service does something improper, that impropriety will clearly be associated with the service's own identity, not with Kim.

There is no user-absent scenario 

In otherwords, there is no user-absent scenario.  There is a user is present and delegates authority scenario.  After all, how can a user delegate authority if she isn't present???

CardSpace is built on this principle.  A delegated authority coupon is just a set of claims.  CardSpace facilitates the exchange of any claims you want – including delegation claims.  So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate – as itself – presenting delegation tokens whenever appropriate.

This is the right way to do things from a security point of view.  We need to move beyond the idea of omnipotent services running behind the curtain, which is what we have come up with in the past, to a truly secure model where the user consciously delegates and systems demonstrate this in an auditable fashion.

Surely it is obvious this is the best way to reduce everyone's exposure and liability.  The user has less exposure because she controls what she delegates.  The service has less exposure because it operates under specific and explicit permissioning, and insider attacks are significantly mitigated.

As much as I think Liberty represented a step forward when it first stepped up to the plate, it needs to embrace the user-centric model and replace the more monolithic “on behalf of” mechanisms with a proper approach to delegation under the control of the affected parties.

 

New book on Cybercrime

Speaking of new ways for a vendor to win my loyalty, here's an email I got today:

Dear Amazon.com Customer,

We've noticed that customers who have expressed interest in The Digital Person: Technology And Privacy In The Information Age by Daniel J. Solove have also ordered Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society) by J. M. Balkin. For this reason, you might like to know that J. M. Balkin's Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society) is now available. 

You can order your copy for just $22.00 by following the link below.

Cybercrime: Digital Cops in a Networked Environment (Ex Machina: Law, Technology, and Society)
  

J. M. Balkin

Price: $22.00

Book Description

  • “Cybercrime is written by the leading academic experts and government officials who team together to present a state-of-the-art vision for how to detect and prevent digital crime, creating the blueprint for how to police the dangerous back alleys of the global Internet.”

    — Peter P. Swire, C. William O'Neill Professor of Law, the Ohio State University, and former Chief Counselor for Privacy, U.S. Office of Management & Budget.)

  • “A timely and important collection of materials from highly qualified authors. Cybercrime will provide a wealth of new insights both for general readers and for those who study and teach about the legal and policy implications of the internet.”

    –David Johnson, Visiting … Read more)

I actually received this in my mail this morning.  I remember when I got my first email from Amazon, I started fuming.  My reaction was, “No!  This can't be! Not SPAM from Amazon!”.  It seemed incredible.

Then I read the message.  And guess what.  It wasn't SPAM.  Why?  By intersecting its knowledge of my interests with that of other people who share them, Amazon is able to make book suggestions that are just as cogent as most people I know.  This is what I call a relationship.  It isn't based on confinement or bombardment.  It's based on service.  The service is user-centric in a great way.

Now, moving down a level of abstraction, I think I'll buy the book.

Johannes sends “marriage” greetings

Here's more support from another legendary member of the OpenID community, Johannes Ernst of Netmesh.  He's the inventor of LID, and one of the strongest champions for the “URL-based” identity used in OpenID.  He brought ideas his together with Brad Fitzpatrick's quite a while ago now, creating one of the first synergy-lurches for the community.

I should also point out that Johannes has also been one of the first, and most tireless, advocates of the synergy between OpenID and Information Cards.  He has given many cycles to OSIS, the group that has co-ordinated open source work around identity selectors and information card technology.  The beautiful thing here is that convergence with CardSpace MEANS convergence with Information Cards in general, including the Higgins project and work by many others in the community.  I've been concentrating on CardSpace for obvious reasons, but to me it is very important that this goes far beyond CardSpace into another whole community.

Wow! After two years of hard work, we are finally getting real convergence in identity land! Today, Bill Gates is announcing has announced in his keynote at the RSA conference that Microsoft will support OpenID. Here are some posts covering the news:

At NetMesh, we've held for a long time that URL-based identity (OpenID, with its roots LID, i-names and Sxip), and other technologies such as CardSpace have to come together so we can really get to an interoperable, multi-vendor, user-centric identity layer for the open internet. That's why we helped put together OSIS, and lots of activities of that nature.

Now even Bill Gates supports the same vision! Yippie!! (apologies for being too excited, but this is exciting!)

Just pointed out to my wife — who wrote the first line of code, ever, about three years ago, implementing URL-based identity — that in some way, she should now be famous!

So, congratulations Tammy!

Feature – not a bug!

As he says, Brad Fitzpatrick “made” the orginal OpenID to solve problems he was facing at Six Apart.  Of course it grew over time, if anyone's opinion counts, it's his.  And here it is:

So Bill Gates just announced earlier this morning (while I was sleeping in / recovering) that Microsoft is supporting OpenID.

When I made OpenID, I intentionally left the method of authentication undefined. (feature, not a bug!)

Now people ask me what I think about Microsoft supporting it, using their InfoCards as the method of authentication…. I think it's great! So far I've seen Kerberos integration for OpenID, voiceprint biometric auth (call a number and read some words), Jabber JID-Ping auth, etc…. all have different trade-offs between convenience and security. But as more people have CardSpace on their machines, users should get both convenience and security. (sorry, I'm not totally up on all the details… just seen demos….)

Anyway, I and others at Six Apart are thrilled to see Microsoft supporting OpenID. Kudos!

Thanks Brad.  For us, its clear that OpenID is a really great technology for doing public identities – the simplicity is stunning.  I really like your work.  OpenID is clearly an important part of the identity metasystem.  We really hope to see the synergy keep expanding.

 

Doc Searls on Creator Relationship Management

Here is Doc Searls, Editor of Linux Journal, rapping about the role of identity in a whole new creator-consumer model:   

If incoming mail contains the word “identity” it goes to a mailbox I started in late 2004. It has over 7000 emails in it now. The majority of those are from the Identity Gang list.

The Identity Gang got its name when it first met informally on the December 31, 2004 edition of Gillmor Gang. I've lost track of how many workshops and meetings and other exercizes in convergence we've had, but the progress continues to be amazing.

I just looked at what Eric Norlin of IDG wrote here, then at what Scott Kveton of JanRain wrote here then at what Kim Cameron of Microsoft wrote here — to pick just three out of countless posts, all connected somehow. You can see the progress in just one month.

This observation comes in the midst of thinking about a form of
Vendor Relationship Management that has the same initials as CRM, but a different meaning: Creator Relationship Management.

I would like to relate to creators in a better, less intermediated way. On the supply side, Creative Commons has done a great job of clarifying how artists and their representatives would like to relate in the marketplace. Think of CC as a form of CRM — of customer relationship management. A way of relating to customers. It's a great start. But it still only comes from the supply side.

Now I want to come back at creators from the other direction: from the demand side. From my end, not just theirs. I want to give them something more to relate to than an entry I put in a form on a website. I want to create a mechanism of engagement that is independent of any one supplier: that is silo-free.

I want them to be in my database, not just be one entry in their database.

I want to relate as a customer in the marketplace, and to be able to expand on that relationship in ways that allow both sides to create and expand value.

That means if I like a play, or a piece of music, or a podcast, or a video, or any creative production, and I want to pay the creators (and the producers) for that, I want a way to do that directly, on my own terms, with minimum intermediation.

I want to reward the intermediators too — the producers and distributors, for example. Anybody who contributes value.

Beyond cash for goods or services, I would like the option of having some range in relating. Maybe I want nothing more than give an artist some cash and a high-five. Or I may want a subscription to notices of new work, or to performances near where I live.

The thing is, this mechanism needs to live on my side: to be mine. It must be able to relate to a first source or to an intermediary, but it can't belong to the intermediary. The responsibilities for relating need to be shared. To do that, I need to control my end, free and clear. I can't just be enrolled in a system controlled by the supply side, or by somebody in the middle.

The absence of the power to relate from the demand side — except with cash or mechanisms controled by the supply side or its intermediaries — is a problem as old as the Industrial Age, and it's time to solve it.

So: my role on the demand side needs to be better equipped. How do we do that?

First we start with identity. That's why everything going on in the Identity Space is important. (And why I need to catch up with it.)

Second, we need to pick a problem to solve, not an ocean to boil. Here's one I like: make it easier for public broadcasting listeners and viewers to pay for the goods they receive. Right now public broadcasting continues to raise money in extremely old-fashioned ways. The one I hate most is the fund drive where they turn off programming for two weeks, plead poverty, and then give you a cup or a CD if you send some money. There has to be a better way.

So that's what I want to work on as my first VRM project, which I'll detail in Wednesday's SuitWatch Newsletter, and then here on Thursday. Stay tuned.

The concepts are great.  I wish we had a better word than ‘management’.  It seems like we have to “manage” everything, from time to relationships, when we used to just enjoy them.

 

Scott Kveton on InfoCard / OpenID convergence

Here's a post by Scott Kveton, CEO of JanRain, that sums up a meeting we had during the week.  JanRain is one of the driving forces behind OpenID, and produces the libraries that a lot of people are integrating into their websites and blogs.  JanRain also operates MyOpenId, an identity service that works with OpenID software.

You want to know about the JanRain World Headquarters?  Energy radiates from everywhere.  Beside our conference table was a very impressive can of Bad Idea Repellant, which seems to have done its job.

For what it's worth, I really liked these people.  They are real engineers.  They are committed to getting an identity layer in place. 

I explained my concerns about the current OpenID proposal and  phishing, and they not only ACKed; they had ideas about how to move quickly to change things.  

Against this background it was clear how CardSpace could be one important way of strengthening their system and integrating it with others.  Meanwhile, I conveyed my enthusiasm for the great simplicity of their proposal. 

We talked about public (omnidirectional) and private (unidirectional) identifiers and we all agreed that both were necessary in different contexts.  We talked about how OpenID managed Cards could provide CardSpace with strong new capabilities around public personas for web services.

Then the conversation got pretty technical, and I showed a profile of WS-Trust that didn't involve use of a SOAP stack or anything complicated.  But over to Scott:

Mike Jones and Kim Cameron from Microsoft came in for a visit today to the JanRain World Headquarters (if you’ve ever visited here, you’d understand why that’s funny).

The JanRain engineers were interested in learning more about CardSpace. We’ve heard about it, seen Kim talk and even read his proposal on a way to integrate OpenID and CardSpace. However, we didn’t know enough about the technology to comment on it either way. Also, we wanted to hear more than just marketing hype and hand waving; we wanted some code. Kim and Mike did not disappoint … 🙂

CardSpace is an identity meta-system that you use to manage InfoCards. InfoCards are like the cards in your wallet except these cards you present to sites that you want to visit to identify yourself with. I really believe that Mike and Kim have their hearts in the right place and the technology looks solid. It looks like Microsoft has learned a lot since their last foray into identity. I think OpenID and CardSpace could really compliment each other quite nicely as well as help address the phishing concerns that have become so prevalent.

The CardSpace InfoCard manager is an interface that comes up when the user is presented with a site that supports InfoCard login. Instead of giving the user a login form in the browser that might be phished, the user is presented with a dialog that allows them to deliver an InfoCard for the site they are trying to login to. This dialog is single-modal; you are locked out of doing anything else unless you complete the task at hand. This follows along with what Mike Beltzner shared on the OpenID general list and the difficulties in fighting phishing:

I can also sum things up for you even more succinctly:

– users are task oriented, driving to complete the goal the quickest way possible
– users pay more attention to the content area than the browser chrome
– users don’t understand how easy it is to spoof a website

Kim went through several code examples where we could see how it all worked. Forget SOAP, forget complicated. There is no hook back to the mothership with this technology. As a matter of fact, OpenID and CardSpace could work together quite easily.

CardSpace is really good at handling the issues around phishing and personal privacy. But what if I don’t want to be private about certain things? I like that I can identify myself as me to lots and lots of different sites and I don’t mind if people correlate that data. As a matter of fact, I like it. Wouldn’t it be nice to have an OpenID tied to my InfoCard then? One of the greatest reasons OpenID is succeeding is that its a destination. Its a unique place on the Internet where you can learn more about who I am. Coupled with microformats you start to see some interesting possibilities. CardSpace doesn’t do the public side very well and both Kim and Mike admitted this. This is an interesting possibility for OpenID IMHO. Not only that, it could be done without any changes to sites that already support OpenID. You’d get the benefits of OpenID’s strengths while leveraging the anti-phishing and privacy mojo that CardSpace has.

We already have some great technology for changing the chrome in Firefox and discussions are on-going with Mozilla about how we can integrate this further and have it truly baked in (hopefully they’ll look at Dmitry’s thoughts on this). We’ve got the CardSpace code that is now shipping on Vista and available for Windows XP. We’ve got lots of options for fighting phishing and protecting privacy with more on the way. All of these solutions play to each technologies strengths and actually just might be what we need to get to the identity holy land.

 

How to get a branded InfoCard?

A lot of people have asked me, “But how does a user GET a managed Information Card?”  They are referring, if you are new to this discussion, to obtaining the digital equivalent to the cards in your wallet.

I sometimes hum and ha because there are so many ways you can potentially design this user experience.  I explain that technically, the user could just click a button on a web page, for example, to download and install a card.  She might need to enter a one-time password to make sure the card ended up in the hands of the right person.  And so on.

But now that production web sites are being built that accept InfoCards, we should be able to stop arm-waving and study actual screen shots to see what works best.  We'll be able to contrast and compare real user experiences.

Vittorio Bertocci, a colleague who blogs at vibro.net, is one of the people who has thought about this problem a lot.  He has worked with the giant European Etailer, Otto, on a really slick and powerful smart client that solves the problem.  Otto and Vittorio are really on top of their technology.  It's just a day or two after Vista and they have already deployed their first CardSpace application – using branded Otto cards. 

Here's what they've come up with.  I know there are a whole bunch of screen shots, but bear in mind that this is a “registration” process that only occurs once.  I'll hand it over to Vittorio…

The Otto Store is a smartclient which enables users to browse and experience in a rich way a view of Otto's products catalog.  Those functions are available to everyone who downloads and installs the application (it is in German only, but it is very intuitive and a true pleasure for the eye). The client also allows purchase of products directly from the application: this function, however, is available only for Otto customers. For being able to buy, you need to be registered with http://www.otto.de/.

That said: while buying on http://www.otto.de/ implies using username and password, the new smart client uses Otto managed cards. The client offers a seamless provisioning experience, thanks to which Otto customers can obtain and associate to their account an Otto managed card backed by a self issued card of their choice.
Let's get a closer look through the screens sequence.

Above you see the main screen of the application. You can play with it, I'll leave the sequence for adding items in the shopping cart to your playful explorations (hint: once you're chosen what to buy, you can reach the shopping cart area via the icon on the right end.

Above you see the shopping cart screen. You can check out by pressing the button circled in red.

Now we start talking business! On the left you are offered the chance of transfering the shopping cart to the otto.de web store, where you can finalize the purchase in “traditional” way. If you click the circled button on the right, though, you will be able to do go on with the purchase without leaving the smartclient and securing the whole thing via CardSpace. We click this button.

This screen asks you if you already own an Otto card or if you need to get one. I know what you are thinking: can't the app figure that out on its own? The answer is a resounding NO. The card collection is off limit for everybody but the interactive user: the application HAS to ask. Anyway, we don't have one Otto card yet so the question is immaterial. Let's go ahead and get one. We click on the circled button on the left.

This screen explains to the (German-speaking) user what is CardSpace. It also explains what is going to happen in the provisioning process: the user will choose one of his/her personal card, and the client will give back a newly created Otto managed card. We go ahead by clicking the circled button.

Well, that's end of line for non-Otto customers. This screen allows the user to 1) insert credentials (customer number and birthdate) to prove that they are Otto customers and 2) protect the message containing the above information with a self issued card. This is naturally obtained via my beloved WS-Security and seamless WCF-CardSpace integration. Inserting the credentials and pushing the button in the red circle will start the CardSpace experience:

The first thing you get is the “trust dialog” (I think it has a proper name, but I can't recall it right now). Here you can see that Otto has a Verisign EV certificate, which is great. I definitely believe it deserves my trust, so I'm going ahead and chosing to send my card.

 

Here there's my usual card collection. I'm going to send my “Main Card”: let's see which claims the service requires by clicking “Preview”.

Above you can see details about my self issued card. Specifically, we see that the only claim requested is the PPID. That makes sense: the self issued card will be used for generating the Otto managed card so the PPID comes in handy. Furthermore, it makes sense that no demographic info are requested: those have been acquired already, through a different channel. What we are being requested is almost a bare token, the seond authentication factor that will support our use of our future Otto managed card. Let's click “Send” and perform our ws-secure call.

The call was successful: the credentials were recognized, the token associated to self issued card parsed: as a result, the server generated my very own managed card and sent it back to you. Here's there is something to think about: since this is a rich client application, we can give to the user a seamless provisioning experience. I clicked “Send” in the former step, and I find myself in the Import screen without any intermediate step. How? The bits of the managed card (the famous .CRD file) are sent as a result of the WS call: then the rich client can “launch” it, opening the cardspace import experience (remember, there are NO APIs for accessing the card store: everything must be explicitly decided by the interactive user). What really happens is that the cardspace experience closes (when you hit send) and reopens (when they client receives the new card) without any actions required in the middle. If the same process would have happened in a browser application, this would not be achievable. If the card is generated in a web page, the card bits will probably be supplied as a link to a CRD card: when the user follows the link, it will be prompted by the browser for choosing if he/she wants to save the file or open it. It's a simple choice, but it's still a choice.
Back on the matter at hand: I'm all proud with my brand new Otto card, and I certainly click on “Install” without further ado. The screen changes to a view of my card collection, which I will spare you here, with its new citizen. You can close it and get back to the application.

The application senses that we successfully imported the managed card (another thing that would be harder with web applications). The provisioning phase is over, we won;t have to go through this again when we'll come back to the store in the future.
At this point we can click on the circled button and give to our new Otto Card a test drive: that will finally secure the call that will start the checkout process.

Here's we have my new card collection: as expected, the Otto card is the only card I can use here. Let's preview it:

Here's the set of claims in the Otto card: I have no hard time to admit that apart from “Strasse” and “Kundennummer” I have no idea of what those names mean :).
I may click on “Retrieve” and get the values, but at the time of writing there's no display token support yet: nothing to be worried about in term of functionality, you still get the token that will be used for securing the call: click the circled button for making the token available to WCF for securing the call.
Please note: if you are behind a firewall you may experience some difficulties a this point. If you have problems retrieving the token, try the application from home and that should fix it.

That's it! We used our Otto managed card, the backend recognized us and opened the session: from this moment on we can proceed as usual. Please note that we just authenticated, we didn't make any form of payment yet: the necessary information about that will be gathered in the next steps.
Also note that it was enough to choose the Otto managed card for performing the call, we weren't prompted for further authentication: that is because we backed the Otto card with a personal card that is not password protected. The identity selector was able to use the associated personal card directly, but if it would have been password protected the selector would have prompted the user to enter it before using the managed card.

It definitely takes longer to explain it than to make it. In fact, the experience is incredibly smooth (including the card provisioning!).

Kim, here's some energy for fueling the Identity Big Bang. How about that? 🙂

That's great, Vittorio.  I hear it. 

By the way, Vittorio is a really open person so if you have questions or ideas, contact him.

 

Gabe hits the nail on the head

This post by Gabe Wachob at Digital Identity and Beyond is golden: 

There's been a lot of discussion about the fact that OpenID protocol has a special exposure to phishing/pharming and that the OpenID community needs to address these issues, either technically or through pressure on various parties to address phishing/pharming more broadly. There are a lot of proposals – in particular, we are all waiting to hear from Kim Cameron about OpenID and Cardspace (though applying Cardspace at the OpenID Provider seems like a straightforward solution).

If you ask me, things are happening EXACTLY how I would have wanted and expected them to. Why? Becuase OpenID is a platform for innovation in authentication. People who want to innovate in authentication methods (Mozilla/Firefox, Cardspace, VxVsolutions, etc) do NOT have to be the same people who innovate in offering services on the web (any one of a million folks running mediawiki, drupal, etc). That “delinking” of authentication innovation and service innovation is what is valuable in OpenID.

No, OpenID doesn't solve all problems, and maybe today it only solves a very narrow set of problems with an acceptable risk profile. But to me, thats not the point – its the unleashing of creativity and the power to let developers and architects focus on what they are interested in and good at. Security and identity nuts can focus on authentication and let the social networking, wiki-touting, web 2.0-heads do what they do best! OpenID is an abstraction, a key middle ground for these folks to meet and leverage each other's work – that OpenID is deployed for use in a fairly narrow set of use cases TODAY should not mean that it will not be very important in they very near future…

Very interesting thinking and way to put things.