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?