Scott Kveton on CardSpace and OpenID

Many of the people adding OpenID support to their blogs and services are using JanRain's libraries.  Scott, the company's CEO, addresses the worry some members of his community may have about a big, powerful company getting involved with the bottoms-up technology they have worked on so hard.  I actually have  a lot of sympathy for this concern, and for peoples’ feelings about the technology they have developed.  If we were coming to “take over”, it would really be bad news for everyone.  But Scott Kveton, Dick Hardt, Michael Graves and myself aren't the kind of people who would let this happen.

What I really like about Scott's comments is the way he focusses, without any bias, on what is good about the component technologies and their synergy.  This is what real engineering is about, in my humble opinion.  It's one of the things that will really drive us towards the Identity Big Bang.  And the whole world will benefit.

OpenID has always been about convergence. When Brad, David and Johannes talked about how OpenID and Yadis could work together over a year ago. When the XRI folks brought their amazing people and technology to be integrated into OpenID 2.0 last Spring. This past Summer when Sxip Identity joined the OpenID party by joining in on developing the specification and offering up their attribute exchange specification to the OpenID community. And now today, we have a commitment from Microsoft to take part in the OpenID community as well as enable the technology for their future identity products.

There are a couple of points I’d like to make outside of the above announcement to hopefully address any concerns that the OpenID community might have:

  • JanRain will never require users of our libraries or services to use Windows CardSpace â„¢. We offer support for this technology as another option for users much like using our Safe SignIn and Personal Icon technologies on MyOpenID.com. We’ll also continue to support the OpenID efforts going on with Mozilla and Firefox.
  • Windows CardSpace â„¢ is shipping with Vista today and is a well thought-out technology that helps address many of the privacy and security concerns that people have had with OpenID. OpenID helps users describe their identity across many sites in a public fashion. The two together are very complimentary products and each has its strength.
  • Microsoft did not cave in to the OpenID community and the OpenID community is giving nothing up to Microsoft. This is a collaboration on bringing the best technology to the marketplace as quickly as possible to help secure users and solve the single sign-on solution once and for all.
  • Please reserve judgment on what this all means until you see it all work together. The technology is really quite simple and the ramifications for end-users is huge. It also goes a very long way to completely addressing the phishing concerns we’ve heard so much about.

Dick Hardt on CardSpace and OpenID

Here is Dick Hardt, CEO of SXIP, explaining our joint announcement on OpenID and CardSpace to people in the community who may worry that Starship Microsoft is about to land on OpenID and squish it. 

This morning Microsoft announced they would support OpenID in future identity server products. Although this is a huge endorsement for OpenID, there will likely be many people that are fearful of what Microsoft’s involvement may do to OpenID.

At ActiveState I worked with Microsoft to bring Perl and Python technology to the Windows platform. This was a win for Perl and Python programmers that wanted to use their tools on the Windows platform. It was also a win for the community at large, as a fair amount of the threading and Unicode support that is in Perl today was funded by Microsoft. Just as I bridged the Microsoft and Open Source worlds back in the 90s,

I look forward to bridging the Microsoft and OpenID worlds today. The team at Microsoft get what we are doing in OpenID, and want to enable their technology to take advantage of the reach of OpenID, as well as enable the OpenID community to take advantage of CardSpace technology. This looks like a win-win for everybody.

Dick's previous Perl work really is a good example of what came about when we “defactionalized” our industry and got momentum going.  The “identity gang” phenomenon has been a good example of the same thing since day one, and this concrete announcement takes things in an even more positive direction.

Let me say something about potential squishing. It just won't happen.  One of the best things about OpenID is its organic quality, and the last thing we want to do is interfere with that.  

My big ask was to add a way to request credentials based on phishing-resistant authentication.  The main idea was to ensure the system is built to handle the dangers that would come with its own success.  As it is more widely adopted, and used for more purposes, OpenID credentials will inevitably become a “honeypot”.  But through the collaboration going on here, and other similar initiatives, we can make sure we'll have the means in place to protect our users even before they are in danger. This in turn is key to preventing a loss of confidence in identity systems and the internet in general.

In the early 1980’s, James Martin said, “Every successful system will attract usage to the point that it becomes unsuccessful”.  He was referring to systems that gobbled up mainframe resources by attracting users until they became bogged down and unusable, but over the years I've thought of his maxim in many contexts.  I think one outcome of today's announcement will be to provide an exception, and that's worth celebrating.

 

CardSpace / OpenID Collaboration Announcement

As an outcome of the discussions that have been taking place here in the Blogosphere – and in-person meetings – it is exciting to convey the following joint announcement by JanRain, SXIP Identity, VeriSign and Microsoft:

JanRain, Microsoft, Sxip, and VeriSign will collaborate on interoperability between OpenID and Windows CardSpaceâ„¢ to make the Internet safer and easier to use. Specifically:

  • As part of OpenID’s security architecture, OpenID will be extended to allow relying parties to explicitly request and be informed of the use of phishing-resistant credentials.
  • Microsoft recognizes the growth of the OpenID community and believes OpenID plays a significant role in the Internet identity infrastructure.  Kim Cameron, Chief Architect of Identity at Microsoft, will work with the OpenID community on authentication and anti-phishing.
  • JanRain, Sxip, and VeriSign recognize that Information Cards provide significant anti-phishing, privacy, and convenience benefits to users.  Information Cards, based on the open WS-Trust standard, are available though Windows CardSpaceâ„¢.
  • JanRain and Sxip, leading providers of open source code libraries for blogging and web sites, are announcing they will add support for the Information Cards to their OpenID code bases.
  • JanRain, Sxip and VeriSign plan to add Information Card support to future identity solutions.
  • Microsoft plans to support OpenID in future Identity server products
  • The four companies have agreed to work together on a “Using Information Cards with OpenID” profile that will make it possible for other developers and service providers to take advantage of these technology advancements.

Dick Hardt, Sxip Identity
Kim Cameron, Microsoft
Michael Graves, VeriSign
Scott Kveton, JanRain
 

 

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.

 

I-names and CardSpace

Here are some smart comments by =Andy.Dale of ooTao on how Information Card identity selectors like CardSpace and Higgins should work with XDI and i-names.  Andy has played an important role in introducing OpenID to ISPs and his comments bear directly on the convergence theme we've been discussing:

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports… All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb… I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify ‘Joe’; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted ‘this is my i-name’ should NOT be trusted); presumably XDI.org could publish that list.

So in summary… I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

By the way, I've been using my =Kim.Cameron i-name for a couple of years now – ever since I started this blog.  It has been a life-saver.  It has been my email conduit to my readers and allowed me to interact personally with many people all over the world – without ONE piece of spam.  

So I would be a fool not to be a big supporter.  And more broadly, I'm a fan of =Drummond.Reed‘s thinking about identifiers.  He and his associates have thought more deeply about what identifiers need to be than anyone else in the world.

 

New InfoCard Profile documents available

Arun Nanda, Mike Jones, and others both at Microsoft and Ping have been working very hard for a long time now to make sure the profile we used to build our prototypes, and then our product, was being fully shared with everyone else who wanted to interoperate.  This has also involved an ongoing attempt to make sure the profile was clear enough to be useful.

Today I'm posting new versions that I think are a lot clearer (let me know!)  First, here is A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0.  I think anyone adding InfoCards to their site will find this document useful.

In addition I'm putting up two documents intended for people who really want to get into the details of how to implement the underlying toolkits and platforms.  Don't feel compelled to read them if you aren't doing this type of work!  They are part of the process of working with our colleagues in OSIS, Higgins, etc – those building Identity Selectors and the system software that powers managed card providers and claims transformers.  The papers will also be of interest to academics and people who really like to get way down into how things work.   You should begin with A Guide to Interoperating with the Infomation Card Profile V1.0.  I'll post the second document (the normative technical reference) in a couple of days.

I'm beginning by putting these docs up here so everyone in the identity community can get access to them ASAP.  Ultimately, they will appear in many other places, including MSDN.

 

Ping will show OpenID / CardSpace integration

According to this post, Ashish Jain at Ping has a new prototype of how CardSpace / OpenID integration will work in their evolving product.  It seems to be a continuation of the work they've already done with SAML / CardSpace integration – only now, the OpenID protocol has been added to the metasystem mix.

Come to think of it, isn't Dick Hardt's Whobar pretty close to having this capability as well?  So I think a number of us have wanted to integrate this work for some time, but recently it has become more obvious what the advantages are.

Anyway, if you haven't read Ashish's piece:

Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it.

CardSpace OpenID Integration

In short, I agree. In fact, if you want to see a demo of what Kim describes, please stop by Ping Identity’s booth next week at the RSA Conference and you will get to see exactly that. An OpenID IdP Server that uses CardSpace for runtime authentication.

It’s not done by any means. There are still some unresolved items. For instance, If the user already has a profile registered with the OP, at runtime should the server use the persisted attributes or the claims as provided by the card? And the support for multiple cards. But you will get the idea.

I still have a few questions though. AFAIK OpenID Authentication 2.0 considers authentication out of scope.. So….to prevent phishing and to build user’s confidence, I can use CardSpace. Or anything on the likes of PassMark’s mutual auth. To provide more confidence to the RP, I can use OTP, device finger printing, biometric, certificates, KBA whatever. However there doesn’t seem to be the SAML AuthnContext equivalent to convey this to the RP. Therefore RP has no way to determine the type of OP authentication or if the authentication ever happened.

Even if there is way to communicate the authentication type, there is no trust or relationship between the OP and the RP. So….RP (who as a service provider has everything to loose) has no reason to believe that the OP isn’t lying and may have to employ their own safety measures.

I’m still coming up the curve so I may be wrong, but something seems missing. I’ll keep looking.

Ashish makes an interesting point about conveying the authentication type in the protocol.  I certainly agree with him.

I also like his question about trust.  It's one others have asked and which I scratched my head about at first.  So I'll put in my two cents worth.

In all identity protocols, you have an authority that makes claims about a subject, and the relying party decides whether or not to believe them.  As computer nerds we have called that “trust”, though in real business environments it's usually more a matter of reducing risk to the point that, on balance, it's better to do a transaction than not to do it.

But what is “the trust” (risk analysis) based on?  Usually on business relationships.  For example, we trust a bank to make assertions of various sorts.  And we trust a partner or customer to make other assertions.  So the trust is rooted in our experience – in a relationship.

This is where OpenID does something different: the authority is simply the behavior of the internet, and the trust only pertains to an identifier (one could layer other capabilities on top of this).

Basic Tenets

  1. Every person has a URL to which they lay claim.
  2. Every URL has an identity provider that “speaks for” it.

When I go to a relying party I tell it which URL I claim.  Then it sends me to the identity provider that speaks for that URL to get a token saying I really control it.

I give that token to the relying party, which then contacts the identity provider to verify the token is valid (the actual protocol includes optimizations).

To believe the claim, the Relying Party (RP) needs to trust that the URL has not been tampered with (an evil party could alter it to say an evil identity provider speaks for it).  The RP also has to believe it really contacted the URL when finding out who spoke for it (I could have been misdirected through a DNS attack).  And it needs to believe it really contacted the identity provider when getting token validation (again trusting DNS).  The last two issues can be mitigated by using https, but that complicates it, and even then, the system has different characteristics than one based on cryptographic tokens.

All in all, the closest analogy is to using an email address as an identifier by asking what email address you own, sending you the email, and getting you to click a link showing you own the email.  In this case the relying party depends on the underlying mail system, DNS, and all that.  OpenID replaces email with web URLs.  So it's a lot more direct.

Proving control 

How does an identity service know you really control some URL?  Many approaches are possible.  Let me give the example of Yahoo's system (it's not OpenID but uses the same general idea). You log into their identity provider and it gives you a key (a couple of lines or random gook).  You must then paste the key into your html page and press a button back at Yahoo.  This causes their system to open your page and see if the key is there. If so, the service deems that you own the URL.  Having done this you can get rid of the key and the Yahoo identity provider is willing to “speak for” your control of the URL.  The whole process just takes five minutes.

 

Drummond Reed on CardSpace and OpenID

Amongst other things, Drummond is CTO of Cordance and co-chair of the OASIS XRI and XDI Technical Committees.  He's playing an important role in getting new identity ideas into the Internet Service Provider world.  Here he responds to my first convergence post:

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.

I'm going to clone myself so I can find more time to write up my second proposal.  Meanwhile, just a small clarification.  Drummond talks about the “default CardSpace schema”.  He's really talking about the “default Self-Issued Card schema.” 

CardSpace itself handles tokens of any type, containing claims of any type.  There are no limitations on your schema if you create a managed card.  I'll make that clearer in my next post. 

Further, we tried to keep the “bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology.  But one of those initial claims is a URL…  I thought an i-name or i-numbers would be able to go there.  Is more needed?