Guest Blog: Reaching the Age of Consent

In the past year, consent for the release of attributes, and more generally for personal information items, has become a highly active area of Internet identity. Drivers are numerous, including GDPR, the new draft of NIST 800-63-3, and the challenges R&E federations are facing in attribute release. While policy regulations such as GDPR typically are protocol neutral, the technical approaches to date have been protocol specific. While the requirements are universal, the implementations tend to weld in local considerations and have scale issues. And while regulations have some specificity, they lack the “case law” that provides the necessary level of practical detail to properly be compliant to the regulation. Fortunately, each of these consent areas, and others that will permit the flow of information while appropriately and effectively protecting user privacy, are now being worked on.

It should be noted that consent is not a universal panacea; indeed, some regulations state use cases where consent is explicitly not permitted. But where consent is necessary or helpful, there is a growing focus on not just an act of consent, but the “quality” of that consent. There is a common set of such characteristics, including revocation, fine-grain attribute release choices, use of appropriate identifiers, increased emphasis on usability, and other privacy preserving techniques that quality consent needs to meet. And from a UX perspective, that quality consent experience should be similar regardless of protocol or platform, and their preferences should be portable across devices, and, ultimately, identity providers.

The use cases for consent drive an architecture that can combine both individual user choices and organizational/regulatory preferences into a flexible decision point that makes the ultimate decision on what attributes are released. That decision point interacts with the user via a well-engineered interface, one that is adaptive across devices. Consent receipts can be issued from that decision point as a part of a notification service, one that can likely leverage nascent work in SEC-events in IETF.

It is somewhat straightforward to implement a consent-informed attribute release system that reflects the above architecture and meets the use cases. The challenge lies in providing the “Informed content” – the information that a user might need to make effective decisions. It includes logos for IdP and RP, determinations and explanations of required and optional attributes, friendly descriptions of attribute names and values, pointers to relevant privacy policies, revocation capabilities, etc. This fuel to drive informed consent machinery at technical and user levels is currently scattered and strewn, when it exists at all.

In the multi-lateral federations, some of that information can be found in the federated metadata. Other scraps of informed content may be at well-known URI’s, or resolvable from the attribute name. Software or metadata statements in OpenID Connect may be a vehicle for carrying some content in that landscape.

Creating informed content will not be easy. For example, determining required versus optional attributes (aka data minimization) will require a shared sense within a community of what minimal functionality for an application might be. And while human-readable syntax attribute names have been at least discussed in some venues, the challenge of creating human-readable syntax and semantics for the values those attributes take is formidable. In some cases, such as group memberships, the set of possible attribute values is unbounded, if controlled. Add needs for internationalization, localization, etc. and it is clear that much needs to be done.

But the work will be done. Consent is becoming a critical tool in the identity kit. The drivers are moving the need along. None of the remaining challenges are intractable. But, to serve the gods of scale, we will need to work together for rough consensus and common practice.


Ken Klingenstein