Musings on Digital Identity

Month: May 2007

Hands-On Information Card Interop at IIW

On Tuesday afternoon at IIW representatives from numerous Information Card projects sat down at the same table (actually, 3 tables so we would all fit :-) ) and systematically used our implementations together, exercising the different possible combinations. The session notes, as posted on the OSIS wiki, tell the story:

Notes from IIW 2007a

The OSIS group sponsored an Information Card interoperability connect-a-thon on May 15, 2007 as part of the Internet Identity Workshop 2007 A in Mountain View California. Participants collaborated to work through combinations of Identity Provider, Identity Agent, and Relying Party scenarios, in order to identify and workshop problems with interoperability. The following representatives were present and participated:

5 Information Card Selectors

  • Ian Brown’s Safari Plugin
  • Windows Cardspace
  • Higgins IdA Native
  • Higgins IdA Java

11 Relying Parties

  • Bandit (basic wiki authentcation)
  • Bandit (elevated privileges)
  • PamelaWare
  • CA
  • Windows Live RP (used to obtain a managed card)
  • Windows Live/single-issuer (where you can use the managed card)
  • Oracle RP
  • Identityblog RP (based on Rob Richards’ library)
  • Identityblog helloworld token RP
  • UW/Shibboleth

7 Identity Providers

  • Higgins
  • Bandit
  • UW/Shibboleth
  • LiveLabs
  • HumanPresent
  • Identityblog HelloWorld IdP

4 Token Types

  • SAML 1.0
  • SAML 1.1
  • helloworld
  • username token

2 Authentication Mechanisms

  • username/password
  • self-issued (personal) card

Many combinations interoperated as expected; several issues were identified and are being fixed in preparation for the coming Information Card Interop event to be held at the Burton Group Catalyst Conference in San Francisco (June 25-29).

One of the things I love about IIW is that it’s a working meeting — not a series of mind-numbing presentations. This interop was a great example of the industry coming together and doing work together. And of course, this session was a dry run for the upcoming User-Centric Identity Interop event coming at Catalyst next month, where even more projects will be represented. Hope to see many of you there!

Open Source Information Card Relying Party Software Projects

Today at the Interop Conference in Las Vegas, Bob Muglia announced Microsoft’s sponsorship of four open source projects that are producing Information Card Relying Party software for important web programming environments: Ruby on Rails, Java, PHP, and C. The press release, which also talks about extending the Open Specification Promise to the Information Card Specifications, contains supportive quotations from several friends in the identity community: Paul Trevithick and Mary Ruddy, Tony Nadalin, Dale Olds, and Gerry Gebel.

Details on the Ruby and Java projects were announced, with details on the PHP and C projects to follow. See these sites for details:

Ruby on Rails Relying Party:

Java Relying Party:

Shibboleth Supporting Information Cards

Today Internet2 announced that it is adding Information Card support to Shibboleth. This will enable the millions of members of the academic and research communities with identities provided by Shibboleth software to use those identities under user control through Information Cards at sites where they are accepted. Microsoft is a sponsor of this work, just as it sponsored the earlier Internet2 work to add WS-Federation support to Shibboleth.

I had the pleasure of test driving an early version of this software running at the University of Washington during IIW last week during the user-centric interop session there on Tuesday afternoon, courtesy of RL “Bob” Morgan. Very cool!

Interoperable Verified Identity Claims

Monday morning before the Internet Identity Workshop people representing both providers of verified identity attributes and some of the key Information Card software projects met to talk about interoperable ways of exchanging verified identity claims via Information Cards. Verified claims are made by third party identity provider on your behalf, and have been validated in some fashion by the identity provider.

For instance, while I might claim that my street address is 123 Main Street, a statement by an authoritative data source on my behalf that they have verified that my address is 123 Main Street is substantially more valuable and may be required by relying parties for some purposes.

While the statement “I have verified the subject’s address as being 123 Main Street” is expressible in innumerable ways, the participants expressed a shared interest in expressing it the same way. That way Information Cards making this statement by different identity providers will interoperate, giving relying parties a choice of verified identity providers, which is good for everyone. The high-order bit coming out of this discussion is that we all agreed to agree.

The primary problem we tackled together was how to represent verified versions of the claims expressible in self-issued Information Cards like Name, Address, E-mail address, Gender, Date of Birth, etc. The constraints on the solution we agreed to were:

  • Compatibility with self-issued cards: Cards capable of issuing verified claims should also be accepted by relying parties willing to accept unverified versions of these claims.
  • Verification of individual claims: It should be possible to issue tokens in which some claims are verified and others are not.
  • Compatibility with CardSpace V1: The method for expressing verified identity claims should be usable from the first release of Windows CardSpace, as well as other compatible identity selectors such as the Higgins and Bandit selectors.

The solution we whiteboarded out together has the following properties:

  • Identity providers should advertise the ability to provide claims corresponding to the standard self-issued set under the standard schema URIs for self-issued cards, such as, even if a verified form of the claim is available. This satisfies the “compatibility with self-issued cards” requirement.
  • Identity providers will use a SAML 1.0 token for expressing verified identity claims intended to be compatible with self-issued information cards.
  • Identity providers will use common URIs for advertising and providing the verified versions of the claims in the self-issued claims schema. For the verified versions of the claims rooted at we discussed a strawman proposal of rooting the corresponding verified version under For instance, the URI for a verified street address claim would be

Of course, agreeing to common URIs for advertising and requesting verified claims is only the first step. Interoperability also requires that the structure of the verified claim values be compatible.

Verified claims, as currently issued by data providers through existing channels, are structured records containing both the data values as well as statements about the data. When provided via Information Cards, this will still be true.

Guided by input from the participating data providers, we whiteboarded the following proposal for how to structure these values:

  • Each verified claim value will be represented as a standard XML structure with a required subfield, optional standard subfields, and optional extension subfields that can be defined by identity providers.
  • The required subfield is the “value” field, providing the verified value of the claim.
  • Optional interoperable subfields discussed were:
    • who: What party verified the claim.
    • how: How the claim was verified.
    • when: When the claim was verified.
    • expires: When the verification should be treated as having expired.
    • supplied: The value supplied as input to the verification, which may differ from the “value” field. For instance, while the verified value of my given name might be “Michael”, the supplied value might be “Mike”.

For example, in response to a relying party’s request for the claim a response might be:

  <who>Acme Data Provider</who>

Of course, defining fields like these begs the question “what data types do these fields use?” In response, a proposal was made to consider making this explicit by allowing (or requiring) that a type URI be provided for each such element, thus making the fields self-describing.

One possibility is to add a “type” attribute to these fields to provide this information. Here’s an example illustrating this approach:

  <value type="">Michael</value>
  <who type="">Acme Data Provider</who>
  <when type="">2007-05-14T16:30:00Z</when>

Beyond the self-issued claim types
Of course, the vast majority of verified claims will not correspond to the self-issued card claim types. Many will be specific to particular application domains. There was agreement that wherever possible, existing schemas should be used. For instance, in the employment space, HR-XML schemas might be utilized.

Another issue raised was that some kinds of verified claims will themselves be complex data structures, such as “employment history”, “education”, or “professional certifications”. While the display token value for these claims should try to communicate something of value, such as an indication of the most recent job or degree, it was recognized that the person may have to go directly to the identity provider to view these claims in full detail.

Next Steps
It is our hope that this discussion will lead to experts defining precise representations for these and other useful interoperable claims. The parties involved in these discussions all want to see this happen soon so that identity providers and relying parties can start to take advantage of interoperable verified claims through Information Cards as soon as possible.

Caveats and Closing
The examples above are illustrative, not normative. They’re intended to document the discussion we had and provoke further discussion. I’m sure there are numerous ways that they can be improved and useful approaches that we didn’t even think of. Please join in!

Discussion participants were:

John Cartin,
Pat Mangiacotti,
Tony Nadalin, IBM / Higgins Project
Dieter Sommer, IBM / Higgins Project / Idemix
John Dancu, IDology
Mike Jones, Microsoft / CardSpace
Andy Hodgkinson, Novell / Bandit Project / Higgins Project
Paul Antoniades, ooTao
Barry Beechinor, ooTao
Andy Dale, ooTao
Mary Ruddy, Social Physics / Higgins Project
Dick Hardt, Sxip Identity
Brian Hernacki, Symantec
Bill Johnson, Symantec
David Recordon, VeriSign
Andrew Jaquith, Yankee Group

Thanks all for a lively and productive discussion!

Updated versions of Information Card profile documents published

New versions of three Information Card documents are now available:

These documents are intended for people building software that plays any of the roles in the Information Card ecosystem: Identity Providers to issue cards, Relying Parties to accept cards, and Identity Selectors to put the person in control by enabling them to employ Information Cards when and where they choose. They include the specifications necessary to move Information Cards from one Identity Selector implementation to another, enabling card portability. And they’re also for those of you who just want to look under the hood and understand how it all works…

Along with these updated documents also comes updated licensing. We recently completed the technical and legal review of the normative specifications that enabled us to bring them under Microsoft’s Open Specification Promise. While this had been in the queue since the beginning, sometimes good things take time and come in stages. Once we had a complete, highly reviewed (and community reviewed) version of the interoperability specifications, that enabled us to complete this licensing work as well.

Thanks to all of you who reviewed earlier versions of these docs and especially those of you who built software based upon them. These documents greatly benefited from the substantial community feedback we received.

A footnote for those of you who have used earlier drafts of these documents… The “Identity Selector Interoperability Profile V1.0” was formerly known as “A Technical Reference to the Information Card Profile V1.0”; “An Implementer’s Guide to the Identity Selector Interoperability Profile V1.0” was formerly known as “A Guide to Interoperating with the Information Card Profile V1.0”; “A Guide to Using the Identity Selector Interoperability Profile V1.0 within Web Applications and Browsers” was formerly known as “A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0”.

Don Schmidt’s Insights on Federation

Don Schmidt just wrote a set of thoughtful and informative posts on federation on the occasion of today’s publication of WS-Federation 1.1 by OASIS. They are:

I highly recommend them! Welcome to the blogosphere Don!

Powered by WordPress & Theme by Anders Norén