Minutes for the face-to-face meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee
July 26, 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 |
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 - 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 |
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 - y 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 |
Rebecca Nielsen, Booz Allen Hamilton |
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) |
Suzanne Gonzales-Webb, VA – y Tony Rutkowski Tony Nadlin Thomas Hardjono, M.I.T. |
William Barnhill, Booz Allen Hamilton |
|
60 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.
There were no additions to the proposed agenda.
3. Approve Minutes
Peter made a motion to approve the minutes of June 28 and approve the correction to the minutes of July 12. Dale seconded the motion. Peter asked if there were any objections. There were no objections. The minutes were approved.
4. Overview of approach to multi-factor step-up authentication from Cathy Tilton of Daon as input to thinking about Phase 3.
Mary explained that in preparation for thinking about phase 3, we have a presentation today by
Cathy Tilton of Daon on an architectural approach to multi-factor step-up authentication. A link to the slides can be found in the chat room.
Cathy began by asking if everyone has the presentation.
Slide 2, the purpose of the presentation is to introduce us to an approach for trust-el. The product is just an example to inform our thinking for phase 3.
Slide 3, reviews the areas of the presentation. Time permitting; there is an example at the end. The example product is IdentityX. It is risk based multi-factor auth. It runs on smart phones and tablets. Right now it runs on most available OS. We have instantiated 8 different auth methods as shown.
Slide 4, It provides multi-factor auth: proof of possession of device, there is a soft cert on the device, what you know is pin/password, OTP, and multiple biometrics: face, voice and palm; and context (gps geo location.) We tried to provide a number of different traditional and non-traditional methods the RP can choose based on the risk level of the requested transaction. It can run out of band and works for mobile apps as well.
Slide 5, shows you a few of the screens. We will step thru the process at the end. It is intended to be very clean. The intent was to not require additional things to hang off the phone. It uses the inherent capabilities of the platform itself.
Slide 6, the whole idea is to have a risk aware capability. For lower risk, you can require a minimum amount of challenges to be made. As the risk level increases, you can select from your basket of auth methods to employ. For banking, the risk may be related to dollar amount. There are also risks that are more dynamic, based on conditions such as the time the transaction occurs.
Slide 7, shows how this fits together architecturally. There are gateways to various phones (not Symbian). It is meant to be a flexible architecture so you can add auth methods in the future. It also supports less smart mobile devices via SMS, but you don’t get the full set of auth methods that way.
Slide 8, the relying party would assign transaction IDs, and would map those to a specific set of policies of methods or combinations of methods, retries, and context. This is in a plot level phase. In the simplest form, the transaction ID may just be high, med and low. We have had other pilot customers who have 30 transaction IDs, some of which are very similar. So it is all under the control of the RP, they chose the methods that are available. Some like biometrics. Others stick to traditional methods they like.
Slide 9, the user makes a transaction request and then the RP makes the auth request to the auth server and based on transaction ID and user ID makes the appropriate challenge. The user response is evaluated. This can be an immediate thing or could require an OTP. The authentication server can send a challenge to the user’s phone and the user enters the response.
Slide 10, what are some of the alternatives and considerations associated with assurance levels? Will the RP request a specific set of methods or an assurance level. That assumes that equivalence has been established. Also does the server report pass fail or assurance level achieved? Sometimes the RP asks for additional things. Some RP’s want to know the actual biometric score. So there are different possibilities there. There is also issue of how much choice do you allow the user. What if the user has preferences? The RP can perhaps allow them to add additional factors beyond the minimum that the RP requests. When trust is elevated, you can require only the delta or required the full set of factors as if starting from scratch.
Slide11, the goal is to make it as convent as possible and as secure as possible.
Slide 12, Cathy thought we might find this interesting. A Gartner study shows biometrics are the most preferred additional factor for online banking users. Customer preferences do matter. Biometrics are becoming more accepted.
Slide 13, describes a couple of use cases. The first is simple online banking. The user logs into the general website with UN/PW. Then when they initiate a transaction, the example challenge is to provide authorization on a mobile device. In this example, maybe just proof of possession is enough. If a subsequent transaction is for even higher value or is more fraud prone, the system may then ask the user to enter a pin and speak a pass phrase.
Slide14, shows adding the geo position. In this case, you have a location sensitive policy. For example if the request was generated in the USA, use policy A. Outside the USA, the system may request a number of different factors. This is showing a more dynamic policy which could be based on time of day or threat level as selected by the RP.
Slide 15, lastly user choice can be a factor. Maybe a bank has set minimum requirements, but maybe the customer would be more comfortable with a higher level. Maybe the customer wants to require an additional factor for transactions over 5K.
Cathy stopped for questions.
Slide 16, begins a set of transaction step examples that describe other use cases and show screens.
Slide 17, you initiate the transaction for 15K.
Slide 18, as soon as you select transfer funds, you get a request to use the mobile devise.
Slide 19, most pilot customers are imbedding the feature in their own app. It could be preloaded as part of registration process. This example assumes registration has already occurred.
Slide 20, it brings-up the initiated transaction. But there could be more than one transaction. The transactions could be generated from multiple service providers and queued for approval.
Slide 21, usually there is a function that checks that your phone is enrolled and your account is valid. Once it is done, you have three choices. You can approve the item, delete it, or report it as fraud.
Slide 22, shows a PIN option.
Slide 23, shows a starting screen to take photo of your face. Voice recognition is also supported. We support basic versions and one that supports rudimentary liveliness.
Slide 24, is a biometric approach that uses your smart phone to take a picture of your palm.
Side 25, describes a standard voice recognition approach with liveliness option.
Slide 26, is the OTP option that would be displayed on the screen.
Slide 26, shows the completion of the transaction.
Cathy concluded by saying she wanted to introduce us to the concept of multiple factors and map them to different risk levels.
Cathy asked if there were any more questions.
Colin responded that it looks great.
Mary thanked Cathy for providing food for thought.
5. Editors update on Second Deliverable (Analysis phase)
Mary began by saying that we now have two sample analyses using the proposed analysis method. We need to review them to see if the analysis format is complete. Once the analysis format is complete, we can analyze the remaining methods.
Colin commented that he did add some comments too. The method seems to be working quite well.
*** Mary took an action item to re-review Colin’s comments.
Colin continued that what he did was to do a cross check with some of the questions and x.1254 threats. There were: theft and credential duplication and hijacking. I can imagine that some of these aren’t relevant to all use cases, but some may be in some. So the issue is should we include those in the chart even if in some circumstance they are not relevant. His other thought was he saw the M 04-04 table, but it is easier to remind people of the actual LOA table rather than the risk table. So that is in the email from Tuesday from me. Apart from that I thought it was coming together. I liked the changes that were put in
Peter commented great, thanks.
Dale said when it come to the trust-el method and analysis, I see you have credential life cycle attributes. I would like to add attributes overall, not just to the credential. Some of the things we are talking about in the attribute TC at OIX, for example, are when signing-up to do geo-location; it may not be linked to the [base] credential. It may be linked to something else you own.
Mary asked for other comments. This is very helpful.
Dale continued, for an attribute, what is the authoritative source of that attribute, rather than a secondary source? It may be the manufacturer is the authoritative source for a VIN [Vehicle Identification Number.] Need to understand if it is the authoritative source or the secondary source.
Colin said that “derivative” is another word for that besides secondary.
Mary commented that there may be multiple links in the chain of attributes, and some processes may require the source be provided. When I was at the OASIS general meeting a few days ago, I was able to speak with Tom, and he had a positive response to the idea of enhancing Kerberos to provide the attribute source.
Mary asked if there were other comments.
Suzanne said there is concern about what would happen, she didn’t know if the group has already addressed this, if you had an expired credential, so that the RP that elevated the credential, what do you do in the event that have elevated, but the credential has turned out to be bad or false. Have we addressed that? That has been discussed in other methods.
Peter responded that is more about outcomes than the method. I think I rolled it into the caveats and limits of each method, don’t you think?
Suzanne replied I don’t know. That is why I brought it forward.
Peter said let’s talk about that issue. If I could write it up into a paragraph, that could help all to think about it.
Mary commented there could be multiple directions of feedback loops if a problem was detected.
Suzanne said I think those may have come out of a discussion of healthcare use case. A physical was given elevated access, but it turned out that his license had been expired.
Peter said let us just talk that thru. If that license was one of the required attributes, than at time of authorization that would be validated by the RP or its proxy. If it was expired, the response back would be no. So it would fail. What you brought forward is an example of why it is important to validate attributes at time of auth. Does that make sense?
Suzanne responded that may answer the question.
Mary commented that this could be a corner case of a doctor’s license that was going to expire the next day and the emergency room doctor ends up working after midnight.
Suzanne responded that she was thinking that maybe an expiration of license hadn’t been entered in.
Dale said she would like to put an idea forward: that this is an issue between the attribute exchange provider and the RP. Maybe the RP doesn’t want to accept the thing. Or maybe it does want to assume the risk.
Mary another example is the process they have in Italy to provide emergency access to doctors so that a patient isn’t killed if there is an emergency and the normal access process isn’t working.
Peter remarked that we really need to encourage everyone to pick a method and give it a shot.
Mary encouraged everyone to pick a method that inspires them and send their choice to the list.
Colin said he will do this as vacation home work.
Mary asked if there were any other comments.
Colin remarked that the examples look good. He may come back with a few directed questions.
6. Attendance Update
We achieved quorum.
9. Adjournment
Mary thanked Cathy again for the information and examples of trust elevation.
Mary made a motion to adjourn.
Dale seconded the motion.
The meeting was adjourned.
>>>>>>>>>>>>>>>>>>>>
Mary Ruddy: CHAT ROOM
http://webconf.soaphub.org/conf/room/trust-el
1. roll call
2. agenda approval
3. approve minutes
4. Overview of approach to multi-factor step-up authentication from Cathy Tilton of Daon as input to thinking about Phase 3.
(Note we hope to get an update from David Rennie of the UK government on applying notions of trust elevation to real world environments on August 9th.)
5. editor discussion on Second Deliverable (Analysis phase)
6. conclude
Mary Ruddy: Link for today's presentation: https://www.oasis-open.org/apps/org/workgroup/trust-el/document.php?document_id=46549
anonymous morphed into Suzanne Gonzales-Webb