Sunday, August 31, 2008

Happy Birthday

Happy Birthday.

Friday, August 29, 2008

Web 2.0 Summit + IIW 2008b


Palace Hotel
2 New Montgomery Street
San Francisco, CA 94105



Computer History Museum
Mountain View, CA


This is a nice combination. Meet me there. Suggestions for the weekend?!
-Axel

Tuesday, August 26, 2008

Firefox 3 Java Bug with openinfocard

Just filed a bug for Firefox 3 and Java 6 Update 10 RC.

I maintain the Firefox extension "openinfocard"
http://code.google.com/p/openinfocard/downloads/list
Since Firefox3 users experience an error message "ReferenceError: java is not
defined". Today I tried whether this error still occurs with
jdk-6u10-rc-bin-b28-windows-i586-p-21_jul_2008.exe and ran into the error
message.
"TypeError: invalid 'instanceof' operand java.net.URLClassLoader" here:
http://code.google.com/p/openinfocard/source/browse/trunk/firefox/components/TokenComponent.js#272
This works with previous version of java.

Reproducible: Always

Steps to Reproduce:
1. Install the Firefox extension into FF3. Save to disk, then install.
2. navigate to a site that uses Information Cards e.g.
https://wag.bandit-project.org/BanditIdP/index.jsp
3. Click on the Information Card icon
Actual Results:
An alert dialog opens with the error message "TypeError: invalid 'instanceof'
operand java.net.URLClassLoader

Expected Results:
No alert but the identity card selector window opens and you can create an
information card (self-issued) that you can then use to provide your claims
about yourself.

Internet Identity Workshop (IIW) 2008b


Computer History Museum
Mountain View, CA

The tag for this event is iiw2008b.

I for me don't have financing to attend (yet) but I recommend this event. Be there!

Friday, August 22, 2008

Kim, Architecture Journal, ICF


Vittorio wrote about issue #16 of the Microsoft Architecture Journal. The latest edition is all about Identity, Claims etc. And it contains an interview with the master, Kim Cameron, who mentions the Information Card Foundation as an example of the industry coming together to make this all happen.
Read it!

If you want to lean more about the Information Card Foundation please contact
Charles Andres, Executive Director
Information Card Foundation
56 Kearney Road
Needham, MA 02494 USA
+1-781 559 4223

xmldap / openinfocard new version


The openinfocard id selector now validates the signature of an imported information card and checks the validity dates of the signing certificate. The certificate chain and revocation lists are NOT checked. This is one feature that blocks an 1.0 release ;-)

Please make sure that you always use the latest version of the xmldap.jar (if you have an RP or STS that needs it) and xmldap.xpi (the id selector). In April I committed a version of the RP (xmldap.jar) to the svn repository that did not work with DigitalMe. I apologize for that.

Thursday, August 21, 2008

Information Cards: Unused (Security) Information

It seems that I have to make up for not posting while my new house was build...

Here is another post for today in the series (1,2,3) of posts around things you always wanted to know about Information Cards but never had the heart to ask.

Did you know that CardSpace does not use the Identity information in an identity enabled EndpointReference? Shocking.
Here is what I heard...

When you import a managed card from a .crd file there is something inside the file that is called the TokenServiceList that contains a sequence of TokenService(s) that contain an EndpointReference. This is defined in WS-Addressing and in our case extended to contain an element "Identity" from the namespace "http://schemas.xmlsoap.org/ws/2006/02/addressingidentity".
<Identity
 xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <X509Data>
   <X509Certificate>
MIICfTCCAeagAwIBAgIBATANBgkqhkiG9w0BAQUFADAqMQ0wCwYDVQQKEwRPU0lTMRkwFwYDVQQLExBJ
bnRlcm9wIEJvZ3VzIENBMB4XDTA4MDYxMTE2MTIxM1oXDTA5MDYxMTE2MTIxM1owSzENMAsGA1UEChME
T1NJUzEZMBcGA1UECxMQSW50ZXJvcCBCb2d1cyBDQTEfMB0GA1UEAxMWdGVzdC5wYW1lbGFwcm9qZWN0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz9qsJnJd/ZD8Fr/uGSojxMVoD53w28O14RLB
Hfm3scuFd9ypxy7KU8fOkDyOtKWoHqAVpPd/TRHIYiyRVorEyIiqQpbKCcqUd2YJM9nVxHuOHYvrVXRj
QAVV3Fu4Ncy22Tl+lJRJzWgcfc89aqFoyIv2tmqvAisRyNf6+1eppmcCAwEAAaOBkTCBjjAJBgNVHRME
AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDALBgNVHQ8EBAMCBaAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCG
SAGG+EIEAQYKKwYBBAGCNwoDAzA1BglghkgBhvhCAQ0EKBYmT3BlblNTTCBDZXJ0aWZpY2F0ZSBmb3Ig
U1NMIFdlYiBTZXJ2ZXIwDQYJKoZIhvcNAQEFBQADgYEAIppR+riUA/cxJJBaNGslzoa297XMUqQelJ15
1UcGUWCqTxer2/b5nUG2TpmnA0/7CPCjE2t44st6MImB2tqDtI7DNSCKz19aNlhpoHa8MrCjPKHlDNIU
nqg3ZylCxbwm40G5NFiAXXCUznYyD9J6AhDesSvGCRCo3OStKaxr7jM=
   </X509Certificate>
  </X509Data>
 </KeyInfo>
</Identity>

Can you imagine: CardSpace just throws away this certificate and never uses it!

What is this certificate anyway? Some clever people came up with the idea that EndpointReferences need more security and should be protected by Identity. One way to provide endpoint identity information is to specify which certificate will be used by the (security token issuer) endpoint. This for the theory; in practice CardSpace does not use this information.

Why? Well, when the certificate is valid at the time the information card is issued but invalid after some time then the issuer would have to re-issue all cards that contain an EndpointReference with that certificate attached...
Microsoft thinks, I guess, that in general people - even professionals - are to stupid to handle the crypto-thingy correcly.
I don't know. I think that we should expect an Identity Provider to know its business and part of that business is to handle the certificates/keypairs etc so that the Identity Metasystems handles a renewed certificate without hickups.

An alternative to specifing a certificate is to specify an RsaPublicKey. This has no validity dates attached to it so it can not become invalid. If the STS specifies the public key then it can change certificates or part of the information in the certificate as long as the keypair stays the same.
This advantage of keypairs in contrast to certificates is an disadvantage too. Should the private key of the keypair be compromised then all information cards have to be re-issued (Super-GAU). Well, this falls in the category "This should never happen". We should expect to see this not too often.
Enough gossip for now. Time to call it a day.

Enjoy.

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.

Tuesday, August 19, 2008

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)

Monday, August 18, 2008

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?

Friday, August 15, 2008

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...

Monday, August 11, 2008

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.