AuthenticationWorld Blog

At the Burton Conference last week in San Francisco, I watched several presentations predicting what the future of identity would look like. Dick Hardt, of Sxip, gave a good presentation where he outlined how a person in 2017 would be able to have multiple digital personas, work and live electronically in a seamless world. While all this made sense at the general level, I felt that something was missing in the pieces of the identity puzzle in order to make this happen. That's what this blog will cover.

In order for a person to work seamlessly electronically, there needs to be open protocol standards for documents that also seamlessly ties to open protocols for access control. The world of work involves accessing, viewing, editing and moving around all sorts of different types of documents/digital files. Today, there is no way to do this across different vendors and enterprises who are currently using silo'd document management systems.

There are emerging standards for document management vendors to deal with Microsoft's Sharepoint. This requires however that Sharepoint be involved in the document interchange which won't always be the case.

There are also emerging document management protocols for dealing on the Java side of the world. However, this doesn't cover the .Net side of the equation.

Both of the above efforts also don't integrate with an open access control standard.

So...this is the major gap in getting from where we are today to the future that Dick outlined in his presentation. What is the solution? I believe that the way forward is for development of a new, open, document management protocol that in turn integrates with XACML.

For example, let's say that Jane Doe in the future wants to access her health records. Jane by the way is old. Thus many of her health records are scanned images of previous documents. As Jane uses an online interface, the document management system used first of all checks the required privileges for the documents. It determines that the identity Jane Doe can access the records. Further, it determines that no one can edit or change the documents and then determines that the documents require a digital signature plus a password from Jane in order to access the documents.

Jane has an InfoCard that contains her digital signature and password. Using XACML, Jane provides her InfoCard to the document management system and then is able to view her scanned health documents.

This system also works between enterprises. Let's say that John Smith is working on a project where his enterprise Acme is in partnership with another enterprise named Zeon. Acme and Zeon use different document management vendors.

John wants to send Zeon some documents. These include a Word contract, an Excel spreadhseet as well as some engineering CAD files. John clicks on the document management system in Acme. He then indicates he wants to send these files to Zeon. The document management system first determines the document management properties for each of the documents. It sees that the contract and CAD have high security around them. Further, it also sees that the CAD file must expire in 30 days when outside the enterprise. Finally, it also sees that a full audit trail is required for the CAD and Word documents.

The document management system then using XACML, checks to see if the person John is wanting to send in Zeon has the required privileges. Seeing it does, it then encrypts the sensitive documents and sends them to Zeon.

Zeon, takes the documents in and automatically enforces the security policies that Acme had set up for the documents. After 30 days, the CAD file is disabled on Zeon's system. Only those Zeon personal with the required privileges are able to open, view and edit the documents. Whenever the CAD and Word files are accessed, Zeon's document management system maintains a complete audit trail. This may or may not be sent on an updated basis to Acme depending on the agreement the two enterprises have re audit logs.

The future requires open document management protocols that takes into account many different digital file types. Not everything can or will be converted to XML. Further, the protocol must interface with XACML to ensure that there is seamless enforcement and use of access control policies tied to the identities.

I believe that this is the future of digital rights management. By being able to specify the privileges and security policies for any digital file and then tying this to XACML, it opens up the digital world.

Comments? I am beginning to assemble a group of like minded individuals and enterprises who want to see this happen. If you're reading this blog and are interested, please contact me.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

Bob Blakely at Catalyst last week gave an excellent presentation on secrecy. His main message "Secrecy - get over it since the battle is already lost". He rightfully maintains that in today's world there is no secrecy since just about every action is captured somewhere digitally and then is accessible by the public, private or government enterprises in one way or another.

One of Bob's main points was that in order to provide control over this environment it requires transparency and accountability in order to offer the individual privacy. As Bob always says, secrecy does not equal privacy.

With this thought in mind, I will take up a point about identity registration and apply Bob's principles to this.

One of the main weak spots in today's digital world is the lack of ties of an official identity credential to the identity physically. While it is true that many instances of identity don't require official recognition (thus using different personas), in some cases there is the need for tying an identity to a real person at the legal level.

The four main ways of doing this today are:
* Birth certificate
* Name registry
* Passport
* Driver's license

A birth certificate is a record of birth However, it does not tie the individual holding the birth certificate claiming to be the identity to the physical identity. Further, the use of forgery to obtain these documents is quite common. Therefore, while this form of identification is used to tie the identity to the person, it is unreliable.

The name registry that governments run, legally defines the names that apply to an individual. However, these registries use identity registration types like birth certificates and passport to confirm the individual applying for the name change is who they claim to be. As this blog will explain, these certificates don't tie the individual holding them to the physical identity. Thus, a name registry has little use in tying an identity claiming to be someone to the actual physical identity.

A passport is a device where there is usually more importance attached to it to verify that the person who is holding the passport is the physical person they claim to be. Normally, a birth certificate or driver's license is required to apply for a passport as well as providing professional people as references. Then the police do a background check to ensure the identity has no criminal record. However, there is no actual way that ties the passport physically to the holder of the passport. If they have a birth certificate, proof of citzenship and have references and no criminal record, then the passport is issued. It does not tie directly to the physical person, only to the tokens they presented.

A driver's license is a token that has become a key identity token. This is because most people now have a driver's license and, it is easily searchable. The driver's license is obtained by providing identity tokens like a birth certificate and a passport. The actual token therefore doesn't tie the individual holding the token physically to the token.

From a legal perspective, the whole identity system is built on a house of cards (tokens). People wanting to establish a high degree of legal trust with an identity assume that the person has used bonafide tokens which hopefully mean that the person is who they say they are.

Looking ahead to the future I can see identity registration becoming much more troubled. Cloning people is going to occur. As we have done with sheep and other mammals, the day is fast approaching when human cloning becomes fact rather than fiction. Then determining who is who becomes much more difficult.

From a scientific perspective, the answer is to use DNA and biometric fingerprints to differentiate one person from another. DNA works in all cases except for genetic twins. In these cases digital fingerprints can differentiate one person from another.

I proposed in a draft paper I wrote last year that a new identity registration system be used that ties an individual to their DNA and fingerprints. I further proposed that this system be run by the governments as a new birth and naming record agency.

This proposal was met with much criticism since many people didn't want a "centralized" source of identity information that the government runs. Using Bob's principles I want to apply them to what I am proposing versus the "fear" factor that my original paper was met with.

First, I am proposing that the identity's national birth and name registry information only be searchable with the consent of the identity. This means that every time someone or an enterprise wants to do a search on the identity, the individual must provide consent.

Compare this to today's world where at no time do you know who is doing a search on your passport, driver's license, birth or name records. By putting control in the hands of the individual it provides transparency to the process. Bearing in mind Bob's assertion that secrecy is gone- get over it, I believe that by providing the identity with transparent control over their identity they can have a greater degree of privacy than they currently have now.

In my proposal, the agency monitoring the identity has limited authority. At no time can they interconnect the birth/name registry with other government databases. This puts a high degree of accountability on the registry. The only searches that could be done across the registry would be for instances like a dead body with no name being found and a name wanted for the dead person.

Compare this to today's world. There are several million DNA records on file in both the UK and the USA for criminals. These are constantly being searched by law enforcement agencies without the individual's consent. Then there is the numerous cross-linkages that agencies like the NSA, FBI, CIA and other government agencies run between driver's licenses, tax forms, passports etc. There is little accountability for these agencies from the individuals perspective.

I further proposed that at time of registration, the individual would be given a card that contains a digital certificate embedded within it. Until the age of majority is reached, the legal guardians would control this card after which the individual would control it. This card would work like an identity oracle.

So, let's say that you want to purchase some alcohol. You would walk into the store and swipe your card through a reader. The digital certificate would then be sent to the birth/naming registry. If it matches with the cetificate assigned to you, then a message would be sent to the retail terminal saying that the identity is over the minimum age. BUT, the identity of the individual wouldn't be revealed. The identity oracle, the birth/naming registry, would only confirm that the person holding the card is of the minimum age.

Compare that to today. The person going into the store must show their driver's license with their name, photo Id and birthdate to the retailer. The individual has no control over the retailer seeing more information about them than is necessary.

The token however is open to mis-use by someone other than the card holder swiping the card through the reader. However, this token can actually tie to the true physical identity unlike existing current tokens in use like driver's license.

I also said that if the situation arises where the individual must confirm their true identity for legal purposes (filing a tax claim, etc., when they are arrested, etc.), the individual should approve the process. I proposed that the individual would go to an accepted third party approved by the government where they would provide a DNA and fingerprint sample. The third party would then securely digitize the samples and submit them to the birth/naming registry. The birth/naming registry would then compare to the identity they person is claiming to be. It would then submit a response to the third party agreeing or not that this is the individual. The third party would then attest to the enterprise that the individual is physically who they claim to be.

Finally, I wrote that at any time, the individual can request a list of all searches on their birth/name registry. This puts full accountability in the hands of the individual.

Remember, secrecy is dead. However, PRIVACY ISN'T. By using the principles of transparency and accountability, my proposal is to create a new identity registration system that meets the requirements of the age in which we live. It offers greater privacy than current registration and search systems.

Comments?

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

One of the issues raised at last week's Burton Catalyst conference was the inability of current federation systems to rapidly scale. Mike Neuenschwander gave a presentation where he posed the question "How does an organization connect 70,000 partners in a year?". His line of reasoning was "If adding users requires more admins, it’s broke." This blog will agree in some respects with Mike's position and respectfully disagree in others. I will end by proposing new ways of doing federation models that can scale rapidly.

What are the main components of a federation model?:
* Contractual relationship
* Identity management for the partners
* Testing environment
* Operational monitoring to provide and enforce SLA's and OLA's
* Identity management for the enterprise offering the federation

Let's look in detail at each component.

Contractual relationship
This, in my own personal opinion, is one of the largest hurdles in creating a federation. There are many factors that enterprises must agree to including things like:
Technical - Federation standards, communications security, certification, authentication used, and identity attributes
Policy Management
Audit Requirements
Privacy Policy
Error Handling
Security Requirements
Risk and Liability Limits
Contractual Management
(for more information please read a paper I wrote on this last year "Creating a Federated Authentication Trust")

For many business partners who are much smaller than the enterprise offering the federation service, the contract may be readily agreed to without much thought to the consequences if something goes wrong. Small businesses will agree because they want to do business with the larger enterprise. However, medium and larger businesses may take time in agreeing to the contract and possibly want to negotiate on certain items where they feel the risk is too high for them.

Identity Management for the Partners
Most small and even many medium sized enterprises don't have identity management systems. This poses a distinct problem in federating with a large enterprise who does. Without this, the federation service won't work. In my mind, the next biggest challenge after quickly getting agreement on the contract is trying to get small and medium sized enterprises to implement some form of identity management system which can then provision the identities and establish a federated trust relationship.

Testing Environment
This too can be a big problem in creating rapid federations. Often there may be a significant time lag in getting a partner to agree to the federation and then to get them to test the federation environment. Often times, there may also be a booking factor in getting time to test in the test environment.

Operational Monitoring
Most small and medium sized businesses who are federating with a large partner are at the mercy of the large partner's monitoring systems, since they don't have sophisticated monitoring on their side of the connection. As a result, they are contractually obliged to the monitoring data coming from the large federation.

Identity management for the federation
The large enterprise running the federation usually has good to excellent identity management systems in place. A requirement is that they are able to offer, or capable of offering multiple federation protocols as these develop.

Taking into account all of the above, how can we design a federated trust model that scales rapidly with little human involvement?

In my mind there are two main groups of partners. Small ones who lack infrastructure and contractual knowledge and medium to large ones who have infrastructure and contractual knowledge. Let's examine innovative solutions for the small enterprises. I'll use an example of a company called Acme Inc who has 50,000 partners it wants to federate with, most of them being small enterprises with little or no identity management systems. In the example I'll use a small business partner "Bob Co" to whom it wants to federate. Bob Co has 50 employees.

Small enterprises
Acme doesn't want to spend the time and money helping each of the 45,000 small businesses it wants to partner with establish their identity management systems. However, it needs to assist them in some way or Acme can't realize the benefit of the federated model. As a result, Acme decided to out-source this problem to enterprises who offer innovative identity management solutions. Here's the business process they design for Bob Co.

Bob Co is sent an email outlining the benefit of federating with Acme. As well, Acme sales reps and the Acme call center are also given scripts to use in discussions with Bob Co.

Bob Co's CEO decides it is in his own business interest to pursue this with Acme since he wants their business. He then clicks on a link to Acme's partner website. There he finds numerous online materials describing different parts of the federation trust model. Unfortunately, Bob Co's CEO doesn't read these. Instead he immediately clicks on the "Let's Get Started Link".

He is then presented with a online form. After entering in his company information, the form then checks the Acme partner database and calls up the information about Bob Co. After agreeing that this is his company, the form then changes. It now asks Bob Co's CEO a starting question:
"Does your company have an identity management system?"

Since Bob Co's CEO doesn't even know what an identity management system is, he clicks on a button "Explain to me what this means". He is then given a quick two minute tutorial on what an identity management system is. After returning to the main screen, he then clicks "No" as the answer to the question.

The screen then changes. It now asks him if he is running a Window's network? If so, it then asks him what version of software (e.g. NT, XP, Win 2000, Vista). Since Bob isn't sure he saves the form and then goes to get his answer.

He returns and then enters NT. At this point the screen then connects him to a choice of outsourced identity management providers. These use a combination of outsourced identity management tools that Bob Co can use. Their pricing is by the number of users. Therefore, Bob Co's CEO has a choice of options for as little as 10-20$ month that will start him off with a manual identity entry and also provide him with the outsourced authentication and federation trust management. Bob Co's CEO can click on a link and immediately talk to the outsourced provider's staff who can step him through the questions.

Note that if Bob Co already had an AD directory or an existing database of identities (like payroll), the outsourced identity management provider might try and use a virtual directory to tie to the identities.

The main point I am making is that Acme has outsourced the identity management problem to a new type of enterprise offering innovating solutions, at low cost, to small and medium sized enterprises. For a very low cost, Bob Co can manually enter in their employees online, have this automatically placed in a directory, authenticate to the directory and have it automatically take care of the federation trust. Further, the outsourced provider can also use monitoring tools to ensure that the SLA's and OLA's are met in the contractual agreement that Bob Co is signing with Acme. Bob Co doesn't have to know anything about identity management. They just consume the services.

Note: This new type of enterprise service offering is just beginning. It doesn't exist yet in most countries since the demand hasn't been there. I believe that if Acme and other like minded large enterprises want this as a requirement to do federation that this type of service offering will quickly grow.

When Bob Co's CEO has completed the identity management question on the form, he is now provided with the contract and a click here to agree to it. If he has any questions about the contract, he can click on the "Contract Questions" link. This will take him to various online materials about the contract and answers to specific questions about each component of the contract.

If Bob Co's CEO doesn't like the contract, he can then click on a button indicating he won't sign the contract. Now he is routed to the Acme Federation Team's legal experts to have more discussions.

Assuming that Bob Co's CEO accepts the contract he can now move to testing. Since he is small and is using one of the identity management outsourcers, he doesn't have to test since the outsourcer already has tested against the Acme interface. In this case, Bob Co's CEO proceeds on in the form.

He clicks a button agreeing to all terms and conditions and is immediately activated with Acme for federation. He logs on to his outsourced identity service and clicks on an Acme link on his web page. He is immediately federated with Acme.

Medium to large enterprises
These enterprises start by using the same form that Bob Co used. However, when they indicate their enterprise name and say that they have an identity management system, the form changes. Now they are asked many specific questions about their identity systems. If at any time they are confused, they can click on a "Identity Assistance" button. This will take them to online resources explaining what the questions mean (e.g. identity attributes, authentication strength, etc.). If they are still confused, they can click on a button "Live Assistance"). This will take them to an Acme call center. There the person will either use text and or voice to assist the enterprise with their questions. Any questions which the call center can't answer are then referred to the Acme Federation Trust team.

When the federation partner agrees that they can complete the identity management system requirements, their online form then asks them to approve the contract. As with Bob Co, the enterprise can review the contract and click on buttons explaining different parts of the contract. If they have trouble in coming to agreement with the contract, they will click on a button and be referred to an Acme Federation legal expert. On the other hand, if they click that they will accept the contract, then they will be taken to the testing section of the form.

Here the form provides the federation partner with test tools that can be done offline to speed up the process. As well, Acme also has capacity planning test data available to show the partner that they have done this testing already. By using offline testing, this speeds up the test environment process. As well, they can automatically book times for the test environment. Acme has used virtual environments to create a test environment where the throughput capacity of many clients doing testing can be done quickly and inexpensively.

When the partner is ready, they click on a button and they are activated for federation.

In Summary

The model I have described above is a scalable federation trust model. It uses automation and online materials wherever possible to educate and answer questions in advance. However, it also recognizes that there are times where human assistance is required. In these cases, it uses low cost human assistance, like a call centre to answer basic questions. It then uses higher cost assistance, like the Acme Federation Trust team where their expertise is required.

Further, the model outsources those areas where Acme's time and expertise isn't valuable. Thus Bob Co can deal with an outsourcer, either online and/or directly, to establish a low cost, low maintenance, identity management system sufficient to allow them to federate with Acme. The outsourcer service will range from a bare bone, manual identity entry system, to the use of virtual directories tied into the partners' databases and directories.

Acme also uses innovative test tools and environments to quickly process partners through the system. Many small partners will skip this test as the outsources have already tested the Acme federation environment. Where medium to large enterprises want to do their testing, Acme offers tools to do testing offline and also made a large number of test environments available virtually, which are bookable online, to keep the throughput high.

Mike's presentation last week at Burton was good in raising the points about scalability. However I thought it lacked a real world implementation perspective. Most of the 70,000 businesses in his question are identity neophytes. Further, they don't want to know that much about it. It is this group that requires new innovative services to provide them with the basic infrastructure, at low cost, to enable them to participate in an identity federation. I believe that it is only by outsourcing the problem and turning it into a commercial opportunity that the scalability can be acheived.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

One of the challenges facing enterprises is how to make available information that is sitting in enterprise silos while at the same time ensuring that the information is seen by those who are approved to see it. As big search engines move into the enterprise, this challenge becomes very important.

A large search engine company like Google, Yahoo or Microsoft could write unique API's for every document management vendor out there. The API's could then interpret the document management policy rules for each document and then determine which documents to show the user doing the search. However, this becomes extremely expensive to do and maintain.

I believe that in order to free up enterprise information, the search engine companies need to consider helping create a document management/digital rights management protocol that integrates with XACML. Why?

If there was a common XML schema defining document management types and a way to communicate document management policies that tie to the identity, the enterprise would now have a way to deploy search engines internally quickly and inexpensively. For example let's say that Guy is an employee of Acme Inc. They have eight different document management systems within Acme.

Guy does a search for "Widget X" using the search engine tool. The search engine uses the document management protocol to communicate with each of the eight document management systems. Let's say that there are hits for the search term "Widget X" in three of the document management systems. The document management systems would then communicate with the search engine.

One of the hits is viewable by anyone within the enterprise. So, in this case, the document management system would, via the document management protocol, let the search engine know that it can display this hit to Guy, since he is an employee of Acme.

The second hit is for a more sensitive document on Widget X. It requires that Guy use his digital cert to open it. In this case, the document management system communicates with the search engine via the protocol. The search engine shows the header of the document. When Guy tries to open the document, the search engine prompts Guy for his digital cert using XACML.

The third hit document is top secret. Only a limited number of people on an access control list are able to view the document. The search engine uses the document management protocol and XACML to see if Guy is on the list. He isn't. Therefore, depending on how Acme has customized the search engine, it may not show Guy that the document exists or, it may show a header and indicate that Guy needs to talk to his superiors in order to access the document.

We need a way to inter-operate quickly, inexpensively and with the appropriate security when freeing up information contained within enterprise silos. In my own view, this requires a new document management protocol that integrates with XACML. With this, the digital future beckons.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

You can access on-line the draft discussion use cases document I have created for a new document management/digital rights management protocol that integrates with XACML.

In discussions with Phil Hunt from Oracle on Friday, we discussed whether this can be done by getting an open source project put together. We also discussed whether what I am after can be done by extending XACML polices or, creating new profiles or by creating a new protocol. I am agreeable to any of this, assuming we can get enough support to back this and, assuring ourselves that whatever course we take will achieve the end results.

Please read over the two blogs I have previously written about this ("Future of Identity" and "Search Engines and a Document Management Protocol that integrates with XACML") and the use cases and then let me know what you think. If you like the general idea I am presenting, then please forward this blog to friends, colleagues and customers for comment, criticism and interest.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com

One of the things I have noticed is the fact that while many large enterprises have deployed provisioning systems, the actual number of the enterprise applications integrated to the provisioning system is low. This blog will discuss the reasons for this and a solution I call the "Provisioning Factory".

So, why is it quite common to not have integrated that many applications into the provisioning system?
* A prior management belief that the "provisioning product" will somehow miraculously integrate the applications
* Lack of a dedicated management/implementation team focussed on integrating applications (it's often that this is one of many responsibilities an IT team had)
* Lack of communication and understanding of the line business processes and problems that automatic provisioning might solve
* Challenges and costs in creating connectors to various applications (especially home-grown ones)
* No business process people on the provisioning team, only technical experts
* Lack of testing environments for the provisioning process (limits thoughput)
* Few or no tools to help educate application owners on why integrating with a provisioning system is a good idea
* Lack of a budget to integrate applications

Does this sound familiar in your enterprise? If so, then it's time to create a "Provisioning Factory Model".

The place to begin is with senior management. They have to be educated as to the business benefits, security benefits and process improvements by widely deploying a provisioning factory model. There has to be a commitment by the senior manager to support a wide integration as well as providing the necessary budget to accomplish this. All too often senior management has been sold a bill of goods for provisioning without the proper budget and support system in place to actually accomplish the goal once the initial implementation is done.

The management team then needs to make a list of the top 100 applications that need to be integrated. These applications need to be graded on the type, time and cost of developing connectors, the business process changes, the business unit buy-in to this process, the application owner's buy-in to this process and the type of testing required.

Next it's time to create three to four business process streams for the provisioning factory. One stream is for applications where connectors already exist and for which little change needs to be done to the workflows and the roles. Application owners need to be provided with on-line resource materials telling them what the process will be as well as answering questions like test environments, who to contact, etc. Their "speed" through the factory should be very quick.

Another stream needs to be in place for applications where there is a connector but for which business process reengineering is required and/or role based access control changes put in place. Depending on the provisoning tool you use, you may need to be more or less work in order to discover which roles and identities are using the application. The application owner needs to fill in an on-line form that asks them all sorts of questions about their users and current business flows for on and off-boarding. Then a team provisioning expert needs to contact the app owner to examine the work required.

There also needs to be a stream created for applications which don't have a connector. This stream will have several sub-streams. After filling in an on-line form, the app owner will be contacted by a team provisioning expert. One sub-stream will exist for those aps which can be quickly integrated with little work. Other sub-streams will exist for those apps which require business process engineering or role based access control, etc.

The team needs to prioritize their work. Some of the work may be out-sourced to lower cost providers (e.g. connector development).

The team needs to have experts in connector development, business process re-engineering, security, testing and change management.

By applying this factory model to provisioning, it is possible to integrate hundreds of applications per year.

Guy
www.authenticationworld.com
guy.huntington@authenticationworld.com