Wednesday, October 31, 2007

Attribute Context?

The ongoing Cardspace assurance thread with Pam, Gerry, and Kim hilite for me the fact that two different sources of the same attribute, even if they have the same value, can engender totally different levels of assurance in that value. The 'how you got it 'matters'.

Vittorio sums it up

.. a date of birth gathered during some questionnaire or a date of birth certified by an authority carry different business weight ..

As yet, AFAIK, there is no standardized syntax by which these differences might be described - something equivalent to SAML's Authentication Context but for attribute statements and not authentication statements (pause here for somebody to mutter to themselves 'Well identifiers are just attributes after all').

Beyond syntax, what of a framework for attribute assurance? OMB m04-04/NIST 800-63 explicitly state that attribute assurance is out of scope for that work.

1 comment:

Robert said...

Yes, some attribute context statement of sorts might come in handy. Every now and then. But...
First, if the RP cares about the reliability of one or more attributes it can typically deal with that in the oob contract that it engages in with the IdP/AttributeProvider. In other words such a RP doesn't treat all IdPs equal. Try to get into a Finnish bar on Friday night with a self signed paper that state that you're over 18. With a government issued photo id your chances increase significantly. This example also shows that "laws" (and govermental/public IdPs) can provide a lot of the "legal" framework and useful services. I see a trend here in Finland where banks act as IdPs and they have "federated" their customers to a government photo id, and hence are seen as reliable providers of especially date-of-birth (and social security number). Interestingly the largest group of RPs (SPs) that make use of those bank IdPs seem to be governmental/community services (tax office, community college, etc.).

Second, it may be useful to wonder why does the RP need a more-reliable attribute ? If it wants to serve me more personalized advertisements, it actually should favor the date-of-birth on that self-signed thingy as the visitor probably actually likes to be treated as a 55 year old lady, irrespective of the governmental IdPs claim of the person being a 16 year old boy.

I haven't seen many good real implementations where the authentication context is used effectively, so I think that it will be really long before we would see RPs that actually would be clever about attribute context. But yes, in theory it would be good to provide the RP with information about the "source" of the attribute value(s).