[OpenID] openid, foaf and attribute exchange

Thu Jul 26 00:08:52 UTC 2007

So...I'm getting more convinced at least on the issues related to the
topic of OpenID Exchange, based on our actual recent experiences.

I know in the SAML deployment of webSSO we did recently, we struggled to
indicate within the SAML message the full typing and syntax and naming
of the attributes we were publishing. I'm still not sure whether the
SAML standard does or does not allow for namespace-based
registration/declaration of attribute names. I cannot fathom for the
life of me whether it has a means to define and then indicate value
specs.  I found myself almost wanting to simply take complete control,
and put an LDAP string-encoded name=value pair in there, referencing the
oid of the attribute back to the IETF spec in question. I.e. Just borrow
LDAP-representations/X500-definitions of values...even tho. no LDAP
server is actually involved (in our case).

Whilst the problem I mention above is REAL, it may be a function of the
SAML product I'm using - which is trying really hard NOT to make SAML2
as difficult as humanly possible. This obviously means dropping features
from frontline support that ... hardly anyone ever needs. While I can
easily already publish my (signed) metadata-attribute contracts and
store them in a repository that it itself declaring metadata about these
SAML metadata resources to allow for searching, the value typing/syntax
signaling support seems entirely missing in the metadata as in the
messages. I don't know whether the problem is the standard, the product,
or me. Whichever the case, it's a pain, as doing something trivial has
become a pain (yet again).

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Mark Wahl
Sent: Wednesday, July 25, 2007 4:21 PM
To: Story Henry
Cc: ID Schemas; general at openid.net
Subject: Re: [OpenID] openid, foaf and attribute exchange

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.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general