Mike Jones: self-issued

Musings on Digital Identity

Author: Mike Jones Page 29 of 33

Building the Internet's missing identity layer

Equifax, the Information Card Foundation, and Interoperable Verified Claims

By

On November 16, 2008

In Claims, Information Cards, Interoperability, Windows CardSpace

Equifax Verified Over 18 CardMy congratulations to Equifax for issuing the first commercially deployed Information Cards with verified claims. This is huge step forward towards a future where individuals can routinely make verified digital statements about themselves, facilitating trusted, privacy-preserving interactions online.

I’m writing to bring you some of the story-behind-the-story in Information Card Foundation member Equifax issuing these verified Information Cards. Rather than use proprietary claims schemas in their cards, Equifax chose to use claims that are designed to be interoperable with cards that will be issued by other identity providers. Their cards use a combination of the standard Information Card claims, along with a newly defined age-18-or-over claim that anyone can implement.

This new age-18-or-over claim is the first to emerge from the new Information Card Foundation Identity Schemas Working Group. This is a place where anyone can propose a new claim URI and register it for use by all. You will find the age-18-or-over claim definition in the working group’s Claims Catalog. This is an example of how the Information Card Foundation is facilitating collaboration to advance interoperable Information Cards.

I’ll close by saying that while the Equifax page promotes the new Azigo identity selector, their card uses interoperable protocols and file formats, and is compatible with all identity selectors. For instance, you’ll see a screen shot of my Equifax card in Windows CardSpace below, showing both the use some of the standard Information Card claims, as well as the new age-18-or-over claim from the ICF Claims Catalog.

Equifax Age 18 or Over Card Details

Even More News from the PDC: First Look at the Next Version of CardSpace

By

On October 29, 2008

In Events, Information Cards, Software, Windows CardSpace

CardSpace IconI’m excited that the first beta of the next version of CardSpace — Windows CardSpace “Geneva” — is now available. You can download the bits for this and the other “Geneva” betas at the “Geneva” Connect site. The team posted a detailed introductory piece about the new version on the team blog, so I won’t repeat that here.

This version of CardSpace is a rewrite on a new code base designed to be much smaller, faster, and easier to use. While it’s an early build and far from feature-complete, we nonetheless wanted to get it out now so you can see the directions we’re headed and give us feedback early in the development cycle. This build runs on Windows Vista (32 and 64 bit), Windows Server 2008, and Windows 7.

We’ll be writing more about the key features of CardSpace “Geneva” soon, and as well as the rest of the “Geneva” family that enables claims-aware applications, so watch this space and the team blog. It’s great to now be able to show and discuss the work the team has been doing. I’m looking forward to the ensuing conversation…

More News from the PDC: Beta Releases of “Geneva” Platform Components

By

On October 28, 2008

In Claims, Events, Federation, Information Cards, Software, Windows CardSpace

As just announced on the “Geneva” Team Blog (formerly known as the CardSpace Team Blog), beta releases of all three components of Microsoft’s “Geneva” identity platform are now available at the “Geneva” Connect site. The components are:

  • “Geneva” Framework: Previously called “Zermatt“, the Geneva Framework helps developers build claims-aware .NET applications that externalize user authentication from the application and helps them build custom Security Token Services (STSs). It supports WS-Federation, WS-Trust, and SAML 2.0.
  • “Geneva” Server: Geneva Server is an STS that issues and transforms security tokens and claims, manages user access, and enables easy federation. Based on the “Geneva” framework, it also supports WS-Federation, WS-Trust, and SAML 2.0.
  • Windows CardSpace “Geneva”: CardSpace “Geneva” will be the next version of Windows CardSpace. It has a much smaller download footprint, starts fast, and has some innovative user interface improvements made in response to feedback from the first version.

All are early betas that are works in progress, but I highly encourage those of you who are interested in claims-based identity to download them and let us know what you think. Also, be sure to check out the “Introducing ‘Geneva’” whitepaper by David Chappell.

Next News from the PDC: SAML 2.0 Protocol Support in “Geneva” Server

By

On October 28, 2008

In Events, Federation, Information Cards, Interoperability, Shibboleth, Software, Windows CardSpace

As Don Schmidt wrote this morning, Microsoft’s “Geneva” Identity Server product will support the SAML 2.0 protocol. Specifically, we will be supporting the SAML 2.0 IdP Lite and SP Lite profiles and the US Government GSA profile. Customers had told us that these SAML profiles are important to them and we’re responding to that feedback by implementing them in “Geneva” Server. Those of you who were at Kim Cameron’s “Identity Roadmap for Software + Services” presentation at the PDC got to see Vittorio Bertocci demonstrate SAML federation with “Geneva” Server to a site running IBM’s Tivoli Federated Identity Manager.

The “Geneva” Server is the successor to Active Directory Federation Services (ADFS). It will, of course, interoperate with existing ADFS and other federation implementations using the WS-Federation protocol. In addition, it adds WS-Trust support for issuing Information Cards, letting it work with Windows CardSpace and other Identity Selectors.

I’ll add that the SAML 2.0 support doesn’t stop with the server. SAML 2.0 is also supported by the “Geneva” Identity Framework — a .NET application development framework formerly known as “Zermatt” and “IDFX”, which likewise also supports WS-Federation and WS-Trust. In short, the same identity development framework components that are being used to build “Geneva” Server will be available to all .NET developers as the “Geneva” Identity Framework.

Finally, I’ll close by thanking the folks on the Internet 2 Shibboleth project, IBM, and Ping Identity who helped us with early interop testing of our code. You have been valuable and responsive partners in this effort, helping us make sure that what we’re building truly interoperates with other SAML 2.0 implementations deployed in the wild.

First News from the PDC: Windows LiveID Becoming an OpenID Provider

By

On October 27, 2008

In Events, LiveID, OpenID

Today at the Microsoft Professional Developer Conference (PDC), the Windows LiveID team announced that anyone with a LiveID will soon be able to establish an OpenID for their LiveID. Furthermore, they have established a testing environment where you can try out LiveID’s OpenID support and an e-mail address for you to provide feedback to the team.

One feature of the OpenID 2.0 implementation that I’d like to call your attention to is that they give users a choice, on a per-relying party basis, whether to use a site-specific OpenID URL at the site for privacy reasons, or whether to use a public identifier for yourself — explicitly enabling correlation of your identity interactions on different sites. Here’s what that experience looks like in the preview release:

LiveID OpenID choice

Read more about the preview release here.

PAPE Specification Entering Public Review Period

By

On October 22, 2008

In OpenID, Phishing Resistance, Specifications

OpenID logoThe OpenID Provider Authentication Policy Extension (PAPE) specification enables an OpenID Relying Party to request that the OpenID Provider satisfy a set of policies specified by the RP when the OP logs the user in. And it likewise enables the OP to reply to the RP saying which of the policies it satisfied.

One of these policies lets the RP request that the OP perform phishing-resistant authentication, the need for which has been discussed here and elsewhere. Another capability I’m a fan of is the ability for the RP to “freshness date” the login, requiring that the OP actively authenticate the user if the current authentication was performed longer ago than an RP-specified number of seconds.

The PAPE Working Group just recommended that the OpenID Foundation members approve the current draft (Draft 7) as an OpenID specification. Today starts a 60 day review period required as part of the OpenID specification process, which occurs prior to an approval vote by the members. PAPE is the first new specification to be produced under this process, and I’m pleased as an OpenID board member to report we now have an existence proof that the process works (or more precisely, we will once this specification is approved).

There are already four implementations of this spec in existence and even better, there are public testing endpoints for these implementations where you can kick the tires. You can try the DotNetOpenId and JanRain implementations at these sites:

You should also be able to test the relying parties with signon.com and myopenid.com, which currently implement earlier drafts, since the authentication policy syntax didn’t change.

This spec was a collaborative effort among a number of people. David Recordon wrote the initial drafts last year, with input from the people thanked in Draft 2. Since then, Nat Sakimura was responsible for the generalization of the authentication levels to enable levels other than just those defined by NIST be used. Ben Laurie was an ardent and practical security advocate (as always). Allen Tom was a proponent of the strong “level 0” description. Andrew Arnott of the DotNetOpenId project shared his experiences building an independent implementation with the working group, helping improve the specification. And John Bradley was a never-ending source of common sense, although he would deny it to your face if asked.

Online Identity Theft and Digital Playgrounds Whitepapers

By

On October 12, 2008

In Information Cards, Privacy, Safety

I wanted to bring your attention to two whitepapers covering important Internet identity topics that were published by members of Microsoft’s Trustworthy Computing and Privacy teams, both announced on the blog The Data Privacy Imperative.

The first is “Online Identity Theft: Changing the Game — Protecting Personal Information on the Internet” by Jules Cohen, Brendon Lynch, and other members of Microsoft’s Trustworthy Computing team. Per the announcement, the paper:

… for the first time describes in detail Microsoft’s comprehensive strategy for curbing online identity theft. In addition to describing current Microsoft initiatives, the paper outlines long-term solutions for “changing the game” by ending reliance on “shared secrets” for authentication.

Relying on “shared secrets,” such as usernames, passwords, birthdates and government ID numbers to establish the right to do something online, creates security problems because they are relatively easy to steal and can be difficult to remember, update and manage. We need to employ new identity practices online that are just as reliable but better protect against fraud and abuse, and that’s where Information Cards come in …

The paper has been greeted by favorable reviews, including an Information Week article that also describes the role that the Information Card Foundation can play and a NetworkWorld article by Dave Kearns that concludes “Download this important paper, read it, then act on it.”

The second is “Digital Playgrounds: Creating Safer Online Environments for Children” by Jules Cohen of Microsoft’s Trustworthy Computing team and Chuck Cosson, Policy Counsel on privacy and safety issues, with some input from me. The paper was presented to the Internet Safety Technical Task Force (ISTTF) by Jules and submitted by Microsoft as input to the task force. As Jules wrote about the approach:

The Digital Playgrounds paper outlines a framework that would enable the creation of optional online “walled gardens,” specifically for children and trusted adults. These online sites would only be accessible by folks with trusted and age verified ‘digital identities.’ This framework suggests achieving this by allowing trusted offline parties, who have the ability to meet with a parent and child in real life, examine the appropriate documents and then issue extremely secure digital identities based on these in in-person proofing moments. The framework we have outlined is largely a technical solution to the age verification challenge, but we believe that the nontechnical aspects of the problem will be as difficult to solve as the technical ones, if not more so. For example, government and industry will need to work together on designing the necessary criteria for in-person proofing events as well as the subsequent issuing, auditing and revoking of these digital identity cards.

I especially encourage people to consider the possibility that existing offline identity proofing ceremonies might be leveraged to enhance safety online as well.

I’m going to the Internet Identity Workshop

By

On October 5, 2008

In Events

iiw2008bIt’s more than a conference or meeting. It’s the place where people building the Internet’s identity layer collaborate and get things done.

Hope to see you there: November 10-12, Mountain View, CA. Register now!

Information Card Standardization Work Commencing

By

On September 26, 2008

In Information Cards, Interoperability, Specifications

OASIS logoI’m looking forward to participating in the new OASIS Identity Metasystem Interoperability Technical Committee (IMI TC) starting next week, which will produce an Information Card standard. As I told John Fontana of Network World earlier this week after the OASIS announcement of the IMI TC, this work is coming at a logical time.

Information Card IconThe industry has been working together on building and testing interoperable Information Card software for the past two years through the OSIS Interops. The breadth of participation and the level of interop achieved between the participants are a testament to the maturity both of the Identity Selector Interoperability Profile specification, which will be a primary input to the standardization work, and of the numerous implementations of interoperable Information Card software. I’m also pleased that the features and tests from the most recent OSIS Interop will be one of the inputs informing the standardization work, enabling the committee to benefit from the experiences that implementers have gained by seeing how their software actually interoperates with others’ solutions.

As a personal note, I haven’t been involved in standards work since I was a technical editor of the POSIX Threads standard in the late ’80s and early ’90s (eventually published as PASC 1003.1c-1995 and ISO/IEC 9945-1:1996). I’ll be curious to see how the OASIS process is like and unlike the POSIX process from nearly two decades ago. Also on a personal level, I’ll say that the committee is a great collection of individuals, and I’m really looking forward to working with them to produce an identity standard of significant long-term value.

Also, be sure to see the comprehensive posting on Cover Pages about the IMI TC, which is chock full of useful information and references. Looking forward to seeing some of you in London!

New Information Card Foundation Members from Around the World

By

On September 23, 2008

In Information Cards

Intel logoDeutsche Telekom logoI wanted to bring your attention to a press release about seven new members who have joined the Information Card Foundation from around the world. The new members are Deutsche Telekom of Germany, CryptoPro of Russia, Eduserv of the United Kingdom, ETRI of South Korea, Figlo of the Netherlands, Intel of the United States, and WISeKey of Switzerland. I’m particularly excited to welcome Deutsche Telekom and Intel as new board members. It’s great to see the range of companies and individuals who are coming together to help bring the benefits of Information Cards to their markets and spheres of influence.

PPID Compatibility Note for Sites Accepting Self-Issued Information Cards

By

On August 27, 2008

In Documentation, Information Cards, Interoperability, Windows CardSpace

Information Card IconRelying Parties often identify subjects using the Private Personal Identifier (PPID) claim and Signing Key values sent by an Information Card. Thus, it is important that the PPID and Signing Key values produced by a card be stable and long-lived.

Unfortunately, the PPIDs and Signing Keys generated by self-issued (a.k.a. personal) Information Cards using the algorithm originally shipped with Windows CardSpace (and documented in ISIP V1.0) for sites using regular certificates were not stable under several important conditions. Therefore, after considering industry feedback on the long-term problems that this continued instability would cause, and in consultation with other Identity Selector authors, a decision was made to change these algorithms in a way that will provide much better long-term stability of these important Subject identifiers for Relying Parties. The new algorithm is documented in the Identity Selector Interoperability Profile (ISIP) V1.5.

This change shipped with the version of Windows CardSpace in the .NET Framework 3.5 Service Pack 1. This service pack will be installed by Windows Update on systems with the .NET Framework 2.0, 3.0, and 3.5 in the coming months. I know that the Bandit and Higgins projects have implemented the new algorithm as well.

Unfortunately, this change means that the PPIDs and Signing Keys for self-issued cards used at existing Relying Parties that employ standard SSL certificates will change after this installation.

What Sites Need to Do

Sites need to ensure that they have tested mechanisms in place to enable their users to re-associate their Information Card with their account when the card’s PPID and Signing Key change. The good news is that these mechanisms are likely already in place in the form of “lost card” handling procedures.

When the card is used after the update, it will appear to be an unrecognized card. Just as sites’ lost card procedures can be used today to associate a new Information Card with their account, these same procedures can be used to re-associate the existing card with the account after these changes.

These lost card procedures will typically involve sending the user a message at the e-mail address of record for the account. This message contains a link that enables them to associate an Information Card with their account. This flow is nearly identical to the “lost password” flows often found on sites. Best practices for lost card handling are documented in the “Enabling Information Card Recovery” section of Patterns for Supporting Information Cards at Web Sites: Personal Cards for Sign up and Signing In.

Additional Steps Sites Could Take

In the short term, sites could also choose to add text to their Information Card login pages warning users that their existing cards will not be recognized as being associated with their accounts after the .NET update, and directing them to use the “lost card” feature of the site to remedy this situation.

EV and no-SSL Sites Not Affected

None of this affects sites using Extended Validation (EV) certificates or sites not using SSL certificates. These algorithms were already stable and have not changed. No action is required in these cases.

Background on the Problem

Because the original PPID and Signing Key algorithms used the entire certificate chain, these values could change under several circumstances:

  • First, as sites renew their certificates, it is common for the certificate chain for the new cert to differ from the old one. This would change the PPID, breaking the user’s self-issued cards at those sites. And of course, the chain always changes if the site changes its certificate provider.
  • Second, because the algorithm for converting the bytes of the chain certificates into characters was not fully specified by ISIP V1.0 for some OIDs, for some kinds of certificates, different Identity Selectors produced different results for the PPID claim, Signing Key, Client Pseudonym PPID, and IP Identifier values.
  • Finally, in ISIP V1.0, the PPID for a site using a non-EV certificate is different than the PPID for a site that uses an EV certificate, even in the case where the non-EV leaf cert content meets the EV issuance criteria. This means that when a site upgraded to using an EV certificate, user’s cards would stop working at that site.

Overview of the Solution

To address these issues, the computation of the PPID and Signing Key for sites using regular certificates has been changed to no longer include information from the certificate chain, but only information from the leaf certificate. This will provide stability both when certificates are renewed and when a certificate is obtained from a new issuer.

Furthermore, the new algorithm generates the same PPID values for sites using EV and non-EV certificates with the same leaf certificate information, while generating different Signing Keys. This will help enable a smooth migration path for sites upgrading from non-EV to EV certificates because the PPID remaining the same can be used as evidence that the same card is being used before and after the certificate upgrade.

More about the specifics of the algorithm change can be found in Section 8.6.1 of ISIP V1.5 and additional guidance and commentary can be found in the corresponding section of the ISIP V1.5 Guide.

WS-Addressing Identity Extension Published

By

On August 27, 2008

In Documentation, Information Cards, Interoperability, Specifications, Windows CardSpace

Information Card IconIBM and Microsoft just published the specification “Application Note: Web Services Addressing Endpoint References and Identity” at http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/. This specification is referenced by the Identity Selector Interoperability Profile (ISIP) and is covered by Microsoft’s Open Specification Promise (OSP). This completes the publication and licensing under the OSP of all specifications that Information Cards based upon the ISIP depend upon.

Note: While ISIP 1.5 references the addressing identity extension using a date of July 2008, it was actually published in August. This is an erratum in the ISIP that resulted from the publication of the extension taking longer than anticipated — not a reference to a different document. Both consistently use the URL http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/.

Analysis of the Third OSIS User-Centric Identity Interop

By

On August 23, 2008

In Information Cards, Interoperability, OpenID

OSIS logoCongratulations and thanks to Pamela Dingle for publishing a detailed analysis of what that the industry accomplished together during the Third OSIS User-Centric Identity Interop (I3). As Nulli Secundus writes about the paper:

The OSIS I3 Interop was a five-month event in which organizations, individuals, and projects working in the solution spaces of Information Cards and OpenID collaborated to define and demonstrate their ability to transact successfully regardless of differences in hardware or software platform. Participants worked within each solution space to define and test acceptable behaviors for various situations that crop up when loosely coupled solutions communicate with each other via open protocols. Interop participants created results within two different matrices: feature test results which recorded adherence to acceptable behavior when explicitly tested, and cross-solution results which recorded overall interoperability between solutions with complimentary roles. Combined, the participants recorded over 1200 mostly successful results.

As new solutions enter this space and existing solutions add to their feature sets, the OSIS Interop process and results serve as a metric to inform developers what features will contribute to a consistent experience for users and administrators. OSIS Interops have served as a focal point for discussion and feature concentration and a forcing function to solidify the protocols. Overall, much was accomplished but there is still work to be done. By examining participation, contribution to best practices, process and collaboration, discoveries, and obstacles, the Interop process can be refined and improved to give even more value to those involved; by doing so, diversity in product offerings will not result in difficulty for end users.

Many of the learnings and conclusions that Pamela has captured in the paper have informed the Fourth OSIS User-Centric Identity Interop (I4), which is under way and builds on the accomplishments of I3 and the previous interops. Check out the paper and if you have an implementation of Information Card or OpenID software, the time is now to participate in I4!

Identity Selector Interoperability Profile V1.5

By

On August 11, 2008

In Documentation, Information Cards, Interoperability, Specifications, Windows CardSpace

Information Card IconI am pleased to announce the publication of the Identity Selector Interoperability Profile V1.5 and companion guides. The ISIP (as it’s come to be called) documents the protocols and data formats used by Windows CardSpace so as to enable others to build compatible Information Card software.

Version 1.0 of these documents corresponded to the.NET Framework 3.0 version of CardSpace. Version 1.5 corresponds to CardSpace as of .NET Framework 3.5 Service Pack 1. Like the previous version, ISIP 1.5 is licensed under Microsoft’s Open Specification Promise.

Significant new content covers:

  • Relying Parties without SSL certificates
  • Use of WS-Trust 1.3 and WS-SecurityPolicy 1.2
  • Relying Party STSs
  • More stable PPID algorithm
  • Specifications for computing ic:IssuerId and ic:IssuerName
  • Token references by Identity Providers via wst:RequestedAttachedReference and wst:RequestedUnattachedReference elements
  • Custom issuer information in cards
  • Custom error messages
  • Clarification that an ic:MasterKey is required for managed cards
  • Plus numerous of clarifications that were found by others building Information Card software — especially during the OSIS interops

The three new document versions are:

Thanks to the literally dozens of you who provided comments on ways to improve the ISIP and companion docs and who reviewed drafts of this material. This version of the docs benefited substantially from your detailed knowledge of and experience with the previous spec gained through implementing interoperable Information Card software.

Finally, I’d like to thank the members of the CardSpace team who diligently documented many of these features on the CardSpace Team Blog in advance of their publication under the ISIP. Your work let the industry gain early experience with implementing these features and was a tremendous resource to me as I was producing these versions of the documents.

Digital Identity Podcast for MySuccessGateway

By

On July 4, 2008

In Claims, Information Cards, Interoperability, OpenID, Phishing Resistance, Privacy, Windows CardSpace

MicrophoneKim Cameron and I recorded a podcast on digital identity for MySuccessGateway this week at the invitation of Jim Peake of SpeechRep Consulting. Jim was a gracious, informed, and enthusiastic host during our conversation, which covered a wide range of digital identity topics including identity theft, shared secrets, privacy, Information Cards and the Information Card Foundation, the value of verified claims, business models for identity providers, password fatigue, defeating phishing attacks, OpenID, why interoperability is essential and the interoperability testing the industry is doing together to make it a reality, some of the identity products that are shipping and forthcoming, and the Laws of Identity. He even asked us how we felt about Bill Gates’ retirement, as a kicker.

If that sounds interesting to you, give it a listen…

CardSpace Consumer Website

By

On July 3, 2008

In Documentation, Information Cards, Windows CardSpace

Windows logoMicrosoft recently created a Consumer Website for CardSpace to educate end-users about Windows CardSpace and Information Cards. This complements the developer-focused information at the MSDN CardSpace site and the CardSpace Community Site.

No, it’s not the kind of content targeted at regular readers of this blog — especially the short video — but then, that’s kind of the point. :-)

First Verified Age Information Cards

By

On June 28, 2008

In Claims, Information Cards, Windows CardSpace

IDology Verified Over 18 cardLast week IDology demonstrated a first that many of us see great possibilities for: an Information Card making a verified age claim. I’m excited at this first step towards the goal of enabling people to routinely use interoperable verified claims about themselves via Information Cards.

Obtaining my age-verified card online was easy. I submitted my name, address, and birth date (via a self-issued card) to IDology’s verification process. Next they asked me a few additional questions to confirm that I was likely to be the person who I claimed to be. With correct answers in hand, they proceeded to issue me an Information Card enabling me to make IDology-verified claims on my own behalf.

I used the card at two (demo) relying parties: a social networking site that restricts membership to people 18 and over and an online wine store. You can also imagine verified identity information being valuable at job and career sites, at dating sites, when applying for insurance or credit, for enrolling in promotions, etc. The possibilities are endless.

Please join me in congratulating IDology on this significant achievement. I believe it will be the first of many good things to come in the verified identity space!

The remainder of this post shows the process of obtaining and using my verified identity Information Card. In some cases I intentionally went through extra steps, such as previewing the cards before sending them, to make it completely clear what is occurring. The address of the demo site is obscured at IDology’s request because this is not yet a production service. Some of the (real) data about me used to obtain the card is obscured for privacy reasons.

Signing Up for a Verified Age Card

SocialNet start page

The experience starts by visiting the “SocialNet” site, which invites me to join. I click “Join SocialNet Today”.

SocialNet join page

SocialNet lets me join either by typing my information into a web form or by providing it via an Information Card. I click the Information Card icon.

SocialNet join card selection

This brings up CardSpace, where I choose a self-issued card with my home address.

SocialNet join card preview

I preview the card, seeing that the site will be sent my name, address, and birth date. I click “Send”.

SocialNet verification questions

I’m asked two questions that I should know the answers to to help confirm that I am who I say I am. I answer them correctly.

SocialNet joined

Having passed the identity verification process, I’m given the opportunity to download an Information Card for my newly verified identity. I click on “Download Managed InfoCard”.

Install IDology card

I click the “Install and Exit” button to install my verified identity Information Card.

Using the Card at SocialNet

SocialNet login page

Now that I have a verified age card, I use it to sign in at SocialNet by clicking on the Information Card icon.

SocialNet login card selection

I choose my IDology verified Information Card and click “Preview” to review the claims I’m being asked for.

SocialNet login card preview

SocialNet is only asking for my name and the PPID for my card. I send them.

SocialNet logged in

I’m logged into SocialNet using my verified Information Card.

Using the Card at OnlineWineMerchant.com

OnlineWineMerchant login page

Now I go to another site that accepts my verified age Information Card: “OnlineWineMerchant.com”. I click the Information Card icon to sign in.

OnlineWineMerchant login card selection

My IDology verified Information Card is accepted by the site. I choose it and click “Preview”.

OnlineWineMerchant login card preview

OnlineWineMerchant.com is also only asking for my name and a PPID. (In a real deployment, I suspect it would be asking for an age claim of some kind too.) I send the card.

OnlineWineMerchant logged in

I’m logged into OnlineWineMerchant.com using my verified age card, letting me take advantage of the verification I did for SocialNet on this site too. This is the synergy that will make Information Cards with verified identity claims a valuable addition to the identity landscape.

A Personal Perspective on the Information Card Foundation Launch

By

On June 24, 2008

In Bandit Project, Higgins Project, Information Cards, Interoperability, Pamela Project, People, Phishing Resistance, Windows CardSpace

Information Card Foundation banner

In May 2005, when I wrote the whitepaper “Microsoft’s Vision for an Identity Metasystem“, these sentences were aspirational:

Microsoft’s implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.

Non-Microsoft applications will have the same ability to use "InfoCard" to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

Now they are present-day reality.

This didn’t happen overnight and it wasn’t easy. Indeed, despite it being hard, the identity industry saw it as vitally important, and made it happen through concerted, cooperative effort. Key steps along the way included the Laws of Identity, the Berkman Center Identity Workshops in 2005 and 2006, the Internet Identity Workshops, the establishment of OSIS, the formation of the Higgins, Bandit, OpenSSO, xmldap, and Pamela projects, publication of the Identity Selector Interoperability Profile, the Open Specification Promise, the OSIS user-centric identity interops (I1 rehearsal, I1, I2, I3, and the current I4), the OpenID anti-phishing collaboration, the Information Card icon, and of course numerous software releases by individuals and companies for all major development platforms, including releases by Sun, CA, and IBM.

Of course, despite all the groundwork that’s been laid and the cooperation that’s been established, the fun is really just beginning. What most excites me about the group of companies that have come together around Information Cards is that many of them are potential deployers of Information Cards, rather than just being producers of the underlying software.

The Internet is still missing a much-needed ubiquitous identity layer. The good news is that the broad industry collaboration that has emerged around Information Cards and the visual Information Card metaphor is a key enabler for building it, together in partnership with other key technologies and organizations.

The members of the Information Card Foundation (and many others also working with us) share this vision from the conclusion of the whitepaper:

We believe that many of the dangers, complications, annoyances, and uncertainties of today’s online experiences can be a thing of the past. Widespread deployment of the identity metasystem has the potential to solve many of these problems, benefiting everyone and accelerating the long-term growth of connectivity by making the online world safer, more trustworthy, and easier to use.

In that spirit, please join me in welcoming all of these companies and individuals to the Information Card Foundation: founding corporate board members Equifax, Google, Microsoft, Novell, Oracle, and PayPal; founding individual board members Kim Cameron, Pamela Dingle, Patrick Harding, Andrew Hodgkinson, Ben Laurie, Axel Nennker, Drummond Reed, Mary Ruddy, and Paul Trevithick; launch members Arcot Systems, Aristotle, A.T.E. Software, BackgroundChecks.com, CORISECIO, FuGen Solutions, Fun Communications, Gemalto, IDology, IPcommerce, ooTao, Parity Communications, Ping Identity, Privo, Wave Systems, and WSO2; associate members Fraunhofer Institute and Liberty Alliance; individual members Daniel Bartholomew and Sid Sidner.

Identity Choice at HealthVault

By

On June 23, 2008

In Information Cards, LiveID, OpenID, Phishing Resistance

OpenID logoSean Nolan, chief architect of Microsoft’s HealthVault service, posted an article about giving their users choice for the identities they use to access their information. He announced that in addition to accepting LiveIDs, HealthVault is about to start accepting OpenIDs from two OpenID Providers and is also building native Information Card support. As Sean wrote:

As we’ve always said, HealthVault is about consumer control — empowering individuals with tools that let them choose how to share and safeguard their personal health information. OpenID support is a natural fit for this approach, because it allows users to choose the “locksmith” that they are most comfortable with.

You can certainly expect to see more such options in the future. For example, we are in the process of building in native support for Information Cards, which provide some unique advantages, in particular around foiling phishing attempts.

Talking about OpenID, Sean also wrote:

As we learn more, and as OpenID continues to mature, we fully expect to broaden the set of providers that work with HealthVault. We believe that a critical part of that expansion is the formalization and adoption of PAPE, which gives relying parties a richer set of tools to determine if they are comfortable with the policies of an identity provider.

Please join me in congratulating the HealthVault team on being the first Microsoft service to employ OpenID and for their commitment to providing their users convenient, secure access to their healthcare data.

Even Phishers Have Their Problems

By

On May 26, 2008

In OpenID, Phishing Resistance

While gone phishing, I discovered that the use of JavaScript puts one barrier up that phishers have to overcome to impersonate a legitimate site. In a characteristically hilarious post, Paul Madsen points out that, besides having to overcome active defenses like Sxipper (“Down girl!”), phishers may also inadvertently present pages localized for their locale, rather than the victim’s.

Intrepid identity adventurer though Paul may be, this stopped him dead in his tracks:

Deutsche Blogger login

Of course, maybe Paul’s German was better than he thought, as the page was urging him to “Gehen Sie auf Nummer sicher! Schützen Sie sich von Phishing und Identitätsdiebstahl.” — “Go safe! Protect yourself from phishing and identity theft.” :-)

Page 29 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén