EIC 2010: Kim Cameron on Minimal Disclosure
Federated Discovery meets Minimal Disclosure
Mortal enemies or soul mates?
Good and bad news: He never spoke about this yet.
Claims in the enterprise are a done deal!
Of course there are some details, e.g. how you deploy them etc. But in general it’s an irreversable process. We need to go across platforms and applications and enterprises (in the cloud).
The way we do this is via the claims metasystem.
The standards are widely accepted, a lot of interop testing, all of the industry support claims.
Microsoft ADFS 2.0 will be released tomorrow! Many deployments under way in private enterprises and government (will be part of Active Directory)
We can say that claims as being counted on as being part of the infrastructure.
The next version Sharepoint also moved on to a claims based infrastructure. You do not need to define combinations of permissions and people. Instead you have a claim picker.
The power of claims will do the rest
Cloud and Claims
Clouds project claims into the forefront. You cannot do cloud without claims.
You cannot do this without federated directory though. Make it work across platforms and devices, across applications and between individual enterprises and the cloud.
We need a directory metasystems which works everywhere. We need a shared datamodel, protocols and so on.
Before it’s being able to work in this different scales without administered each scale, it needs to be administered via policies.
We need simple APIs integrated with the developer platform
He does not want to say that we need a single API like LDAP, that was a mistake.
Federated interscalar directory
Use Case: Cell Phone to Enterprise Directory
All employees and their phone numbers available when phone is unlocked (but no other information). But we need selection and not the whole thing.
Peers all reports and management chain available on the phone, including titles, relationship, phone and email. But it all needs to be synced, not only exported once!
Phone aware of service access points for it’s owner’s servcie (e.g. location servies, unified communication). So not only people.
Use Case: Departmental Directory to Enterprise Directory
Department directory kept up to date with information on employees
Authoritative within the department for Sales Contacts and automatically kept up to date through subscriptions to the contacts directory
Contact Phone numbers replicated to employee cell phones but disappear if phone is lost or employee leaves.
Use Case: Cell Phone to Cloud Directory
All my contacts – regardless of whcih social network we share – are available and stay upü to date on my cell phone
I can create personal groups crossing enterprise and social networking boundaries which are available in unified ciommunications, phone, mail, etc.
Use Case: Email running in the cloud
Use Case: Cloud based spam filter
They only want to outsource spam but not email. But for this usually you have to outsource all group memberships.
There is no need for that in case we have the right directory structure. Use federation at the minimal level!
Use Case: Merger and acquisition
Use Case: Change of role or identifier
I can change role or even identifier and retain access to previous resources if that is permitted by policy (eleminate the pain currently felt in moving from one domain to another)
Use case: Complex queries
Use the queries possible on databases but use them on directories
Use Case: New applications don’t threaten old ones
Use Case: Application Developer portability
Run an app either on cloud or locally, there should be no difference
Use Case: Every applicaton developer can use the directory
We have a strange protocol right now which only 2000 people in the world understand. we need to have more up-to-date approach to program to the directory. We need applications which are able to run in multiple directories.
Federated directory requirements
New features and data models required!
Support for Relationships (e.g. NOT simply a hierarchy model)
…
They tried to create a new schema which all people in MS could agree on. No easy task.
He wants to show this schema to the industry and get feedback.
Evolving Active Directroy
It will clamp on AD, it is not a replacement like ADFS does today
Implications on privacy and data protection
Person’s need to traverse contexts vs. Person’s need for “contextual separation”.
Is privacy a blocker for future directory development
Minimal Disclosure Mechanism
Example: Alice wants to prove that she is over 21 but she does not want to give out more information.
With this system she can take that statement and “block out” all the other information in the token. She can also convert the dob into an age. This is sent to the RP which only gets this information.
Minimal Disclosure Scenarios
You disclose only what’s necessary for a transaction.
Example: I lost birth cert but have my eID card.
The RP can ask: Give me your name, DOB and address. In this case this is still minimal disclosure.
Another example: I am going to a dating site and want to know if somebody really is of the age they say.
Once again I am going to make a claim but do not give my name away at first. The information is just gender, >21 is true.
All other information is again cryptographically blocked from view for the RP.
What protection mechanisms can be used by Federated Directory?
We need to institute the right to be forgotten.
How can the requirements be enforced? Only legally.
Call to action: Begin discussion on what the next generation data model can look like and whether it is something which can be standardized.
Question: Is this a replacement of LDAP?
Answer: Time goes on but LDAP will also not go away. Infrastructure we have stays. As he explained it might be the underlying technology.
(this transcript might not be correct, any corrections are welcome!)
