[OpenID] openid, foaf and attribute exchange

[Mark Wahl]

Story Henry wrote:
> 
> mhh.. Not sure I understand. Yes there are some relations that need to 
> be defined, but that's not difficult...

I'll take that with a :-)

> Is this the kind of relation you are working on there?  

Similar.

The goal of the Identity Schemas working group as I understand them
would be to enable a user, community, or organization, such as Sun
for example, to:

  * reference well-known base ontologies by which identity schemas are
    constructed and identified (FOAF in RDF, { inetOrgPerson User eduPerson
    } in LDAP, the Microsoft self-asserted claims list for InfoCard...,
    which today have no consistent human AND machine readable
    representation,

  * be able to choose from well-known identity schema elements for
    use in modelling the attributes of identities, to avoid needless
    redefinition of schema,

  * if there is no existing schema element for Sun's purpose, enable
    Sun's definition of a new schema element to have published
    metadata that expresses its syntax AND semantics, so that external-
    to-Sun application developers AND external-to-Sun applications which
    encounter users who have that attribute in their identity will
    know what to do with it.

For example, suppose Sun decides it wants to have a sunEmployeeNumber
attribute in the OpenIDs or FOAF files of its employees.  The metadata
Sun publishes for that attribute type might include typical schema
stuff like
  - that the attribute is a subtype of the inetOrgPerson/pilotPerson
    employeeNumber attribute,
  - that the values of this attribute are positive decimal integers,
  - that the sunEmployeeNumber is assigned by Sun,
  - that Sun employees have exactly one sunEmployeeNumber,
  - that no two Sun employees share the same sunEmployeeNumber,
  - that once an employee stops being an employee, their number is not
    reassigned,

or 'more interesting' statements like
  - that a sunEmployeeNumber is only valid if it comes in a protocol
    exchange from an address mappable to the *.sun.com domain signed
    a with certificate issued by a sun CA,
  - that the values of the sunEmployeeNumber are not permitted to
    be transferred outside of the safe harbor as they contain personal
    identifying information,
  - that a web service to check whether a value is still valid is
    openid.sun.com/checkID/, ...

This is necessary as schema definitions proliferate and this shows no
signs of slowing down.  Each new protocol/data format defines its own
"yet another" way of modeling people as a bunch of { properties attributes
name=value pairs claims }.  Every enterprise or service provider
software application and large enterprise defines its own models.

As this is inevitable, it is necessary to be able to describe the relationships
between identity schemas.  For example, that many LDAP attributes are just the
X.500 attributes with different names, that many FOAF properties are IETF
standards-track LDAP attributes with different names, OpenID AX attributes
are ...


First, there are some basic relations for schema elements themselves, such as

* "defined by"/"change controlled by": e.g. to express that the organization
   Microsoft defined PPID attribute, and that the organization IETF has change
   control for the inetOrgPerson object class.

* "same as": e.g. to express that cn defined in LDAP and commonName defined
   in X.500(93) are the same attribute type,

* "similar purpose": e.g., { cn commonName department departmentName fn
     fullname g givenName o organizationName organizationalUnitName ou
     sn surname } are all types of attributes whose values are names that
   people use to identify individuals and organizations,

* "appropriateness for context": e.g., do not use the ism attribute of my
   name in social networking, use the kunya or -urf attributes, if present,
   otherwise use the nisba.

* "grouping": e.g., homeTelephone and homeAddress are more closely related
   to the concept of a person's domicile than businessFaxNumber.

* "ordering": e.g., when displaying my full name, my middleName
   comes after my givenName and before my surname, and my generationalQualifier
   comes after my surname,

* "sorting": e.g., in the en-US locale of white pages listings of individuals,
   surname sorts before givenName.

* "contains": e.g., fullName contains surname, postalAddress contains
   postalCode.

Second, there are relations for all attributes of a particular type. For example,

  * "acquisition": to get your own value of the screenName attribute, sign up
    with AOL, and to get a flickrAppKey, sign up with Yahoo.

  * "assigner": the values of sunEmployeeID are assigned by Sun, but are
    restricted: someone can't just "get" one.

Third, there are relations for values. For example,

  * "validated by": the CA DMV validates that this driversLicenseNumber 12345
    is correct for this fullLegalName "joe bloggs" and streetAddress "maple
    street" as of 5/2007.

>> which can be expressed in RDF and retrieved via "GET", as described in
>> http://idschemas.idcommons.net/moin.cgi/BasicRetrieval
> 
> That looks like a formalization of the RDF linked data practice. It is 
> pretty simple right,
> you do a GET on a URL and you will get a representation back in rdf/xml 
> if you do your content negotiation right.

Yes, RDF in XML is one encoding of identity schemas metadata.

Mark Wahl
Informed Control Inc.