Category: Windows CardSpace

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 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress, 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 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ we discussed a strawman proposal of rooting the corresponding verified version under http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/. For instance, the URI for a verified street address claim would be http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/streetaddress.

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 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/verified/givenname a response might be:

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

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:

<verified>
  <value type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">Michael</value>
  <who type="http://www.w3.org/2001/XMLSchema#string">Acme Data Provider</who>
  <when type="http://www.ietf.org/rfc/rfc3339.txt">2007-05-14T16:30:00Z</when>
</verified>

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, BackgroundChecks.com
Pat Mangiacotti, BackgroundChecks.com
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!