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:
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).
- 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.
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.