Minutes for the face-to-face meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee
June 14, 2012
1. Call to Order and Welcome.
2. Roll Call
Attending (please notify me if you attended the meeting but are not on the list below)
Abbie Barbir, Bank of America - y |
Anil Saldhana, Red Hat Bob Sunday |
Brendan Peter, CA Technologies |
Carl Mattocks, Bofa |
Cathy Tilton, Daon Charline Duccans, DHS |
Duane DeCouteau |
Colin Wallis, New Zealand Government |
Dale Rickards, Verizon Business - y |
David Brossard, Axiomatics |
Dazza Greenwood |
Debbie Bucci, NIH |
Deborah Steckroth, RouteOne LLC |
Detlef Huehnlein, Federal Office for Information |
Don Thibeau, Open Identity Exchange |
Doron Cohen, SafeNet |
Doron Grinstein, BiTKOO Gershon Janssen – y |
Ivonne Thomas, Hasso Plattner Institute |
Jaap Kuipers, Amsterdam |
Jeff Broburg, CA |
John Bradley |
John "Mike" Davis, Veteran's Affairs |
John Walsh, Sypris Electronics |
Jonas Hogberg |
Julian Hamersley, Adv Micro Devices |
Kevin Mangold, NIST Lucy Lynch ISOC |
Marcus Streets, Thales e-Security |
Marty Schleiff, The Boeing Company |
Mary Ruddy, Identity Commons - y |
Massimiliano Masi, Tiani "Spirit" GmbH - y |
Nick Pope, Thales e-Security |
Peter Alterman, NIST - y Rainer Hoerbe – y |
Rebecca Nielsen, Booz Allen Hamilton - y |
Rich Furr, SAFE-BioPharma Assn |
Ronald Perez, Advanced Micro Devices |
Scott Fitch Lockeed Martin |
Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A. - y |
Shahrokh Shahidzadeh (Intel Corp) - y |
Suzanne Gonzales-Webb, VA – y Tony Rutkowski Tony Nadlin Thomas Hardjono, M.I.T. |
William Barnhill, Booz Allen Hamilton |
|
67 percent of the voting members were present at the meeting. We did have quorum.
2. Agenda review and approval
We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el chat room text is included at the end of the minutes.
Abbie asked if there were any additions to the agenda. There were none and we proceeded with the agenda.
3. Approve Minutes
Abbie made a motion to approve the minutes of May 31.
He asked if there were any objections. There were no objections. The minutes were approved.
Abbie thanked the editors for pushing the first deliverable through approval by the TC.
4. Presentation on the legal issues of electronic identity credential trust elevation by Tom Smedinghoff
Abbie said he hopes to raise the issues and have some thinking on this subject. Tom has agreed to provide some background on legal aspects of issues of trust. Abbie knows Tom from ITU-T and Kantara. The slides are on the link on the chat room.
Tom appreciates the opportunity to present to the TC. When Mary first asked Tom to do this, he started by reviewing the survey of trust-el that the group produced to get an idea of what we are focused on and thinking about. Tom explained that he may have made some incorrect assumptions
Slide 2, Tom started with some preliminary questions. Whose rights are we or might we be concerned about? We can look at the original credential provider or the individual or the RP or the federation operator. We need to look at whether there are legal or contractual issues with trust-el or risks or liabilities that might be assumed and ways for parties to protect themselves.
Slide 3, this is a question that occurred to him as he read through the document. There are two possible processes for analysis: elevate the credential or leave the credential as it is and merely use it as one of several sources of evidence. These two approaches potentially lead to different legal results. Think library card vs. passport. There are two choices: we can elevate the trust level of the library card, or we can say library cards are not good enough but if you also show us 6 other things, then it is ok. It makes a difference what we are doing and how we characterize it.
Slide 4, another key question is who is doing the elevation. I’m assuming it is the RP. Is seems that whoever is involved in the elevation process could have varying roles: from non to full responsibility for the trust-el decision. That is the key person we need to look at. For example if it is the RP that is doing the elevation, we might ask if during this process the RP is in effect assuming the liability of an IDP.
Slide 5, we also need to consider the selection of the method that is being used. The survey outlines 5 methods. My sense is that there is a difference in quality of trust in different methods taken in different contexts. So the decision to use one vs. another could influence the reliability of the trust elevation. It is also possible in some situation a federation may have an interest in all elevations being done the same way.
Slide 6, what to focus on. Is the process encumbered with legal issues? A credential comes with legal obligations. The issue is: do some of these effect the responsibility for trust-el. There could be regulatory or statutory restrictions. For example, privacy laws in some countries prohibit data collected for one credential being used for another purpose. Second we need to look at contract restrictions. If I sublicense, you can’t inherent greater rights? The credential may come with only a limited set of rights. Another example is permission requirement restrictions.
Slide 7, we are basically asking the when does the RP or even the IDP have the right to do the trust-el. It is an “off label” use of the credential”. It could conceivably violate some law or requirement. The use may be restricted to a particular, purpose or system, etc. There are a variety of things that could encumber the credential. A participant needs to be concerned with trust-el liability.
Slide 8, there is a question of whether trust-el changes the liability allocation rules. Does it shift it more to the RP? Does it absolve the original IDP of risk? These are questions, which may not be relevant in some scenarios and very relevant in others.
Slide 9, potential impact on each role. What is the legal impact on the original IDP? What representations come with the original credential and which of these carry over to the elevated credential? Or are they off the hook due to modifications? How can an IDP protect itself?
Slide 10, what is the legal impact on the RP (again assuming the RP is doing the trust-el)? Are they in violation some existing law or contractual requirement? Does the RP have the right to do the trust-el? This goes back to the question about how we characterize the trust-el transaction. That will make a difference for these kinds of questions. Also if the RP does the trust-el process, are they making any warranties (especially to the person named in the original credential?) If the original credential is fraudulent or the trust-el is fraudulent, then both could cause the original subject to suffer some identity theft. Is the RP in effect making any warranty to the subject? Is the RP assuming any IDP risks?
Peter commented that is an interesting question.
Tom replied that could be controlled in the operating rules.
Peter remarked: what that implies Tom, is an RP would be well advised to outsource the trust-el to an entity that has that line of business.
Abbie commented we could have a broker do this.
Slide 11, so what about 3rd parties? I was thinking more about providing info, but if they were also doing the trust-el, it is a bigger issue. Is it a sanctioned 3rd party or is it a party that is not part of the vetted identity system?
Shaheen asked should the RP get permission from its customer before is uses an IDP?
Slide 12, what is the legal impact on the subject? Should you be getting permission? My issue is you probably should. If a stolen Google ID is elevated to LOA-3, what are your rights in that situation? And are they potentially violated by the RP? He was thinking about what kinds of uses could come up. An assumption from Google might be that the credential is not used for a high value transaction. Do I have a right to assume that I don’t have to exercise a lot of diligence because it can’t be used to access my bank account? If someone elevates it and uses it to access my bank account, does it violate the assumptions? If something like that happens, who is liable for the damages if my bank account gets cleaned out? The federation operator may have some risk there. These are just a sampling of the kinds of questions that are out there. In general, these can be addressed in advance as part of the operating rules. The issue to ban off label use of the credential is sometimes prohibitions or associate liability limits. Those kinds of concepts might be relevant. We need to consider all roles and their rights and responsibilities they are taking on. This is just a quick overview and a lot more work needs to be done. As you move forward, you need to keep that in the back of your mind and at least note that it is an issue and maybe consider how the issues can be addressed.
Tom stopped for questions.
Abbie thanked Tom. This is really an eye opener. On your slide 2 where you ask the two relevant questions, I think that we are doing the second option. That is what we are focusing on. We take the credential as a credential. Peter, correct me if I’m wrong.
Peter replied that he agreed. We acknowledge that other alternatives are available.
Gershon commented that he had an interesting conversation about trust-el and how long it is valid for: the specific transaction vs. elevating permanently. If you do elevate, then for how long? When do you demote?
Peter commented that last year, Debbie and he were talking with the VA about the whole initiative. The VA wanted us to explore elevating trust for the duration of the transaction, which is clean enough for us to address. The second approach is to use that trust-el experience as an identity proofing action that would generate a higher credential that could be used in future transactions. At no time was there any consideration of doing identity proofing.
Tom said if it is not just a onetime transaction, if the end result can be used in the future, that is more akin to elevating the credential.
Abbie asked what is the difference between that and elevating trust with a cookie?
Shaheen said you still have to be sure the whole session is not hijacked. At the end of the day, it is the RP that is making that decision.
Abbie said one of the questions Tom raised is who is assuming the liability? Not sure if this is part of the purpose of phase 3. At the end of the day, we need to consider this [legal issues] as part of the ecosystem. Do we need to consider this at the design stage and let the RP decide its liability?
Shaheen commented if we are moving to reuse of a credential, then it is up to the RP to decide where to assign it an LOA.
Abbie commented that part of the limitation of the current ecosystem is the tight coupling between the attribute and RP decision. This is a chance for an RP to go to multiple providers to verify an attribute, even at different levels. This current model is why many organizations in the financial services world refuse to be IDPs. It is because they don’t want the liability.
Tom commented, but you may be taking on liability if you take on some of their processes.
Abbie commented I’m not liable about the risk engine the RP uses. If the input to that decision is one attribute that I attest to, I’m liable for the accuracy of that input, not the overall decision. This changes the whole ecosystem. If it works this way, I can be a participant in the ecosystem.
Peter said you have done it again Tom.
Tom replied this is just some things to think about.
Abbie asked Peter if we want to include this in the risk analysis. Should we in the matrix include who is elevating the trust?
Peter replied yes, that is a question. Tom you may want to pin down who does the trust-el, even if you don’t evaluate risk. At least knowing what that role is, is important. It may lead to subsequent limitations in the design of the system or operators. It is also a very useful way of looking at it. One of the things that struck me is that exactly these kinds of issues should inform the legal committee of the soon to be legal steering group [NSTIC steering group]. All these issues need to be addressed for the ecosystem to interop effectively going forward.
Tom commented that is the key point. If companies are going to participate, they need to know what risk they are taking on. We also need to recognize there may not be a single answer to these questions, but we need to figure that out also.
Abbie commented, yes, the risk appetite.
Gershon, I have a question about the slides. Were they written from a national perspective?
Tom responded my intent is that they would apply cross border. Obviously, when crossing borders, you have more laws to look at. You need to look at this from a cross jurisdictional perspective.
Abbie asked what about the rule about EU citizens being identified? Do we really need trust-el if we can have a PKI credential per citizen?
Tom replied that would replace e-signature. I’m still working my way through that document. There is a lot to digest there. I think at its essence, it focuses on facilitating cross border transactions for public servers. It doesn’t require any country to adopt a national ID scheme, but if they do, there needs to be an unambiguous link between the credential and the person.
Reiner asked in the case of the national eID schemes being used for signature, the RP won’t receive the public key.
Abbie asked who issues that? Does each country have an entity that sends an assertion?
Reiner replied there can be other auth schemes. About half of the EU countries have some PKI scheme.
Abbie said assuming the RP can build into its business model the ability to do auth at a PKI level.
Peter commented we had a discussion about this at a NSTIC staff meeting yesterday. Some folks think this is not a problem. I think it confuses and obfuscates the relationship between commercial IDPs and Trust frameworks and drives them to a requirement to have a state run and operated process that will run the risk of stifling innovation in the private sector.
Abbie agreed, which is why NSTIC is structured the way it is in the US.
Reiner agreed that there won’t be a viable trust provider sector to pick it up. The adoption in the private sector is a wish, but the primary goal is to establish a cross border system.
Abbie asked if there were any more questions for Tom.
Shahrokh commented that for a CA [Credential Authority], today if someone cashes a check with a fake ID, the liability isn’t on the DMV, it is on the teller and the bank who has cashed the check. Even if you take this to a check cashing shop, the liability is assumed by that hole in the wall place. Why isn’t that electronic activity any different than physical activity for a bank?
Tom commented I think the key is that when the state DMV issues a credential it is backed by a statue that says that it has no liability for a driver’s license. If a state was issuing another credential, it could potentially have no liability also. In the EU, the EU has liability.
A federation could create roles that say there is no liability on the CA. The real issue is that is great if you are an IDP. The question is can you create a viable commercial system if the issuers don’t have any liability.
Abbie commented the DMV mandates use of its credential for driving. The state doesn’t do that for commercial transactions.
Tom commented that there is a bill introduced in Virginia to absolve the IDP of liability if they comply with specified criteria. That is an alternative approach you could take on. There is still an issue if you can create a viable community if the IDP has not liability.
Abbie thanked Tom again and invited him to stay on the call.
5. Editors update on Second Deliverable (Analysis phase)
Mary updated the TC on the current status. The editors have drafted and iterated on a list of analysis questions [which have been sent to the TC list]. We used this list to perform a sample analysis of the end point identity method. We are currently iterating on this analysis to further refine the analysis criteria.
Peter said we took all of the questions that you saw that would be used as the method of the analysis. So the process is to throw these questions against method, and we did that for endpoint entity. The reason we did this is to determine if these methods will work as an analytic tool. Shaheen, Mary and I bounced these questions against end point identity. It fit neatly and we were pleased, and then early this morning what occurred to me is what that this process is descriptive. It doesn’t answer the fundamental question of how effective is it at mitigating risk. So we have done step one, the questions, and step 2 to parse method into an answer and now part 3, we need to answer the question of how effective this method is at curtailing risk. We haven’t done it yet, but have identified it as the next task.
Abbie replied what we need to do is iterate between now and the next TC call. I will definitely do that. That is high on my activity list for the end of the week. We would like rest of the TC to work on it. Have we posted the latest version to the TC?
Peter/Mary responded no.
Abbie commented I think that you should. We should put it out there and see.
Abbie said wait until we have done one more internal iteration.
6. Attendance Update
We achieved quorum.
We discussed the process for requesting a leave of absence. The process is to send an email to the co-chairs and secretary. Obtaining a leave of absence preserves voting status until the person returns from the leave.
9. Adjournment
Peter made a motion to adjourn.
Rebecca seconded the motion.
The meeting was adjourned.
>>>>>>>>>>>>>>>>>>>>>>
anonymous morphed into Tom Smedinghoff
abbie: agenda
abbie: 1. roll call
2. agenda approval
3. approve minutes
4. Presentation
Tom Smedinghoff, ABA, on the legal issues and considerations of trust elevation.
5. Editor discussion on Second Deliverable (Analysis phase)
6. conclude
abbie: Passcode: 637 218 8139
Int'l Toll: 1-980-939-6928
abbie: 1 866 222 6652
abbie: presentation at https://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2575
anonymous morphed into Suzanne Gonzales-Webb
anonymous morphed into Shaheen Abdul Jabbar
Shahrokh Shahidzadeh (Intel): The Risk appetite that Abbie is talking about is exactly what banks do today for check cashing. At the end of the day if one cashed a check at a teller by presenting fake identity isnt the liability on the bank and not the DMV?
Shahrokh Shahidzadeh (Intel): here the bank has appetite for assuming the liability cause they are the ones who need to verify the credential
abbie: yes bank liability