Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Value metadata in identity protocols (20070522)
One design pattern typical of many identity systems and protocols is that
- the initial version of the system or protocol is oriented to the transfer of attribute or claim values as simple strings,
- subsequent revisions to the system/protocol add the requirement to attach, to a value being transfered, various forms of metadata "about" the value.
This has been true for:
| Protocol | Value Metadata Extensions |
|---|---|
| X.500(1997) | validity periods (notBefore through notAfter) |
| LDAPv3 | language tags (RFC 2596 and RFC 3866)
"dynamic" indicator |
| OpenID AX | language tags |
There are numerous implementation approaches for adding support for value metadata in identity protocols, including
-
Add fields to the transfer protocol representation of an attribute.
This approach was adopted in X.500. X.501(1993) defined an attribute as an attribute type and a set of values; X.501(1997) defined an attribute as an attribute type, a set of values, and a set of valuesWithContext:
Attribute ::= SEQUENCE {
type ATTRIBUTE.&id,
values SET SIZE (0..MAX) OF ATTRIBUTE.&Type ,
valuesWithContext SET SIZE (1..MAX) OF SEQUENCE {
value ATTRIBUTE.&Type,
contextList SET SIZE (1..MAX) OF Context } OPTIONAL }
- Add a modifier to the attribute type.
This approach was adopted in LDAP. LDAPv2 defined an attribute as an attribute type and a set of values; LDAPv3 defined an attribute as an attribute description and a set of values, in which an attribute description was an attribute type and a set of optional modifiers, such as ";binary" or ";lang-en".
- Integrate the metadata into the string value.
This approach was adopted in the draft specification for use of language tags in OpenID values, in which a fetch might return
The value of openid.ax.value.fav_movie.2 ("Amélie" in French), the UTF-8 encoding of ten Unicode characters, is the following 23 bytes:
f3 a0 80 81 # LANGUAGE TAG
f3 a0 81 a6 # TAG LATIN SMALL LETTER F
f3 a0 81 b2 # TAG LATIN SMALL LETTER R
41 # A
6d # m
c3 a1 # eacute
6c # l
69 # i
65 # e
f3 a0 81 bf # CANCEL TAG - Have different attribute types for a string valued attribute, and an attribute with a richer structure that is capable of supporting metadata.
This last approach has been considered since the mid-1990s as an "attribute certificate" (see the discussion in section 1 of RFC 3281), and was also discussed at the recent Internet Identity Workshop 2007 (iiw2007) in the context of Managing schema in the identity metasystem.
Earlier this month I proposed an Identity Associated RDF attribute, a rich attribute in which claims expressed in RDF could be tunneled through LDAP, SAML or OpenID. (Specifying the encoding in which the RDF is signed and incorporated as a CardSpace claim for STS transformation is still under development.)
Mike Jones of Microsoft wrote in Interoperable Verified Identity Claims on an additional form of value metadata of interest to CardSpace: indicating whether an attribute value has been verified, and if so, by whom, how, and the validity period of this verification. He suggests a syntax of a rich attribute for a "verified name", such as
<verified>
<value type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">Michael</value>
<who type="http://www.w3.org/2001/XMLSchema#string">Acme Data Provider</who>
<when type="http://www.ietf.org/rfc/rfc3339.txt">2007-05-14T16:30:00Z</when>
</verified>
One key question when designing a value metadata representation system is how value metadata combine on a single value. If metadata labels X and Y both attach to a value V, must a receiver understand any of X, Y, or the combination of X and Y, in order to parse V? If a receiver understands X but does not support Y, can the receiver determine that X is present on that value?
An example of where an attribute value might have multiple metadata is a university student's on-campus housing address.
- The address value might be issuedBy a campus housing department.
- The address value might be verifiedBy the student's college or department (as mail sent to that address is delivered to the student).
- The address value might be validUntil a particular date, asserted by the student, of when they go home for vacation.
A receiver of this information may wish to only see attributes that have been verified by one of the colleges in the university, and may not be interested in knowing who issued the value or whether it has an expiry date. How difficult would it be to capture this concept in each of the approaches:
| X.500(1997) context approach | straightforward; each label would be its own context |
| LDAPv3 attribute description approach | would be difficult to describe |
| integrating metadata into the value approach | not recommended |
| different attribute approach, with many rich attributes | would require a sender or receiver to implement a component similar to the Schemat Consumer |
| different attribute approach, with a single rich attribute | straigtforward, so long as there is a flexible transfer syntax, but would also require rich update semantic operations in protocols which support update |