On Friday I had a demo of PLOA – Personal Levels of Assurance — from it’s architect, Jay Glasgow at AT&T. I’ve known Jay since he attended an XDI retreat hosted by Scott David at Whistler two years ago, and at that retreat I learned just how deeply Jay was thinking about the problems of federated identity and user-centric identity. Which is to say, plenty.

PLOA is the outcome of Jay’s analysis about how a large identity provider (IdP) like AT&T should go about providing not just a user-centric identity system, but a developer-friendly and relying party-friendly system (relying parties being the sites that actually need the identity assurance). There’s an entire white paper about it on the Open Identity Exchange site, of which AT&T is an executive member.

But the biggest challenge with PLOA has been that it’s a worldview shift about how identity assurance really needs to work. As such, it solves so many related problems together that it’s hard to sum it up in a nutshell the same way you can for OpenID (“lets you use one username and password across all OpenID-enabled sites”) or OAuth (“lets you give access to your private stuff online without giving out your password”).

After seeing Jay’s demo, the lightbulb finally hit for me: PLOA is Need to know for assurance. It’s a clear way for any relying party to find out just what they need to know about any particular user — for any particular interaction/transaction in any particular context — in as lightweight and user-friendly a way as possible. It does this by:

1. Decoupling assurance — what a relying party needs to know ABOUT you — from authentication — the act of proving you have a valid identity credential.
2. Standardizing how a relying party can ask a third party (the IdP) for just what it needs to know about you to give you the service you are requesting – nothing more.
3. Standardizing how the IdP — and the application developer creating the user experience — can obtain the necessary assurance data needed from you if it doesn’t already have it.
4. Giving you complete control over this process, so you can revoke the assurance data and permissions you have given to IdPs if you want to.

By breaking down assurance into small, discrete, bite-size chunks, each of which is transparent and subject to user permission, PLOA makes identity assurance lightweight, modular, contextual, and privacy-friendly.

That’s a good thing. Now what PLOA needs is:

1. Binding to a standard wire protocol, e.g., JSON over HTTP/S.
2. Publishing by a standards body.
3. Adoption adoption adoption.

Jay knows I believe PLOA is a great fit for the XDI protocol, since the main XDI binding is JSON over HTTP/S, and sending/receiving XDI triples in JSON is about as lightweight and modular as it gets. But that’s just one of many options for a PLOA protocol.

From my perspective, what’s exciting about PLOA is that it’s a perfect fit for where we are headed with the Respect Network (more about that coming soon — for now just see the Respect Trust Framework). So keep an eye on it – for identity assurance, it’s just what you need to know.

UPDATE: Jay advises me that he will be giving demos of PLOA at two upcoming AT&T meetings in NYC on April 19 and NOLA on May 7.