Minutes for the face-to-face meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee
August 9, 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 - y Charline Duccans, DHS |
Duane DeCouteau |
Colin Wallis, New Zealand Government - y |
Dale Rickards, Verizon Business |
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 |
Nick Pope, Thales e-Security |
Peter Alterman, NIST - y Rainer Hoerbe |
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. |
Shahrokh Shahidzadeh (Intel Corp) - y |
Suzanne Gonzales-Webb, VA Tony Rutkowski Tony Nadlin Thomas Hardjono, M.I.T. |
William Barnhill, Booz Allen Hamilton |
|
63 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 proposed an addition to the agenda to ask should we take one meeting off due to vacation. Silence.
There being no additions, the agenda is approved.
3. Approve Minutes
Abbie asked do I have TC approval to approve the minutes from the last meeting?
Peter said yes. Peter made a motion to approve the minutes of July 26. There were no objections. The minutes were approved.
4. Editors update on Second Deliverable (Analysis phase)
Mary began by stating the current status is that sample analyses had been made for two methods. There has been additional discussion about what other factors to include in the analysis format. The next step is to perform the analysis on a larger group of methods.
Abbie asked if Anil on the phone. We could task Anil on the Identity in the Cloud TC.
Abbie asked do we need to include the ownership of the credential, remember the ABA list discussion, what can a third-party attest to.
Peter agreed. He had a talk with Tom in person this week and agrees.
Abbie commented there are some legal issues you need to evaluate when you elevate trust. So where is the limit in the analysis when you do attestation? So the credential provider swears they did a SS number look up, this could be validated in an audit. What do we need to do there? It is part of the risk model.
Peter replied it is part of the overall risk model. In transaction trust, it is not about the credential. There are some trust-el methods in the phase 1 doc that include the delivery of a second credential of some sort. It is in those specific methods that the issue of the ownership or the validity of the credential becomes a factor. But it is only an additional factor. I don’t think we need to get into the legal stuff. I think it is outside the purview and we don’t need to worry about it.
Abbie agreed.
Peter continued it is not in the [analysis] template. We should add it were appropriate. For most methods, it will be irrelevant.
Abbie said in transaction trust, it is the IDP or ISP to the RP.
Peter said we are assuming trust-el is after the initial credential is asserted. We are taking for granted step one. It is out of scope to worry about if the initial credential is valid. It is after an initial transaction has been initiated that we are elevating trust. What I’m thinking about as a sample transaction is: I go to SSA and click on log in. That initiates a transaction between me and SSA RP. The initial login initiates the initial auth process of the transaction.
Abbie said we need to clearly state we are not doing authorization. For example if you go to the VA website and want to use GMAIL, Google may not have done any identity proofing. Is this part of the trust-el model? Are we saying on the contrary, the website says I need higher validation so Google does second factor and then they go back to the RP?
Peter said it depends on the particular design of the RP application. Sometimes it is one to one and sometimes one to many.
Abbie said we could do this with a registry or trust framework. We need to know how that elevation stuff will be consumed across the whole landscape.
Peter replied you are pointing out why it is not an easy analytic process. But we don’t need to worry about first principles. It is how do you, the RP, want to raise the trust you have in the identity of the person you are conducting business with. If that is by an exchange of attributes and if the more these are reliably vetted, then the more you can elevate.
Abbie said I don’t know if it is transaction based or session based. We haven’t looked at mobile models so far. The elevation of trust has to go both ways. If the VA is using a cookie, and Google has a problem but I don’t trust how the VA does cookie mgt as it is acceptable to cookie stealing, then what? There should be a common manner to achieve a higher level of trust. It is not a one way street.
Peter commented I understand why Abbie is concerned, but I think it is an unnecessary complication of an already complicated process. I think the context in which we are working this is a web mediated transaction. It is only a subset, but it is the largest piece of the universe. I also agree we are not addressing the trustworthiness of the RP, so we are not addressing site proofing. We are talking about transactions, not sessions, so we are at least one level abstracted from that. Abbie what you are raising is another subject for us to look at, but it is not part of our focus.
Abbie replied I want us to clearly state what is out of scope so we are not criticized for that.
Peter said as a TC we need to decide if we want to add this to our working list.
Colin jumped in. Peter and Abbie your ears must have been burning on a thread I had with Ian Davis of Canada. Abbie is asking the same question. I’m a RP running a service that is expecting a credential linked to a particular level of assurance, what I’m getting is a credential at another level and I’m doing what needs to be done to elevate trust. What does this do to liability and non repudiation? We had a debate about that. I was wondering if initially, I can get Ken’s permission to pass on that email to Abbie (not to the whole list.) If you can look at that email you can say it is really out of scope or if in scope, then maybe we release it to the list. We need to say it is out of scope or provide guidance.
Abbie responded: I hear you.
Peter said I think you should send that email in and Abbie and I will respond. In general it is a valid concern to consider both ends of the transaction. But there is a fundamental issue - you are raising trust in the transaction not raising trust in the credential. The credential is only one part of the processes that leads you to higher trust in the transaction.
Abbie replied I agree with you. If you are a credential provider at LOA-1 and I’m trying to get back to you to elevate trust, is it possible using one provider to do that?
Peter said it depends on what method is used and your evaluation of the trust-el technique and the result.
Abbie said for example if I have superman150@yahoo.com and I try to use it to logon. There was absolutely zero vetting on this credential. So how can you elevate the trust based on that?
Peter replied I don’t think you can. If I wanted to go to the VA to check out my status, the VA would say you need a LOA-3 credential, yes or no. If you don’t have such a credential, it will default to one or more trust-el processes that it has previous determined will give the VA at the end of the process sufficient trust.
Abbie said we are making big progress here. Once we default to approved VA processes, it means that they have put in place some assurance methods for providers they accept.
Peter commented the first assumption is the VA will only recognize credentials from a FICAM approved provider. The second is the VA will engage some trust-el practices that it has designed into its authentication service. It is not going to do this on the fly. It won’t be arbitrary. That is why we are here so the VA can go to the TC output and say if I use technique A and B then I can achieve the needed trust. What we need to do, to enable this to happen in an auditable manner, is to collect and identify and analyze these methods: how they work and how effective they are for determining the identity of the user. The third thing is to see if with all this knowledge we have generated we can use our knowledge to measure the effects of the use of these techniques against the NIST baseline.
Abbie replied I would rather use the ITU_T one. It clearly separated the vetting process from LOA.
Peter said I’m fine with using alternative standards.
Abbie said we are coming to very good conclusion here in terms of what is in scope and out of scope. You are saying you can put the internal process for determining trust, generate a number that goes into a risk engine and how you consume that is out of scope. What we want is consistent methods.
Peter said we are providing all the RPs with sufficient information so that they can make consistently informed determinations.
Abbie said, so Mary and the editors, this needs to be captured in the analysis.
Mary said we need to draft the context for the second deliverable.
Abbie said for example, based on this analysis, consider this scenario, and this is one way to elevate trust.
Peter said I’m more worried about getting the methods analyzed at this point, then being clear about the definition of the scope.
Abbie asked how many analytic methods are we aware of.
Peter replied that was phase one.
Abbie asked for the VA example, are there published methods?
Peter said that is why we are doing this. Right now it is all ad hoc and arbitrary. What we got from phase 1, right Mary?
Mary replied yes, we have 30 pages of use cases.
Abbie commented that he was trying to see if someone published what we want to publish.
Colin replied there is no standard body to my knowledge has done this.
Abbie commented, so this is good.
Peter said we are in the middle of the analysis. We understand the context paragraph. We don’t understand the analytics. We are lagging on that.
Abbie commented he is not sure what else we can do to motivate the group.
Peter asked who can take the lead with you? And assign action items. What is the magic ingredient to spur analytics?
Peter continued, what I said a few weeks ago is for the four of us to get on a call later today and review the roster and make recommendations for tasking who should take 4 hours and make an analysis.
Colin said there is one other way maybe, so that now there is a little more clarity, maybe we could task people who submitted the use cases to have a go at their own one.
Peter replied that is a good suggestion. The four of us will talk later today and come back with a couple of ideas, Colin’s being one of them, that we have to start proceeding. We need to get it going.
Abbie agreed. Before we run out of time, I would like to put on the table having a face-to-face meeting on Oct 9th before the Cloud Identity Summit in DC. I think maybe we should do a F2F then, and summarize the second deliverable then if it is not done before. Hopefully we can publish after that meeting. Have F2F and then wrap up the second deliverable and then start the planning for phase 3. Is that feasible?
Peter asked Mary to put out a ballot. Maybe we can do a face-to-face meeting the day before the IDtrust Cloud event.
*** Mary took an action item to create a ballot for a face-to-face meeting in DC on October 9th before the IDTrust Cloud event on Oct 10-12.
Colin commented that would be good as his travel is already in.
Abbie asked can we tap on our CA partners to see if they will host us? If not the bank can find us a location.
***Mary took an action item to tap CA.
Colin asked Peter to clarify his current email address.
Peter responded that he has many email address now. The palterman at safe-biopharma.org works. You can also use his hot mail (peter_alterman at hotmail.com ) or gmail (peter.alterman at gmail.com) accounts.
Abbie commented that this was a good conversation.
>>>>>>>>>>>>>>>>>>
6. Attendance Update
We achieved quorum.
9. Adjournment
Abbie asked for a motion to adjourn.
Rebecca made a motion to adjourn.
Colin seconded the motion.
The meeting was adjourned.
>>>>>>>>>>>>>>>>>>>>
abbie: 1. roll call
2. agenda approval
3. approve minutes
4. editor discussion on Second Deliverable (Analysis phase)
5. conclude
abbie: mary where is the link to current version of the second deliverable
abbie: i do not see it on the tc document page
anonymous1 morphed into Rebecca Nielsen (Booz Allen)
anonymous morphed into shahrokh shahidzadeh
Mary Ruddy: Have not yet posted any of the drafts
anonymous morphed into Colin_NZ
shahrokh shahidzadeh: Good morning all
anonymous morphed into Mike Davis