Identity.xsd reloaded

I was wondering why the identity xml schema was not updated after the release of ISIP 1.5...

Here is my (unautorized) edit. Any xml that validates against the old schema should by valid against this new schema (but not the other way around). Well, I changed the namespace from http://schemas.xmlsoap.org/ws/2005/05/identity/ to http://schemas.xmlsoap.org/ws/2008/08/identity/:

<?xml version="1.0" encoding="utf-8"?>
<!-- 
Copyright © 2006-2007 Microsoft Corporation, Inc. All rights reserved. 
Edited for Identity Selector Interoperability Profile V1.5 by Axel Nennker. Some rights reversed. [sic!]
-->

<xs:schema targetNamespace="http://schemas.xmlsoap.org/ws/2008/08/identity"
    xmlns:tns="http://schemas.xmlsoap.org/ws/2008/08/identity" 
    xmlns:wsa="http://www.w3.org/2005/08/addressing" 
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    
    elementFormDefault="qualified" blockDefault="#all" 

    version="0.1" >

  <xs:import 
      namespace="http://www.w3.org/2001/04/xmlenc#" 
      schemaLocation="http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd"/>
  <xs:import 
      namespace="http://www.w3.org/2005/08/addressing" 
      schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/>
  <xs:import 
      namespace="http://schemas.xmlsoap.org/ws/2004/09/policy" 
      schemaLocation="http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd" /> 
  <xs:import 
      namespace="http://schemas.xmlsoap.org/ws/2005/02/trust" 
      schemaLocation="http://schemas.xmlsoap.org/ws/2005/02/trust/ws-trust.xsd" />
  <xs:import
      namespace="http://www.w3.org/2000/09/xmldsig#"
      schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
  <xs:import
      namespace="http://www.w3.org/XML/1998/namespace"
      schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  
  <!-- Standard claim types defined by the InformationCard model -->

  <xs:simpleType name="StringMaxLength255MinLength1">
    <xs:restriction base="xs:string">
      <xs:maxLength value="255"/>
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="StringMaxLength64MinLength1">
    <xs:restriction base="xs:string">
      <xs:maxLength value="64"/>
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="StringMaxLength684">
    <xs:restriction base="xs:string">
      <xs:maxLength value="684"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize1MB">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="1048576"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize16K">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="16384"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="Base64BinaryMaxSize1K">
    <xs:restriction base="xs:base64Binary">
      <xs:maxLength value="1024"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="PositiveUnsignedInt">
    <xs:restriction base="xs:unsignedInt">
      <xs:minInclusive value="1"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:complexType name="AttributedEmptyElement">
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="DisplayCredentialHint" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="Username" type="tns:StringMaxLength255MinLength1" />

  <xs:element name="PrivatePersonalIdentifier" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="IsSelfIssued" type="xs:boolean" />
  <xs:element name="MasterKey" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="PinDigest" type="tns:Base64BinaryMaxSize1K" />

  <xs:element name="HashSalt" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="IssuerId" type="tns:Base64BinaryMaxSize16K" />
  <xs:element name="BackgroundColor" type="xs:int" />
  <xs:element name="CardName" type="tns:StringMaxLength255MinLength1" />

  <xs:element name="Issuer" type="xs:anyURI" />
  <xs:element name="IssuerName" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="TimeIssued" type="xs:dateTime" />
  <xs:element name="TimeExpires" type="xs:dateTime" />

  <xs:element name="TimeLastUpdated" type="xs:dateTime" />
  <xs:element name="StoreSalt" type="tns:Base64BinaryMaxSize1K" />
  <xs:element name="EntryName" type="tns:StringMaxLength64MinLength1" />
  <xs:element name="EntryValue" type="tns:StringMaxLength684" />

  <xs:simpleType name="LogoImageType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="image/jpeg"/>
      <xs:enumeration value="image/gif"/>
      <xs:enumeration value="image/bmp" />
      <xs:enumeration value="image/png" />
      <xs:enumeration value="image/tiff" />
    </xs:restriction>
  </xs:simpleType>
  
  <xs:complexType name="BaseClaimType" abstract="true">
    <xs:attribute name="Uri" type="xs:anyURI" use="required" />
  </xs:complexType>

  <xs:element name="ClaimType" type="tns:ClaimType" />
  <xs:complexType name="ClaimType">
    <xs:complexContent>
      <xs:extension base="tns:BaseClaimType">
        <xs:attribute name="Optional" type="xs:boolean" />
        <xs:anyAttribute namespace="##other" processContents="lax" />
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="SupportedClaimType" type="tns:SupportedClaimType" />
  <xs:complexType name="SupportedClaimType">
     <xs:complexContent>
       <xs:extension base="tns:BaseClaimType">
         <xs:sequence>
          <xs:element name="DisplayTag" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
          <xs:element name="Description" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
        </xs:sequence>
        <xs:anyAttribute namespace="##other" processContents="lax" />

      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="InformationCardReference" type="tns:InformationCardReferenceType" />
  <xs:complexType name="InformationCardReferenceType">
    <xs:sequence>
      <xs:element name="CardId" type="xs:anyURI" />
      <xs:element name="CardVersion" type="tns:PositiveUnsignedInt"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="CardImage" type="tns:CardImageType" />

  <xs:complexType name="CardImageType">
    <xs:simpleContent>
      <xs:extension base="tns:Base64BinaryMaxSize1MB">
        <xs:attribute name="MimeType" type="tns:LogoImageType" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="UsernamePasswordCredential" type="tns:UsernamePasswordCredentialType" />
  <xs:complexType name="UsernamePasswordCredentialType">
    <xs:sequence>
      <xs:element ref="tns:Username" minOccurs="0"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="KerberosV5Credential" type="tns:AttributedEmptyElement" />

  <xs:element name="X509V3Credential" type="tns:X509V3CredentialType" />
  <xs:complexType name="X509V3CredentialType">

    <xs:sequence>
      <xs:element ref="ds:X509Data"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="SelfIssuedCredential" type="tns:SelfIssuedCredentialType" />
  <xs:complexType name="SelfIssuedCredentialType">

    <xs:sequence>
      <xs:element ref="tns:PrivatePersonalIdentifier"/>
    </xs:sequence>
  </xs:complexType>
  
  <xs:element name="UserCredential" type="tns:UserCredentialType" />
  <xs:complexType name="UserCredentialType">

    <xs:sequence>
      <xs:element ref="tns:DisplayCredentialHint" minOccurs="0" />
      <xs:choice>
        <xs:element ref="tns:UsernamePasswordCredential" />
        <xs:element ref="tns:KerberosV5Credential" />

        <xs:element ref="tns:X509V3Credential" />
        <xs:element ref="tns:SelfIssuedCredential" />
        <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax" />
      </xs:choice>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="IssuerInformationEntry" type="tns:IssuerInformationEntryType" />
  <xs:complexType name="IssuerInformationEntryType">
    <xs:sequence>
      <xs:element ref="tns:EntryName" />
      <xs:element ref="tns:EntryValue" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="IssuerInformation" type="tns:IssuerInformationType" />
  <xs:complexType name="IssuerInformationType">

    <xs:sequence>
      <xs:element ref="tns:IssuerInformationEntry" minOccures="1" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="TokenService" type="tns:TokenServiceType" />

  <xs:complexType name="TokenServiceType">
    <xs:sequence>
      <xs:element ref="wsa:EndpointReference" />
      <xs:element ref="tns:UserCredential"/>
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax" />

  </xs:complexType>

  <xs:element name="TokenServiceList" type="tns:TokenServiceListType" />
  <xs:complexType name="TokenServiceListType">
    <xs:sequence>
      <xs:element ref="tns:TokenService" maxOccurs="128"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="SupportedTokenTypeList" type="tns:SupportedTokenTypeListType" />
  <xs:complexType name="SupportedTokenTypeListType">
    <xs:sequence>
      <xs:element ref="wst:TokenType" maxOccurs="32"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="SupportedClaimTypeList" type="tns:SupportedClaimTypeListType" />
  <xs:complexType name="SupportedClaimTypeListType">
    <xs:sequence>
      <xs:element ref="tns:SupportedClaimType" maxOccurs="128"/>

    </xs:sequence>
  </xs:complexType>

  <xs:element name="RequireAppliesTo" type="tns:RequireAppliesToType" />
  <xs:complexType name="RequireAppliesToType">
    <xs:attribute name="Optional" type="xs:boolean" />

  </xs:complexType>
  
  <xs:element name="RequestDisplayToken">
    <xs:complexType>
      <xs:attribute ref="xml:lang" use="optional" />
      <xs:anyAttribute namespace="##other" processContents="lax" />

    </xs:complexType>
  </xs:element>
  
  <xs:element name="DisplayClaim" type="tns:DisplayClaimType" />
  <xs:complexType name="DisplayClaimType">
    <xs:complexContent>
      <xs:extension base="tns:SupportedClaimType">

        <xs:sequence>
          <xs:element name="DisplayValue" type="tns:StringMaxLength255MinLength1" minOccurs="0" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

   <xs:simpleType name="DisplayTokenTextContentType">
     <xs:restriction base="xs:token">
      <xs:enumeration value="text/plain" />
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="DisplayTokenText" type="tns:DisplayTokenTextType" />

  <xs:complexType name="DisplayTokenTextType">
    <xs:simpleContent>
      <xs:extension base="tns:StringMaxLength255MinLength1">
        <xs:attribute name="MimeType" type="tns:DisplayTokenTextContentType" use="required" />
        <xs:anyAttribute namespace="##other" processContents="lax" />

      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="DisplayToken" type="tns:DisplayTokenType" />
  <xs:complexType name="DisplayTokenType">
    <xs:choice>

      <xs:element ref="tns:DisplayClaim" maxOccurs="unbounded" />
      <xs:element ref="tns:DisplayTokenText" />
    </xs:choice>
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="RequestedDisplayToken" type="tns:RequestedDisplayTokenType" />
  <xs:complexType name="RequestedDisplayTokenType">
    <xs:sequence>
      <xs:element ref="tns:DisplayToken" />
    </xs:sequence>

    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>

  <xs:element name="RequireStrongRecipientIdentity" type="tns:PolicyAssertionType" />
  <xs:element name="RequireFederatedIdentityProvisioning" type="tns:PolicyAssertionType" />

  <xs:complexType name="PolicyAssertionType">
    <xs:sequence>
      <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax" />
    </xs:sequence>
    <xs:anyAttribute namespace="##any" processContents="lax" />

  </xs:complexType>
  
  <xs:element name="PrivacyNotice" type="tns:PrivacyNoticeLocationType" />
  <xs:complexType name="PrivacyNoticeLocationType">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="Version" use="optional" type="tns:PositiveUnsignedInt"/>

        <xs:anyAttribute namespace="##any" processContents="lax" />
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:element name="ClaimValue" type="tns:ClaimValueType" />

  <xs:complexType name="ClaimValueType">
    <xs:complexContent>
      <xs:extension base="tns:BaseClaimType">
        <xs:sequence>
          <xs:element name="Value" type="tns:StringMaxLength684" />
        </xs:sequence>

      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="ClaimValueList" type="tns:ClaimValueListType" />
  <xs:complexType name="ClaimValueListType">
    <xs:sequence>

      <xs:element ref="tns:ClaimValue" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="InformationCard" type="tns:InformationCardType" />
  <xs:complexType name="InformationCardType">

    <xs:sequence>
      <xs:element ref="tns:InformationCardReference" />
      <xs:element ref="tns:CardName" minOccurs="0" />
      <xs:element ref="tns:CardImage" minOccurs="0" />
      <xs:element ref="tns:Issuer" />

      <xs:element ref="tns:TimeIssued" />
      <xs:element ref="tns:TimeExpires" minOccurs="0" />
      <xs:element ref="tns:TokenServiceList" minOccurs="0"/>
      <xs:element ref="tns:SupportedTokenTypeList" />

      <xs:element ref="tns:SupportedClaimTypeList" />
      <xs:element ref="tns:RequireAppliesTo" minOccurs="0" />
      <xs:element ref="tns:PrivacyNotice" minOccurs="0" />
      <xs:element ref="tns:RequireStrongRecipientIdentity" minOccurs="0" />
      <xs:element ref="tns:IssuerInformation" minOccurs="0" maxOccurs="unbounded" />
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute ref="xml:lang" use="required"/>

  </xs:complexType>

  <xs:element name="InformationCardMetaData" type="tns:InformationCardMetaDataType" />
  <xs:complexType name="InformationCardMetaDataType">
    <xs:complexContent>
      <xs:extension base="tns:InformationCardType">
        <xs:sequence>

          <xs:element ref="tns:IsSelfIssued" />
          <xs:element ref="tns:PinDigest" minOccurs="0"/>
          <xs:element ref="tns:HashSalt" />
          <xs:element ref="tns:TimeLastUpdated" />
          <xs:element ref="tns:IssuerId" />

          <xs:element ref="tns:IssuerName" />
          <xs:element ref="tns:BackgroundColor" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="InformationCardPrivateData" type="tns:InformationCardPrivateDataType" />
  <xs:complexType name="InformationCardPrivateDataType">
    <xs:sequence>
      <xs:element ref="tns:MasterKey" />
      <xs:element ref="tns:ClaimValueList" minOccurs="0" />

    </xs:sequence>
  </xs:complexType>

  <xs:element name="RoamingInformationCard" type="tns:RoamingInformationCardType" />
  <xs:complexType name="RoamingInformationCardType">
    <xs:sequence>
      <xs:element ref="tns:InformationCardMetaData" />

      <xs:element ref="tns:InformationCardPrivateData" minOccurs="0" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="RoamingStore" type="tns:RoamingStoreType" />
  <xs:complexType name="RoamingStoreType">

    <xs:sequence>
      <xs:element ref="tns:RoamingInformationCard" minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="EncryptedStore" type="tns:EncryptedStoreType" />

  <xs:complexType name="EncryptedStoreType">
    <xs:sequence>
      <xs:element ref="tns:StoreSalt" />
      <xs:element ref="enc:EncryptedData" />
    </xs:sequence>
  </xs:complexType>

  
</xs:schema>

Information Cards: More Subtleties

Another post in my new series (1,2) of posts related to things you never wanted to know about Information Cards:

• Why does the infocard.xsd define PositiveUnsignedInt when there is a XML standard positiveInteger already defined? Maybe I am missing a suble difference?
• Did you notice that the length of a claim's value is restricted to be less or equal than 684 in length?
  
  <xs:complexType name="ClaimValueType">
    <xs:complexContent>
     <xs:extension base="tns:BaseClaimType">
      <xs:sequence>
      <xs:element name="Value" type="tns:StringMaxLength684"/>
     </xs:sequence>
    </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  I am very interested to here the story who came up with this number and why (My guess is that a Windows UI component restricts the length...). People who suggest to store whole customer profiles in claims should be aware of this restriction.
• Did you know that the username/password credential hint is limited to 64 characters in length?! This makes Pamela's invalid Information Card (I4-badidp1.crd) even more invalid.

Information Cards: Redundant Information

public InformationCardMetaData(InfoCard card) {
 super(card);
 this.isSelfIssued = org.xmldap.infocard.Constants.ISSUER_XMLSOAP.equals(card.getIssuer());
}

InformationCardMetaData is an extension of InfoCard in the XML schema definition and in the corresponding XMLDAP classes.
The information in the InformationCardMetaData that the card is self-issued is derived from the Information Card.

Why is this so? Redundant data always leads to trouble.

I suggest that we remove isSelfIssued from the InformationCardMetaData structure in the schema definition.

xmldap.org is down

xmldap.org has lost its hosting. The startup that provided the space etc shut down and there is currently no replacement. Sorry.

Laws of Identity (in German)

• "People using computers should be in control of giving out information about themselves, just as they are in the physical world."
  Menschen, die Computer benutzen, sollten, genauso wie in der physischen Welt, die Kontrolle über die Daten besitzen, die sie über sich herausgeben.
  - I would strike the "just as they are in the physical world".
  People should be in control of their information.
• "The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necessary."
  Nur die Daten, die für einen bestimmten Zweck notwendig sind, sollten herausgegeben werden. Wenn der Zweck erfüllt ist, sollten die Daten gelöscht werden.
• "It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences."
  Es sollte nicht möglich sein unsere Internetnutzung automatisch zu Profilen zu verbinden. Ein eindeutiges Identitifikationsmerkmal, das zur Profilbildung eingesetzt werden könnte, hat viele unerwünschte Folgen.
• "We need choice in terms of who provides our identity information in different contexts."
  Wir benötigen Auswahlmöglichkeiten darin wer unsere Identitätsinformationen in verschiedenen Kontexten zur Verfügung stellt.
  This sounds cumbersome... I would phrase this like this: We need competition between providers that manage our data. If one providers is not worth our trust then we should cancel that service immediately.
• "The system must be built so we can understand how it works, make rational decisions and protect ourselves."Das System muss so gebaut sein, dass wir verstehen können, wie es funktioniert und dass wir rationale Entscheidungen treffen können und dass wir uns schützen können.
  I think that understanding the system is not necessary. We need "trust" in the system. It should help us to make rational decisions and it should help us to protect us against making bad decisions.
• "Devices through which we employ identity should offer people the same kinds of identity controls - just as car makers offer similar controls so we can all drive safely."
  Geräte, denen wir Identitätsinformationen anvertrauen, sollten Sicherheitseigenschaften besitzen, die uns schützen, genauso wie ein Auto Sicherheitseigenschaften besitzt, die uns allen erlauben, sicher zu fahren.
  This is no literal translation. I exchanged "Eigenschaften" (properties) for controls (Maßnahmen / Kontrollen)

Links:
Informational Self-Determination
German Federal Data Protection Act §§31,39 and $6b(5)

Privacy in the Silly Season

In Germany there are currently lots of news stories about private data beeing stolen / misused. It started with a set of 17000 that contained information about lottery customers. Next a data protection commissioner bought a CD with information about 6 million people where 4 million dates contained bank account information. There where several thousand cases where money in the range from 50 to 100 Euro was withdrawn from bank accounts. The latest news: a call center with access to the Deutsche Telekom database abused its access rights to steal data. The number of illegal accesses and of stolen data is unknown...

Well, now politicians - you never heard of - voice their concerns and demand stronger punishment and a data protection office demands that the selling of personal identifiable data must be prohibited by law... The government has decided to wait for the investigation to be finished.

It is good that all this is in the news every hour. But we have to wait what actually changes when the politicians and people are back from vacation.

In relation to these stories I try to translate Kim's laymen's laws of identity: Laws of Identity (in German)

Information Card Subtleties

From ISIP 1.5:

<ic:InformationCardMetaData>
[Information Card]
<ic:IsSelfIssued> xs:boolean </ic:IsSelfIssued>
<ic:PinDigest> xs:base64Binary </ic:PinDigest> ?
<ic:HashSalt> xs:base64Binary </ic:HashSalt>
<ic:TimeLastUpdated> xs:dateTime </ic:TimeLastUpdated>
<ic:IssuerId> xs:base64Binary </ic:IssuerId>
<ic:IssuerName> xs:string </ic:IssuerName>
<ic:BackgroundColor> xs:int </ic:BackgroundColor>
</ic:InformationCardMetaData>

.../ic:InformationCardMetaData/ic:IsSelfIssued This required element indicates if the card is self-issued (“true”) or not (“false”).

.../ic:InformationCardMetaData/ic:IssuerId This required element contains an identifier for the Identity Provider with which a self-issued credential descriptor in a card issued by that Identity Provider can be resolved to the correct self-issued card. The element content may be empty.

The ic:IssuerId value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically:

• Compute IP Identifier in the same manner as RP Identifier in Section 8.6.1, except that the certificate from ds:KeyInfo is used, rather than the Relying Party‟s.

Use the IP Identifier as the ic:IssuerId value. The ic:IssuerId value SHOULD be the empty string for self-issued cards.

.../ic:InformationCardMetaData/ic:IssuerName This required element contains a friendly name of the card issuer.

The ic:IssuerName value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider. Specifically, if the certificate from ds:KeyInfo is an extended validation (EV) certificate [EV Cert], then set ic:IssuerName to the Organization Name (O) field value from the certificate, otherwise set ic:IssuerName to the Common Name (CN) field value from the certificate.

ISIP 1.5 does not state what the value for IssuerName is in the case when IsSelfIssued == true. I think it SHOULD be empty too like IssuerId when IsSelfIssued == true.
[update: Just saw that the XML schema defines IssuerName to be of the type "StringMaxLength64MinLength1". It can not be empty. I suggest that we do away with this "required element should be empty if..."-stuff and define IssuerId and IssuerName to be optional. Or better: We should move IssuerId into the definition "SelfIssuedCredentialType" as it is needed only for this authentication type.
For IssuerName I suggest that we move this element into the Information Card type "InformationCardType" and define it to be not-there for self-issued cards and non-empty for managed cards. The issuer should have the right to choose its name. Deriving it from the cert imposes unneeded restrictions on the issuer. The card is signed and after I verified/validated and accepted the card from that issuer I should accept its choosing for IssuerName.]

IssuerId and IssuerName are defined in the section of ISIP 1.5 titled: "7. Information Cards Transfer Format" and subsection "7.1. Pre-Encryption Transfer Format"; that is: They are needed/computed when a card is exported? This does not make sense. I assume that they are computed when the .crd file is imported.
The XML in the .crd file is signed and the ds:KeyInfo from the signature contains the certificate that is used to sign the XML.
What if the ds:KeyInfo from the signature contains no ds:X509Certificate?

Question: Is there a connection between ic:IssuerId and ic:IssuerName from the ic:InformationCardMetaData and ic:Issuer from ic:InformationCard?
Answer: No. The ic:Issuer from ic:Information card is an URI and is the logical name of the issuer. Potential RPs and Issuers must agree on this logical name because it is used to determine a matching card when the RPs asks for a specific issuer in the HTML object tag.

If the RP limits the accepted tokens to those issued by issuer="urn:flabergasted" then there is no intuitive way to find an STS that issues these tokens. Should the issuer from the HTML object tag be the same as the ic:IssuerName? Probably.

So, what is the use of IssuerId and IssuerName? IssuerName is used to present it to the user when the managed card is displayed to the user. IssuerId is used to find the self-issued card when the managed card is backed by a self-issued card. If the UserCredential is has no ic:SelfIssuedCredential child then IssuerId is not needed.

-----
What if the issuer uses another certificate to sign the issued managed Information Card than for its SSL connection? Is this a "legal" scenario?

XKCD measures and controls

There should be controls in place that the Anti-Virus SW is not interfering with the voting SW.
There should be controls in place that there are no holes in the AV-SW that lets Viruses slip through.
The voting machines should be regularly checked that they were not harmed by the AV-SW.

Now for the analogy...

As a parent I don't like the analogy...

ooTao: Wish I could help

I just read the post by Andy Dale of the end of ooTao as we know it...

I have met Andy several times and always found that he is one who knows what he is talking about. He is an expert but as it seems not an expert in selling "identity".
Having been through this 1,5 times as an employee myself I think I know how he and his colleagues at ooTao feel.

If you are an employer: Don't miss this opportunity to secure this knowledge for your company.

New York Times on Passwords and Alternatives

There is a new article by Randall Stross in the New York Times titled "Goodbye, Passwords. You Aren’t a Good Defense".

I am thankful for this article and I think that we need more of them. It is targeted at a readership that is no expert in security and privacy; and never will be. It informs its readers that there are problems with passwords and that openid (yet?) isn't the solution either. I think that with Information Cards we are moving in the right direction. True, we are not there yet, but major players by forming the Information Card Foundation have decided to jointly work on a accepted and interoperable solution.

Microsoft is doing the right thing to put their implementation of the card selector, CardSpace, into Windows Vista. And to improve it again and again; and put this major component for Internet security outside the long Windows and .NET update cycles; and to support alternative implementations of the identity selector and the other components of the Identity Metasystem.

One thing that I am missing from the article is the notion of "claims". Information Cards are "information cards" not "login cards" and especially they are no "id cards"; they might be used for authentication and even identification but, I believe, that the major thing to note about Information Cards is that they, by means of a trusted client component - the card/identity selector - enable the secure and privacy friendly exchange of data about the user.

Information Cards will be available on major operating systems and browsers. Many people are working on this and we will be successful.

Deutsche Telekom wins IDDY 2008 Award

Just copying from the Liberty Alliance press release...

Deutsche Telekom AG - Deutsche Telekom AG has received a Multi-Protocol IDDY Award for its identity application designed to lower implementation barriers when it comes to the delivery of Online/IP-based services to consumers. Initially launched in 2002 and winner of the 2006 IDDY Award, the application has been steadily enhanced to offer multi-protocol capabilities for service provider interfaces as well as for authentication methods and automatic user identification. The application serves the requirements of the mass market for Online/IP-based consumer applications by providing fundamental functionalities such as Single Login, Automatic identification, Single Sign On and Single Logout.

* Highlights – With Deutsche Telekom AG serving as an identity provider, the application is a key business enabler for offering Online/IP-based services to Deutsche Telekom AG customers. The application ensures easy implementation of consumer services and shortens the time-to-market for new service offerings. It allows quick and cost-efficient link-up with partners using the identity standard protocol that fits best and reduces the complexity of the IT-architecture. The application provides consumers with a unique and consistent user-interface that is easy-to-use, transparent and secure.

* Technologies – With the goal of tying a wide variety of Online/IP-based consumer services together by means of a common identity management user experience and to provide scenario-focused login methods, the application currently supports SOAP/XML, Secure Token Service, ID-FF 1.2, SAML 2.0, HTTP Basic and HTTP Digest, as well as different authentication methods. The underlying architectural guidelines make it possible to integrate further IDM protocols with the latest enhancements moving to provide preliminary support for OpenID 1.1, OpenID 2.0 and Microsoft CardSpace.

Relyingparty Best Practices

Some days ago I went to a kiosk to buy some ice cream for me and my family. I ordered four cones with one scoop of chocolate ice cream each. When I received the first cone I found a huge pile of chocolate ice cream on the cone. I reminded the seller that I had ordered only one scoop and got the answer that this mountain of at least five scoops was _one_ scoop. Hm.

The relying party now has a problem. Its subsystems (kids) already saw the offered claims so there is now no way to plainly reject the token. On the other hand the RP knows that the subsystems (4 5/12 and 5 11/12 years old) can not handle this token without maintainance afterwards. The RP rejects the tokens and asks the issuer to resend them in another format (cup and spoon) without changing the claim's value.

I don't want to stretch this too much but I think that it is not easy to write a best practices paper that is valuable for all RPs. I would have rejected this token because no part of the RP wants to handle strawberry claims.

Carnards Die Hard

A while ago two students, Xuan Chen and Christoph Löhr, from Ruhr University Bochum claimed to have "broken" CardSpace. There were some blog reactions to this claim. The authoritative one of course is from Kim.

Today I browsed through a magazine lying on the desk of a colleague of mine. This magazine with the promising title "IT-Security" repeats the false claim and reports that the students proved that CardSpace has severe security flaws... Well, when you switch off all security mechanism then, yes, there are security flaws (The security researcher in front of the computer).

What can I say?! The existence of this magazine was new to me, but sure they have some readers. The IT-Verlag charges 20€ for this pile of rubbish (Sorry) not very well researched article (page 42).

Interestingly Microsoft is having an ad (the whole second page) in this gazette…

There is still a lot of work for the Information Card Foundation to do.
One of my tasks (privately and not as a member of the ICF) today is to question my colleague about the value of his magazine subscrition...

Gort! Klaatu barada nikto

Because this blog is named ignisvulpis I think that it is allowed to write about a Firefox 3 "feature"... If you type "about:robots" in the address bar then a special page is shown. The title of this page is the quote "Gort! Klaatu barada nikto" from the movie "The day the earth stood still" which I liked as a kid and that is shown in German television really seldom. Anyway the number of google hits when you search for this quote is astonishing. So is the number of related films on YouTube. Here is the "famous" quote:

Here is the trailer of the movie
.
Some of the films remind me on the picture linked-to here:

CardSpace for Firefox new version

I just uploaded a new version 1.0.12 of the Firefox extension that enables CardSpace for Firefox.
This now works for the release version of Firefox 3. Although I know at least one site the drives the javascript kungfu to new heights and that does not work with this version... :-(( Fixed this!

Have fun; and happy testing. Please report issues!

Congratulations TrustBearer

TrustBearer and David Corcoranwork+1-260-399-1648david.corcoran@trustbearer.com are doing cool stuff for years. Now they have been selected by Microsoft as one of two secure openid providers for HealthVault!
Congratulations!

Interesting that Sean Nolan, chief architect of Microsoft’s HealthVault service, says that they are working to support Information Cards in HealthVault too!

Now let's put that on the patient's mobile phone.

Can People Learn?

It appears that the official identity data of many Germans was online readable for over three month... including religion and sometimes a photo.
How did this happen? Well, a software company that had successfully sold its eGovernment software to many German communities published the username and password of a demo version of their software on the internet. BUT this username and password happened to be the preinstalled standard username and password of the real application too. Ouch!
You don't need much fantasy to guess what some of the administrators of the sold software had failed to do...
I don't blame the administrators alone. Sure they probably violated the security policy of their organization but the bad security design of the application takes at least a quarter of the blame. Wait, let's put some blame on the German electronic signature laws too. The system of electronic signatures is so secure and expensive that nobody is willing to pay the price in Euros for it; not even or especially not the community and the government that made the laws.

This would not have happened had they used Information Cards.
Well, on the other hand it is not so complicated to use Information Cards in a way that is really stupid e.g. let anybody access the sensible data who presents a security token with the claim emailaddress == geheim@city.bund.de.

Information Card Foundation

The Information Card Foundation was officially launched today. Great.
The first press articles are on CNET and in the New York Times. I don't like the NYT's analogy of an "online ID card" that much... Information Cards let the user choose which ID she wants to use and from which identity provider it should be asserted. The ID might even be self-issued. There is no government asserted ID required.

---- Here follows the press release text -----

FOR IMMEDIATE RELEASE

TECHNOLOGY COMMUNITY FORMS INFORMATION CARD FOUNDATION TO SIMPLIFY SECURE ON-LINE DIGITAL IDENTITY

June 24, 2008 – Australia, Canada, France, Germany, India, Sri Lanka, United Kingdom, United States – An array of prominent names in the high-technology community today announced the formation of a non-profit foundation, The Information Card Foundation, to advance a simpler, more secure and more open digital identity on the Internet, increasing user control over their personal information while enabling mutually beneficial digital relationships between people and businesses.

Led by Equifax, Google, Microsoft, Novell, Oracle, and PayPal, plus nine leaders in the technology community, the group established the Information Card Foundation (ICF) to promote the rapid build-out and adoption of Internet-enabled digital identities using Information Cards.

Information Cards take a familiar off-line consumer behavior – using a card to prove identity and provide information – and bring it to the online world. Information Cards are a visual representation of a personal digital identity which can be shared with online entities. Consumers are able to manage the information in their cards, have multiple cards with different levels of detail, and easily select the card they want to use for any given interaction.

“Rather than logging into web sites with usernames and passwords, Information Cards let people ‘click-in’ using a secure digital identity that carries only the specific information needed to enable a transaction,” said Charles Andres, executive director for the Information Card Foundation. “Additionally, businesses will enjoy lower fraud rates, higher affinity with customers, lower risk, and more timely information about their customers and business partners.”

The founding members of the Information Card Foundation represent a wide range of technology, data, and consumer companies. Equifax, Google, Microsoft, Novell, Oracle, and PayPal, are founding members of the Information Card Foundation Board of Directors. Individuals also serving on the board include ICF Chairman Paul Trevithick of Parity, Patrick Harding of Ping Identity, Mary Ruddy of Meristic, Ben Laurie, Andrew Hodgkinson of Novell, Drummond Reed, Pamela Dingle of the Pamela Project, Axel Nennker, and Kim Cameron of Microsoft.

“The creation of the ICF is a welcome development,” said Jamie Lewis, CEO and research chair of Burton Group. “As a third party, the ICF can drive the development of Information Card specifications that are independent of vendor implementations. It can also drive vendor-independent branding that advertises compliance with the specifications, and the behind-the-scenes work that real interoperability requires.”

The Information Card Foundation will support and guide industry efforts to enable the development of an open, trusted and interoperable identity layer for the Internet that maximizes control over personal information by individuals. To do so, the Information Card infrastructure will use existing and emerging data exchange and security protocols, standards and software components.

Businesses and organizations that supply or consume personal information will benefit from joining the Information Card Foundation to improve their trusted relationships with their users. This includes financial institutions, retailers, educational and government institutions, healthcare providers, retail providers, travel, entertainment, and social networks.

The Information Card Foundation will hold interoperability events to improve consistency on the web for people using and managing their Information Cards. The ICF will also promote consistent industry branding that represents interoperability of Information Cards and related components, and will promote identity policies that protect user information. This branding and policy development is designed to give all Internet users confidence that they can exert greater control over personal information released to specific trusted providers through the use of Information Cards.

"Liberty Alliance salutes the open industry oversight of Information Card interoperability that the formation of ICF signifies," said Brett McDowell, executive director, Liberty Alliance. "Our shared goal is to deliver a ubiquitous, interoperable, privacy-respecting federated identity layer as a means to seamless, secure online transactions over network infrastructure. We look forward to exploring with ICF the expansion of the Liberty Alliance Interoperable(tm) testing program to include Information Card interoperability as well as utilization of the Identity Assurance Framework across Information Card deployments."

As part of its affiliations with other organizations, The Information Card Foundation has applied to be a working group of Identity Commons, a community-driven organization promoting the creation of an open identity layer for the Internet while encouraging the development of healthy, interoperable communities.

Additional founding members are Arcot Systems, Aristotle, A.T.E. Software, BackgroundChecks.com, CORISECIO, FuGen Solutions, the Fraunhofer Institute, Fun Communications, the Liberty Alliance, Gemalto, IDology, IPcommerce, ooTao, Parity, Ping Identity, Privo, Wave Systems, and WSO2.

Further information about the Information Card Foundation can be found at www.informationcard.net.

Media Contact:

John Fitzsimmons
work+1-781-223-5833
johnfitzsimmons4@hotmail.com

The Seven Laws Wordle

Wordling things (texts) seems to be á la mode. I could not resist to wordle Kim Cameron's Seven Laws of Identity....

Information Card Size

Having Information Cards stored on limited capability devices (USB Tokens, SIM cards, UICC cards etc) currently is a difficult because many of the more secure devices have very little memory. People who have openend a crd file with an text editor or looked at a card in RoamingInformationCard format might have noticed that most of the space needed is due to the card image.

I suggest that we change the Information Card format and introduce a new element that is a reference to the actual image.

Instead of:

<ic:InformationCard xml:lang="xs:language" ...>
 <ic:InformationCardReference> ... </ic:InformationCardReference>
 <ic:CardName> xs:string </ic:CardName> ? 
 <ic:CardImage MimeType=”xs:string”> xs:base64Binary </ic:CardImage> ?
 <ic:Issuer> xs:anyURI </ic:Issuer> 
 <ic:TimeIssued> xs:dateTime </ic:TimeIssued> 
 <ic:TimeExpires> xs:dateTime </ic:TimeExpires> ? 
 <ic:TokenServiceList> ... </ic:TokenServiceList> 
 <ic:SupportedTokenTypeList> ... </ic:SupportedTokenTypeList> 
 <ic:SupportedClaimTypeList> ... </ic:SupportedClaimTypeList> 
 <ic:RequireAppliesTo ...> ... </ic:RequireAppliesTo> ? 
 <ic:PrivacyNotice ...> ... </ic:PrivacyNotice> ? ... 
</ic:InformationCard>

I would like to have something like:

<ic:InformationCard xml:lang="xs:language" ...>
 <ic:InformationCardReference> ... </ic:InformationCardReference>
 <ic:CardName> xs:string </ic:CardName> ? 
 <ic:CardImageRef MimeType=”xs:string”
 hash="xs:base64Binary" 
 width="xs:unsignedInt"px height="xs:unsignedInt"px filesize="xs:unsignedInt"
 href="xs:anyURI"/> ?
 <ic:Issuer> xs:anyURI </ic:Issuer> 
 <ic:TimeIssued> xs:dateTime </ic:TimeIssued> 
 <ic:TimeExpires> xs:dateTime </ic:TimeExpires> ? 
 <ic:TokenServiceList> ... </ic:TokenServiceList> 
 <ic:SupportedTokenTypeList> ... </ic:SupportedTokenTypeList> 
 <ic:SupportedClaimTypeList> ... </ic:SupportedClaimTypeList> 
 <ic:RequireAppliesTo ...> ... </ic:RequireAppliesTo> ? 
 <ic:PrivacyNotice ...> ... </ic:PrivacyNotice> ? ... 
</ic:InformationCard>

• hash="xs:base64Binary"
  The SHA-1 hash of the image data
• width="xs:unsignedInt"px height="xs:unsignedInt"px filesize="xs:unsignedInt"
  The width and height of the image in pixel and/or filesize in bytes (optional)
• href="xs:anyURI"
  The URL where the image data can be retrieved

The id selector can now choose the "right" image for the mobile device based on the image size, but more importantly it can now cache images in the case when more then one card has the same image (URL and hash) or the image was downloaded before. The hash is a protection against DNS spoofing. Alternatively we could define that the href must use SSL and use the id selectors certificate based protection mechanisms against attacks.

Instant Install of Managed Card

I changed the openinfocard id selector and the xmldap idp to make it easier to install managed cards.

Let's say you visit the IdP of your trust and have logged into its service using username and password. In fact the choice of this authentication might influence the rest of this scenario.
After authentication you are presented the list of your current cards:

Formerly you were presented with a list of links that you could click and you had to save the .crd file to disk, then open the id selector of your choice to import the card.
Now, you have noticed the column of little icons, you can invoke the id selector directly. Let's say use click on one of these icons (20071018xmldap):

The new card wizard of the openinfocard id selector has opened and the card is retrieved from the URL that was delivered to the id selector.
After this you are (currently) back to the page that shows the list of your cards and you might now open the id selector to verify that the new card was imported (20071018xmldap):


Well, how does this work?! I use a special tokentype "urn:oasis:names:tc:IC:1.0:managedcard" that tells the openinfocard id selector to use the value of the "issuer" parameter to retrieve and import the card.
There might be better ways to do it and there is a precondition here that I did not mention. Do you see it?

Back to the IdP authentication... Instead of username and password an IdP might have allowed authentication with a self-issued card and then that card could be used for authentication when the managed card is used to provide claims to a relying party!
(More preconditions here... Find them!!! and discuss this either here on this blog or here)

OASIS event

OASIS Open Standards Forum 2008

,

Ditton Park Road Datchet

,Slough Berkshire SL3 9LL,Near London,SL3 9LL

,

(44) (0) 1753 242880

OASIS Open Standards Forum 2008September 30-October 3, 2008

Topics include, but are not limited to:

• High-level overviews of security challenges, and the landscape of security standards being developed to address them
• Case studies, requirements, deployment overviews, profiles from specific sectors or application areas (e-governments, telecom, financial services, healthcare...)
• Authentication of citizens in cross-border government services, issues related to mutual recognition of authentication services
• Information cards and information card interoperability
• Federated technologies
• Access control, access control models, policies, and privacy issues
• Key management (PKI or symmetric key-based)
• Digital Signatures, electronic signatures, server-based signature processing, technical and legal issues.
• Securing Web Services: WS-I profiles; recent Web Services security specifications

This happens together with the workshop "Adopting SOA for Telecom".
Sounds interesting, I would like to attend. Gerry Gebel is giving the keynote and Anthony Nadalindrsecure@us.ibm.com is on the workshop committee.

Information Card (?) Icon Mania

I am missing a gene that makes that I don't understand usage guidelines and IPR discussions.

Doppelgänger

Today I updated the xmldap relyingparty to contain two HTML objects of type "application/x-informationcard". To keep things simple I just have put two forms on the website each containing one object. The only difference between the two is that on requires a self-issued card while the other does not restrict the issuer.

The id selectors seem to handle this well. I tested it with the openinfocard id selector and with CardSpace.

What is this good for?! Well, one object could request a card from the issuer "Mastercard" while the other requests a card from the issuer "Visa". Or one could request an issuerpolicy while the other does not...

Interestingly CardSpace fails the test on Pamela's test page for the OSIS interop test. It seems that CardSpace does not like the missing "requiredclaims" parameter...
The openinfocard id selector has its flaws too but they don't stop this test from "working" or do they?

OSIS I3 Information Card RelyingParty Feature Test

The sad truth is that nobody really cared to fill out the feature test tables for relyingparties during the OSIS I3 interop. This table shows only relyingparties that have at least one test result other than "Not Tested". The xmldap RP and all Microsoft RPs were deleted from the table for this reason. Even features that most RPs support have no utilizable value. The last two rows of the table should show "Works" for probably all RPs but they show the dreaded "Not Tested"...

This table is not usefull to conclude the maturity of the Identity Metasystem from it. Shame on us. Shame on me.

Microformatified

Today I began to put Microformats in my blog and installed the operator extension into Firefox to see and work with microformats. I was astonished that blogger has put a little bit of microformat into my blog already. Using operator or a similar tool you can now work on the tags, export events and contact information. This is a nice start. Next I want services specifications; either XRDS (simple) or Microsoft's openservices?!

Please notice the green cross and the new "operator" toolbar.

Phishing Resistant openid

	openid
	phishing resistant openid

OSIS I4 Wiki is coming up

I am pleasantly surprised that the I4 wiki is up. Well, I guess, Pam is still polishing it. That must be the reason we haven't seen an anouncement. Anyway; thanks Pamela, great work already.

Here is a table I compiled from the last interops feature tables. The new wiki will probably produce something similar automatically. Perhaps not with this eye-hurting colors.And there will be much more feature tests...

Stealing the Security Token

The Ruhr Uni Bochum claims that they can steal the security token in a CardSpace scenario.... The experts from the German computer magazine c't could not verify the attack...
After reading the paper that describes the attack I must say that I find it very unrealistic.

The attack is described for managed cards. The browser is tricked to load malicious code and then the real RP's code is loaded and presented to the user. The malicious code then loads the root certificate for the malicious RP's SSL certificate and asks the user to install it into the trusted store. This is the biggest assumption in the scenario. Next the user clicks the purple CardSpace icon.

Case 1) Auditing Mode
Assume that CardSpace is tricked to request a token for the malicious RP. When this is the first time CardSpace sees this RP (which is likely) then there might be little CardSpace can do to help the user to recognize the malicious site (because of the installed root certificate). When this is not the first time then CardSpace will warn the user who will probably terminate the transaction.
But who installs a root cert into a trusted store might continue the transaction even when CardSpace raise all flags and blinks all warning lights.

First: The IdP might reject to issue a token to an RP with which it does not have a contract or is outside the (enterprise) circle of trust. Then this attack does not work.
Second: When the IdP issues a token to the malicious RP then that RP can decrypt the token and read the (private) claims. Then it encrypts the assertion for the real RP. The malicious code in the browser (loaded from the malicious server) receives the newly encrypted token and presents it to the form for it to be submitted. The assumption that the malicious code can now reuse the security token to whatever purpose it likes at the RP is not true because the auditing mode restrict its use to the malicious RP.

Case 2) Non-Auditing Mode
Assume the same prerequisites as in case 1. The user is super stupid and the token is stolen and not restricted to the malicious RP. So whenever the real RP expects a security token the malicious code in the browser can provide it.

Do I have to say that an attackers code running inside my browser is probably deadly anyway? Even when the token is not stolen the likelihood that the claims will be a visible part of the "next" page is high, so they can be stolen this way too.

Can't wait to hear what Microsoft writes about this. I had a long busy day and will rethink the whole thing tomorrow.

Free SSL certificate from GoDaddy

Sometimes wishes become true.
I just whined about the cost for certificates but only a few hours later I found this offer from GoDaddy for opensource projects.
Have to wait how complex this gets... Sending the application was easy. Now I am waiting for approval...

openid comments at this blog

I just enabled comments with openid on this blog.

Now you can have your nice "own" id instead of a google account.
Please make sure that you have sxipper installed to warn you about phishing attacks. Does sxipper examine the cert whether I have been at a site already? Have to look into this later...

Have fun with this very useful use of openid. If you are a product manager: While this is useful, please listen to your security guys, before jumping onto the openid train by enabling openid on your valuable site. Better enable information cards.

extended validation certificates

Extended validation certificates are not the cure for all problems.
The Register reports an XSS attack to Paypal.

I think that more than EV certs the identity metasystem needs affordable certificates for all.

openid is toast

Mike (one of those who need no sleep) blogged about Fun Communication's openid idtheft site and I encourage you to read Mike's post and try your personal idtheft immediately.

Back here?! Well, you knew all this already, didn't you?
But seeing it in action is another thing, I guess.

So where does this lead us? Remember the "openid dogfight" from September 2007? I too think that we need a spectrum of solutions. I agree that openid is for when an RP has "trivial" security requirements, but I think that trivial is not easy to define. At first your openid might be good enough for trivial things but its value grows with time. The more you use your openid the more valuable it becomes and then the risk you take by using the openid protocol becomes too great to accept. So let us all improve openid through e.g. PAPE. But why? To end up with another secure and inconvenient system? Thanks, no.

• back channels are bad (privacy, user consent). (SAML artefact)
• browser redirect protocols are bad (phishing). (openid protocol, SAML HTTP redirect binding)

Are CardSpace, Higgins' id selector, DigitalMe and openinfocard the solution? Not yet.
I think that the most important things that the Microsoft's vision of the Identity Metasystem until now has brought us are:

• thinking in claims instead of thinking of "login"
• identified the need for a unified user experience when PII is involved
• a client component to achieve the former two

Paul writes that his sxipper prevented the phish. This is a client component like CardSpace and the other id selectors.
We could integrate openid into the id selector and call it "identity agent" or whatever makes this idea stick. But then... Why use openid at all? This is so close to the origin of the security axis that we would need logarithmic scaling to make it visible.

Let us build this identity agent. Let us integrate openid and passwords into the client, but only as a migration path to a convenient and secure alternative.
Down with browser forms for claims/attributes. The browser is your friend.

Minimal Disclosure Tokens

Kim's presentation is full of nuggets. Minimal disclosure tokens will be part of the future of CardSpace I believe.

Magic Kim

While looking for input why "Claims will change everything" I found this presentation from Kim Cameron on the net.
Yes, we have the "proto-wand" and I want to turn it into our magic wand. I think that this is the true "iCard" and I hope that CardSpace will allow to have the cardstore on a secure mobile device not too far in the future.

Please notice the logo on the phone. It shows the building in which Deutsche Telekom Laboratories reside. My colleague Martin Kurze and I created the Magic Kim and reused our prototype magic wand image there.

CardSpace @ Microsoft 360° Security Days

Microsoft Germany offers the Microsoft 360° Security Days to German speaking architects, project managers and developers. One session for architects and project managers is about Microsoft CardSpace. I really hope this will be an inspiring talk given by a true believer of the claims paradigm.
It's a pity that a participant can not provide her claims by using information cards during registration for the event.
Anyway, I am happy that CardSpace is a topic. We need more events that advocate information cards. Worldwide and in other languages than English too. I hope that Microsoft Germany offers the slides of the session to the public after the event and not only to participants.

Bandit Architecture Goes Mobile

Anders Lundgren from RSA Labs just forwarded me a link to a Nokia research paper that describes an implementation of the Bandit's project architecture on mobile devices.

Too bad my attempts to contact Nokia regarding the Identity Metasystem failed. I tried to contact them right after Catalyst Barcelona but replies remained vague and dried out soon. I think that mobiles are THE target for information cards.
Maybe somebody from Nokia reading identity blogs reads this and we work together?
I think we are operating on common ground to a common goal and will benefit from a cooperation!

People are email addresses. not.

During the Internet Identity Workshop I thought that it might be time to "pretend" to relying parties that I don't have an email address. Some years ago I tried to live without a "C:" partition on a windows systems. I had several versions of Windows installed on different partitions and at some point in time removed the oldest version on C by removing the whole partition. After some time I gave up on this scheme because to many dump scripts and too many dump programmers insisted that either the system is on C or that the program or parts of it are installed on C. If you don't have a C than things start to fail in interesting ways.
Today, I think, that many relying parties (social sites) demand that I have a valid email address. I think that this might be an assumption that is more and more false as "social" people are using the social sites. Or more and more people will have email addresses but will not know that they have one.
So relying on email for "verification" (registration) or credential reset might not be a good idea. More probably the notion of an "account" is wrong to begin with.

IIW2008a Infocard Features

During the OSIS session at IIW2008a we went through all the informationcard related features.

• I3:Information Card Relying Party Features
• I3:Information Card Browser Add-On Features
• I3:Information Card Identity Selector Features
• I3:Information Card Identity Provider Features

We categorized them by priority and maturity.
We identified features that need clarification and features that need (better) tests.
Results will be on the wiki soon.

IIW2008a Tuesday: Openliberty People Service

Asa demoing bootstrapping ID-WSF PP from an OpenID