The Attribute Registry V 1.0 is one of the early deliverables from the Scalable Privacy project.
The core data elements are attributes, each of which comes from one of a defined set of specifications or standards. The images in this overview were taken directly from the ontology tool, Protégé, used to maintain the registry. A web-accessible version of the registry is available at http://webprotege.stanford.edu/#Edit:projectId=1f647b22-a7b1-47d1-9964-004f811b3282
Each attribute is associated with the specification that defines it. For example, the OpenID Connect specification covers the following attributes:
An example attribute entry in the registry appears as follows (this is the Profile attribute from OpenID Connect):
Note the metadata (Object properties and Data properties) recorded in the registry for the Profile attribute. Version 1.0 contains a minimal set of metadata elements. Other types of metadata may be added to suit emerging needs in the attribute ecosystem work.
Another example attribute entry in the registry is eduPersonPrincipalName from the eduPerson specification:
Note the relatively full Definition element in this case. This is drawn from the specification itself.
At the top of the eduPersonPrincipalName example above, there is the object property "isClassifiedBy" with the value "Identifier". This is an example of a metadata element meant to categorize attributes across specifications into a defined set of types. This metadata element is called "Attribute Class". Here is the first part of a listing of the currently defined attribute classes:
A couple examples will clarify the notion of attribute class. Take the example of attributes relating to preferences.
The Open Social specification (attributes whose prefix is "osoc") contains two attributes in the class "preference". The LDAP specification (currently RFC4524) contains an attribute "drink" which indicates personal preference as well. Here is the preference attribute, osoc-emails-primary:
Another example of the attribute class metadata is "role". Several specifications (SCIM, SCHAC, LDAP and X.520) contain attributes meant to carry some definition of a person's role:
Going forward, attributes from additional specifications and standards will be added (including a master set from FICAM and one from the state of Virginia). One open issue is whether the current list of attribute metadata is adequate or whether there would be value in carrying additional metadata elements in a general purpose registry of this sort.
Account, Address, Affiliation, Application, Assurance
Citizenship, Contact, Country
DN, Date, Description
Email, EmailMetadata, Entitlement
Language, Link, Locale, Location
Password, Phone, Photo, Pointer, Position, Preference, Presence, Privacy, Profile
Salutation, Search, StateOrProvince, StatusMessage, SuperiorNode