Over the years I’ve been writing this newsletter, the concept of “context” comes up time and again. As I’ve often said, "context" is a better (or, at least, a different) way of looking at identity transactions - the who, what, when, where, how (and perhaps why) of an authentication or authorization. I may give the impression that I am somewhat focused on this concept. Some would even say that I, perhaps, obsess about it. One friend even mentioned that he thought humorist Dave Barry was thinking of me and context (or, “me in context”) when he said: "I argue very well. Ask any of my remaining friends. I can win an argument on any topic, against any opponent. People know this, and steer clear of me at parties. Often, as a sign of their great respect, they don't even invite me." My only plea is that I wish more folks with influence in identity management vendor circles would take context more seriously.
That may be happening.
Paul Madsen is the co-chair of the Liberty Alliance Technical Expert Group. These are the folks who create the scenarios for implementing the Alliance’s specifications. He wrote, for example, “Liberty ID-WSF People Service – federated social identity”.
Recently on his blog he discussed the SAML specification element AuthnContext. As he said: “Most people associate the element with capturing the specifics of how the user authenticated to the IDP [identity provider], e.g. either using a password or (more meaningfully for maximizing the value of the [single sign-on]) some stronger authentication technology like an OTP [one time password] or smart card.” Generally, that’s the way I see most vendors using “context” when it comes to authentication, also.
But Madsen goes on to say: “But Authentication Context is far more powerful than merely describing this aspect of the authentication. Authentication Context gives IDPs and [service providers] a language to discuss many other aspects of the context of the authentication, including:
* The initial user identification mechanisms (for example, face-to-face, online, shared secret).
* The mechanisms for minimizing compromise of credentials (for example, credential renewal frequency, client-side key generation).
* The mechanisms for storing and protecting credentials (for example, smart card, password rules).
* The authentication mechanism or method (for example, password, certificate-based SSL).”
Use of the AuthnContext element can be seen in Sun’s documentation for SAML implementation in Java. For the true specification wonks among you, you might wish to read “Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0”, all 70 pages of it.
But for today, the introduction should be sufficient: “If a relying party is to rely on the authentication of a principal by an authentication authority, the relying party may require information additional to the assertion itself in order to assess the level of confidence they can place in that assertion. This specification defines an XML Schema for the creation of Authentication Context declarations - XML documents that allow the authentication authority to provide to the relying party this additional information. Additionally, this specification defines a number of Authentication Context classes; categories into which many Authentication Context declarations will fall, thereby simplifying their interpretation.”
In other words, the relying party may require any information about the context of the authentication (i.e., who, what, when, why and how!) that could reasonably be expected to be available, or acquired.
If there are any vendors out there who can provide more than simply the method of authentication as part of the transaction, who can provide details of the context and do so within the AuthnContext element, let me know about it and I’ll tell the world that you have built a better mousetrap. And I’ll lead them up the path to your door.