I recently completed reading
Stefan Brands post reviewing Liberty's
“Circles of Trust: The Implications of EU Data Protection and Privacy Law for Establishing a Legal Framework for Identity Federation“.
First, I'm thankful for the review. External commentary is extremely valuable, as those of us working on these problems in standards bodies crave new input. I think some clarifications, however, are required for proper analysis of the
Liberty Specification suite. This review results in two recommendations:
- User-centric data flows for directing (properly authenticated and protected) identity and attribute assertions through the data subjects themselves in a manner that gives each data subject fine-grained selective disclosure capability over identity and attribute assertions made about him or her, and
- Genuine privacy-preserving authentication technologies – as opposed to the current smoke-and-mirrors “pseudonyms” of Liberty Alliance, which are not pseudonyms at all but centrally assigned aliases.
The primary error in this analysis (and thus the resulting recommendations) is some presumption of the locations/ownership of the architectural elements:
+ Service Providers [SP] (who rely on assertions from a trusted party),
+ Identity Providers [IDP] (who may or may not be an 'anchor' of trust in the network),
+ Attribute Authorities [AA] (who may be trusted by the principal for managing their data 'at-rest' and 'in-motion')
These entities in fact can (and do) express themselves into networks in many ways. While it is true that in one form, the IDP and AP may be operated by institutional bodies (corporations, governments, public trusts, etc...), it is equally true that a principal can control these functions themselves, on their own terms, with their own policies, even on their own hosts. In addition, it is likely that a single principal will have many attribute authorities, even for a single service type, creating distributed data-web's. Implimentations may choose from many deployment paradigms.
This satisfies the first recommendation, and can be implemented using current versions of the Liberty Alliance Specifications suite ID-WSF 1.x in conjunction with
SAML v2.0 (as a footnote, the panoptic discussion is more properly placed with the
OASIS SSTC, rather than Liberty).
Of course, there are negative privacy consequences when everything (authentication and attribute assertions) are sourced from a single point. Most notably, triangulation of the subject of these assertions due to single points of origin.
Further, user control of some attributes will be inappropriate. Attributes which are assigned to a principal such as credit cards (card issuing bank is the authority), identification numbers (governments assign drivers license numbers), and health care records (which are create and maintained by health care providers). Relying parties of such assertions a better served by assertions from the assignment authority, rather than some measure of confidence that the principal is stating fact.
To the topic of pseudonym manufacture, thus, clearly given a deployment described above, where the principal themselves may choose to operate their own authentication service (perhaps populated with security tokens obtained from elsewhere or locally). This would then satisfy the second observation.
I'm greatful for you pointing these things out, as it underscores just how composable the framework has become. The wonderful thing about open standards... everyone can read, review, comment, implement and deploy upon them, and are encouraged to do so.
Technorati Identity tag
