Notes for February 19th call

Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee

February 19, 2014.

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

Andrew Hughes - y

Anil Saldhana, Red Hat

Bob Sunday

Brendan Peter, CA

Carl Mattocks, Bofa

Cathy Tilton, Daon - y

Charline Duccans, DHS

Duane DeCouteau

Calvin

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

Diana Proud-Madruga - y

Diego Matute, Centrify

Don Thibeau, Open Identity Exchange - y

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Gershon Janssen

Ilene Bridges

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam

James Clark – Oasis

Jeff Broburg, CA

Jim Macabe (Kaiser)

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

Mike Harrop

Mohammad Jafari, ESC -

Peter Alterman, SAFE-BioPharma

Peter Jones -

Rainer Hoerbe -

Rebecca Nielsen, Booz Allen Hamilton

Rich Furr

Rick Grow - y

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

Tim, McKay - y

Tony Rutkowski

Tony Nadlin

Thomas Hardjono, M.I.T.

William Barnhill, Booz Allen Hamilton

Adrianne James, VA

Patrick, Axiomatics

Steve Olshansky

We achieved quorum.

2. Agenda review and approval

We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el

The agenda was approved.

3. Approval of the Minutes

Diana moved and Cathy seconded approval of the minutes of the previous meeting Feb 5th.

There were no objections.

The minutes were approved.

4. Editors Update

Abbie began. We continue making strides on putting lines in the sand. The purpose of the call today is to continue this discussion. Sometime around the end of March, we should shoot for a F2F. Keep that in mind.

Andrew continued reviewing the slide deck from the last call, which is in the TC document repository. What he tried to do in this version is relate the trust-el model to an ABAC model of NIST 800-153. He made a good case to make treat it as a policy engine that feeds ABAC architecture. We walked through a basic pattern. (Basic ABAC pattern of 800-162.)

Andrew picked-up at slide 17. We need to decide what will be in deliverable 4. Will it be architecture stuff? It probably will not. We need to figure out what an interface would be. We went back and forth on what kind of policy we could write and there doesn’t seem to be enough commonality in practice in elevation from one LOA to another LOA, so rather than digging in on a method of determination itself, we are going to focus on the data and data structures for going back and forth, and leave method determiner determination to implementers.

Slide 18, added in a basic trust-el pattern, within the subject box we have end-user side stuff. Have method determinator and repository and administration point. The basic pattern is intended to handle simple use cases.

Slide 19, extended trust-el pattern. It is supposed to be capable of handling most use cases. Abbie talks about pre-loading of capabilities into a method determinator (knowledge of devices, etc.). The specific details of which line goes to which box [in the model] can be adjusted later. The basic takeaway on this slide is the method determinator’s policy engine for how to get from one LOA to another and what methods are possible. It feeds the PDP and the PDP uses its own resources to make policy decisions. Are we ok at this point?

Slide 20, exercise to take core model from deliverable and make sure can place boxes as a sanity check.

Slide 21, the same.

Slide 22, the same.

Slide 23, overlay boxes are from deliverable 3. If you want to see that, it is actually on slide 7. Slide 24, is the next step in the core model determinator.

Slide 25, the PDP may go through another cycle.

Slide 26, relating this to ABAC really helps one to see where trust-el enhances other models.

Colin commented it would be ideal to test it against an additional model. He is trying to think of one that is reasonably well known. Have you thought about that?

Andrew said XACML may be too close to ABAC to try.

Colin commented it might be, but might just prove the point.

Slide 26, there is other stuff that is needed.

Slide 27and beyond, what might be needed for the PDP and PIP.

Slide 28, more details about PDP. It must be able to consume policy and drive the PIP as needed and signal the PEP in a way the user can work with.

Slide 29, PDP enhancements. He considers the PEP to be active and central to gathering more information to facilitate the trust-el. The PDP tells the PIP to get me more stuff.

Slide 30 and beyond,

Slides 31 to 36 are speculative slides. What he was trying to do is just make some assumptions about what the method determiner actually has to do. This helps determine what types of information the method determiner would actually have to have: what requests and what responses.

Slide 31, first bullet, what does the determiner actually do? Given the current method used, and current LOA and either the request method or the desired LOA, determine the method or LOA destination. It will return an error if there is no way to get from the current LOA to the request LOA. It is not intended to be mathematical. It describes an equivalence (that is not mathematic) between the current LOA and the desired LOA and trust-el method.

Dianna said she is not seeing the role of identity proofing in establishing the high water mark for LOA (either ad hoc or pre-registration id proofing).

Abbie agreed that is totally true.

Andrew explained that when he said LOA, he is not constrained by the NIST LOA definition. What he is really talking about is trust level. If you are using the 800-63 versions, yes you are right. If you are doing it a different way, maybe you are asking the partner a question. Where is the authentication? Is this model discounting the use of additional authentication factors? His answer is this is defined by the method determinator and data it has access to. If you are in a Canadian model where credential and ID proofing are separate, maybe you are asking for more info without changing the level itself. So this ID generalicity is what do you need to get from point A to point B.

Dianna is not necessary meaning strictly 800-63, as it is not really set up for on-the-fly identity proofing. Our concern is something that we can look at to elevate trust. Her point is without some way of assuring that the credential is bound to an actual physical identity, we don’t know what we have. That needs to be part of the whole elevation of trust.

Abbie said in the enrollment phase, the credential issued has to be at a specific LOA. Trust-el can’t exceed this. If you need to do trust-el to LOA-3, you can elevate to maximum level achieved during enrollment.

Diana asked if part of this is answering a question from an independent credit bureau data base, one of the things 800-63 doesn’t do. What if the system did ID proofing on the fly for immediate trust-el? At what level does that raise the LOA? How do we determine that kind of trust-el and the resulting LOA?

Abbie said he thinks the system needs to be distributed. If a person uses Gmail and they want to buy a boat, they could get information from the Bank if it provided online signing. If the bank is willing to send a token, you could use it in combination to get to higher level. The point should be clearly indicated in the 4th deliverable. It will help the architecture to be adaptable.

Andrew is thinking of consulting a specific method that gets you from one level to another, but he’s not sure the rules are portable. A trust framework will specify what trust-el method gets you between methods.

Dianne agreed. It needs to be determined by each org – what they are willing to accept. But she thinks the technology has advanced for on-the-fly ID proofing (based on credit bureau questions or last transaction, etc.) The documentation and standards out there haven’t caught-up with available technology. 800-63 hasn’t caught up.

Andrew agreed. The magnitude of factors is undefinable. Based on a contract, a federation could declare: service A can elevate you from A to B. We know if it can be done, but can’t quantify it, as the TC is not inside the agreement.

Diana thinks it would be worth exploring even if we can’t quantify the specific methods. She thinks it is the way of the future. Most people have a smart credit card.

Abbie commented we talk about FIDO. The FIDO authenticator is an attribute to consider in the decision. We could say a device is enrolled in FIDO, so we have to be very careful. What does enrollment mean? The concept can be more distributed.

Andrew asked if we think trust-el is at the core a trust determination, what effect does additional information for the policy engine have? Additional factors are additional info to feed the policy engine. We haven’t tried to set any standards.

Colin suggested we should try applying this to UMA. We might answer Diana’s question as well.

Andrew responded: Colin you are dead on as usual. I got the ABAC idea from the UMA group. There is an analogy to trust-el is the UMA “needs claim” flow. I will try mapping it [the straw man trust-el approach] to UMA.

Andrew again asked if he should try to define a straw man interface.

Diana really likes Colin’s suggestion about UMA and OAuth models.

Colin said yes to the straw man.

Abbie commented that ABAC is more of an attribute than a role based approach. We need attributes to feed the policy engine (e.g. XACML or UMA.) A lot of trust-el will be within a bank [organization]. Maybe we need to clarify that we are thinking AB rather than ABAC.

Cathy said the offer to host the F2F in San Diego is still open.

Abbie will put a ballot on the TC for the F2F. We also need to co-mingle with the IBOPS TC.

6. Adjourn

Suzanne moved to adjourn the meeting.

Colin seconded the motion.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

abbie : 1 roll cal

2 approval of minutes

3 editor update

4 roll call

5 adjourn

abbie : Passcode: 637 218 8139

US toll free 1-866-222-6652

Int'l Toll: 1-980-939-6928

- Australia, Sydney: +61 (0) 2 8064 4811

anonymous111 asked for a victim, I choose... anonymous

Room information was updated by: anonymous1111

anonymous111111 asks: null

Magic 8-Ball says: Yes - definitely

anonymous2111 asked for a victim, I choose... anonymous

anonymous2111111 asks: null

Magic 8-Ball says: Yes - definitely

anonymous morphed into Tim McKay

Diana Proud-Madruga: Is there a different WebEx?

Diana Proud-Madruga: Either that or could someone please send me the slide deck?

anonymous111 asked for a victim, I choose... abbie

anonymous111111 asks: null

Magic 8-Ball says: Yes - definitely

Suzanne Gonzales-Webb: Is anyone else hearing a lot of static...? Making it difficult to hear the conversation.

Cathy Tilton (Daon): Yes, quite a bit of static on my end also.

trust-el message