Open Issues
From IdCommons
- There are often not one-to-one mappings between schemas (a classic case is decomposition of "address" - some people will have "number" and "street" as two items, some as one - and, of course, some countries don't always have numbers, or even streets - the UK, for example). -Ben Laurie quoted from the Identity Gang
- Even in the US, not all addresses have streets or PO Boxes (e.g. "Internal Revenue Service$Austin TX 73301-0002" is valid)
- The most one can say is that 'street' describes something about a physical location and a mailing address, and 'postalAddress' (the LDAP attribute for a full address) describes something about a physical location and a mailing address, but there is no general mapping from street to postalAddress or v.v. Similarly, there is in general no mapping between 'cn' (the LDAP attribute for a full name) and 'sn' (the LDAP attribute for a surname), even though they are both naming attributes, since there are no markers within the 'cn' value of where a surname starts and stops.
- One could envisage a structuredName with a value such as <firstName>jane</firstName><surname>bloggs</surname><maidenName>smith</maidenName><nickname>zany jane</nickname><initials>jb</intials><generationQualifier/><fathersSurname>smith</fathersSurname><professionalName>Ms. Smith</professionalName><name-as-known-to what='accounting'>!JaneS11</name-as-known-to>...that would be transformable, but few identity management systems have this richness today.
- Should probably attempt to only define mappings that are syntactic transformations (e.g. ISO8859-1 to UTF-8) or could have a little pseudocode in their description.
- Scope
- how many forms of identity system should be represented to be useful?
- how much schema from each identity system should be represented?
- how much metadata from each identity system should be represented?
- how much mapping information between each schema element should be represented?
- Versioning - there are not only changes in version between standard documents, but also between implementations, and deployment. For attribute "foo", there is "foo as defined in RFC 123, foo as defined in RFC 456, foo as implemented by vendor X, foo as deployed by customer Y"... A user of this database who wants to know how to go from "foo" to "bar" is likely to be most interested in the 'most standard' and 'most widely implemented' versions of "foo", and less interested in more specific versions of "foo" (e.g. !MegaCorp has decided to put an employee number into the uniqueIdentifier attribute, which can then be easily mapped to the employee-number field...).
- Multiple possible mappings exist between many pairs schema elements. A typical case is when one an identity system has a 'default' representation for an object, such as a person, as well as an catchall representation.
