CardSpace OpenID Integration – I

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 had 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.

11 Responses to “CardSpace OpenID Integration – I”

  1. January 24, 2007 05:15 AM 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.

  2. ConnectID says:

    For this to work, OpenID providers need to support Cardspace self-asserted cards (thus the commitment from OpenID vendors to add Cardspace) so that the OPs can bridge between the two worlds. Ping already demonstrates this working (importantly, as Ashish points out, if Cardspace authentication is going to be of value to an OpenID RP, there will need be mechanisms in OpenID to differentiate such an authentication from a lesser form.

  3. Arbitrage says:

    Andre Durand Ashish Jain Bryan-Field Elliot Conor Cahill Coty Rosenblath Craig Burton Doc Searls Eric Norlin James Kobielus Jamie Lewis Kim Cameron Pam Dingle Paul Madsen Thomas P.M. Barnett

  4. For this to work, OpenID providers need to support Cardspace self-asserted cards (thus the commitment from OpenID vendors to add Cardspace) so that the OPs can bridge between the two worlds. Ping already demonstrates this working (importantly, as Ashish points out, if Cardspace authentication is going to be of value to an OpenID RP, there will need be mechanisms in OpenID to differentiate such an authentication from a lesser form.

  5. iTickr – Identity Ticker » Blog Archive » CardSpace OpenID Integration – I

  6. [...] 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. [...]

  7. Mark Wahl says:

    “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.”

    Yes, IF the RP doesn’t have any reason to trust of the OP (IdP) then the best the RP’ll know from this authentication is that some user X is able to manipulate some URL resource Y. If Y is not under the control of RP (which it probably isn’t, more likely Y is hosted by X’s IdP or some other hosting service), then this statement isn’t too useful other than to demonstrate that X is an arbitrary Internet user.
    If the risk to the RP is that some of the RP’s hosted blogs may get spam comments, then this may be sufficient. If the risk to the RP is greater and the RP has “something to lose”, then the RP may indeed either want to get more information about X (such as a credit card number) directly from X or in the profile obtained from the OP, or have a way of maintaining a trust relationship with a set of OPs.

  8. [...] 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. read the rest here [...]

  9. [...] Ping will show OpenID to CardSpace integration http://www.identityblog.com/?p=662 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 *** 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. 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 Every person has a URL to which they lay claim. 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. Published Monday, February 05, 2007 7:29 PM by Microsoft Filed Under: News, Strategic Partnerships [...]

  10. [...] There’s been a lot of news the past couple of days around the announcement of a collaboration agreement between OpenID role players (JanRain, SXIP Identity, VeriSign) and Microsoft’s Windows CardSpace on the use of Windows CardSpace with the OpenID 2.0 specification. (OpenID is an open, decentralized, free framework for user-centric digital identity. See the section below for a short overview on how it works) [...]

Leave a Reply

Image | WordPress Themes