Sunday, April 29, 2007

Consent Context Markup Language

How tricky/tough/political would it be for proponents of various identity systems to agree on how to phrase a consent query, if not necessarily how/where/when to present such a query to users? As trivial as picking the text for

"X is asking for Y, wadda ya think?"

Beyond the simple yes/no, accept/deny, proceed/stop options (I've seen them all), there could be agreement on phrasing of the 'remember this decision' prompt and its options.

Alternatively (and far more work), how about a CCML 'Consent Context Markup Language' - a syntax describing how consent was obtained, comparable to SAML's Authentication Context and OpenID's Authentication Quality Extension for describing how authentication occurred.

Quick list of contexts.
  • Who obtained consent? For what?
  • How was the question phrased (as per above)?
  • How was the question presented, e.g. by directly asking the user when they were 'at' the provider, or indirectly a la Liberty's Interaction Service , or by direct user-mediation of the flow a la Cardspace or SAML ECP? (hopefully avoiding the complexity of describing authentication because there would be no temptation to try and say that one consent mechanism was 'better' than another for ranking.)
  • When was consent obtained, e.g. a priori, real-time?
Basic W5 stuff.

Of course, the question is who would care? It would be the provider making the access control decision for a particular bit of identity that would need to know about consent, so in what scenarios is it relevant for the details of said consent to be recorded? Audit would be one. Supporting a 'User Dashboard' where a user can see past identity transactions (and the specifics of the corresponding consent) would be another.

No identity system does this, so nobody should (you'd think) have resistance to collaborating.


Anonymous said...

Paul -
One way to achieve this would be - as far as I can see - by using the policy system in XACML. THis way the user could initially formulate a privacy policy which could then get matched to the SP policy. So for instance, the SP asks for Name, SSN, DOB - or - Name, SSN, Address - or - Name, Address, valid Credit Card number (order could indicate preference). The User policy might want to restrict the SSN, but be happy to disclose Address and Credit Card.
Is this what you are after?

Paul Madsen said...

Hi Gerald, I wasn't thinking of how the user's prefs are captured, reconciled, etc, XACML could well serve for that. Rather I was imagining a syntax for capturing the various permutations by which consent can be captured. So, descriptive as opposed to restrictive.