Continuing the discussion on DisplayTokens [LINK] :
A number of you have emailed me directly and some have commented publicly with some thoughtful insight and I thank you for that. Vittorio has written a very thoughtful and detailed response on his own blog [LINK].
Going back to my original question which was "Does the DisplayToken violate the First Law of Identity?" I am not convinced it does. What I think I am discovering is that the First Law of Identity is not necessarily enforced.
In Kim’s words[LINK]
"Those of us who work on or with identity systems need to obey the Laws of Identity."
For me, being Irish Catholic (and riddled with guilt as a result) I take a very hard-line approach when you start talking about "Laws". For example, I expect the Law of Gravity to be obeyed. I don’t view it as a "Recommendation for the Correct Implementation of Gravity". And the Universe assures me in large part that gravity will be obeyed right? Well for the most part, but you get my point.
So rather than a recommendation around user control and consent; I would rather it be obeyed and enforced by the protocol. Here’s where things get tricky as we’re trying to implement an Identity Meta-System and today, as Vittorio says, I may have a "coconut token" and tomorrow I might have some other token format.
Will the paradigm of RST/RSTR exchange change? Probably no, or not much.
Is there any dependency between the RST and the RSTR today? This I was surprised to learn is a "No".
What I think would solve the issue in some small part is to tie the RST to the RSTR in such a way that the STS cannot possibly generate an RSTR that includes claims other than what the RST requested.
How to support user consent?
To have user consent, the user needs to see what’s being said about them. So again I think you need to tie the DisplayToken to the RST or RSTR somehow.
Now, what about privacy?
That’s a tricky one and likely not 100% solvable but the approach of masking out aspects of the data seems to be what most people (Matt Ellis) suggest when I ask this question. I don’t think it scales.
Today we mask out credit card numbers, providing only the last 4 digits. In other scenarios we mask out social security numbers again with the last 4 digits. Nowadays the combination of birthdate, zip-code and Surname "marketers can uniquely identify almost the whole population" [LINK].
Will the Displaytoken mask out these values also? will we end up with a DisplayToken that looks like this:
First Name: ****cis
Last Name: *****han
Date of Birth: *1/*1/*2
Zip Code: ***69
Huh??? This could get confusing right? And does it work long-term? No. Even today, in many cases folks DON’T NEED your social security number, they only need the LAST FOUR DIGITS!!!
As EJNorman on Vittorio’s blog states; "The question is: why shouldn’t a user be able to inspect what’s being said about him and sent to a relying party to verify that it’s what was expected?"
I think this is at the crux of Law #1. Control and consent right? If a user can’t see what’s being said about them they just have to trust the IdP’s STS. Anytime you "trust" you give up "control", no?
It seems to me that if we are to ask users to "trust" the IdP then we are headed towards establishing a rating or assurance level around the notion of an Identity Provider. Just as not all STSs are IdPs and not all certificate authorities are high-assurance certificate authorities, not all IdPs will be well implemented, reputible or trust-worthy IdPs. The reasons for this are not all malicious as I earlier stated:
- An STS may unwittingly pump in claims into an RSTR without looking at the RST.
- As Vittorio points out; an STS may choose not to verify the credentials in the RST
- Without authentication, an STS might just give out tokens to any RP on your behalf (chances are very low and this IdP would go out of business fast).
The possibility of these things happening is there as the protocol allows it.
Coders/developers on the front line take the path of least resistance almost ALWAYS. Code and ship. If there’s a way to implement something that’ll get the RST/RSTR exchange working with an RP and IdP that doesn’t enforce or prevent 1,2,3 as listed above then my fear is we will end up with IdPs out there that are not well implemented and as a user, we will have little to no way of detecting the good IdPs from the bad.
One way to work towards a solution is to have more heads looking at this across both the TECHNOLOGY (Ws-Trust/Ws-Fed etc.) as well as the HUMAN ASPECT (Identity Laws).
I’m not sure how to solve this. I’m not sure if it’s a fault inherent in the Identity Meta-system or if it’s just a fact of life we have to live with.
I would never want to put the elegance of a meta-system design and accommodation of potential future token types ahead of supporting Law #1.
I think I need to think about this some more…but I feel like I’m getting it.