Minutes from January 22 call

["Mary Ruddy" <mary@meristic.com>]

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

January 22, 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  - y  

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  

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 - y 

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. - y  

Shahrokh Shahidzadeh (Intel Corp)  

Suzanne Gonzales-Webb, VA  

Tony Rutkowski

Tony Nadlin

Thomas Hardjono, M.I.T.  

William Barnhill, Booz Allen Hamilton

Adrianne James, VA 

Patrick, Axiomatics

Steve Olshansky

 

72 percent of the voting members were present at the meeting.  Abbie declared quorum.

 

Abbie wished TC happy new year.  We have an update from Andrew.

 

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

 

Abbie asked for a motion to approve any unapproved minutes [November 13 and October 30].

Peter made such a motion.

Don seconded it.

The minutes were approved.

 

4. Editors Update

 

Andrew gave a WebEx of his slides for the 4th deliverable with a purpose of discussing what should go into it and the information flows. Abbie had suggested architecture would be helpful and this is what he came up with. 

 

Slide 2 is the purpose of the architecture. This will seem like a step backwards. The first 3 deliverables are a bit too find grained. This is pulling back a little to discover the primary actors, and underlying architecture.

 

Slide 3 is the goals of the 4th deliverable protocol.

 

Slide 4is editor’s conventions for drafting the architecture. The terms can be refined as we progress.  Andrew discussed the terms such as differentiating between end-user, end-user agent and client (this is OAuth like).  Sometimes we need information from the device itself for example.

 

Diana commented that this is good. She has been going thru the documentation and the initial identity proofing is an area that she is finding very little information about. The binding of the person to the electronic identity and making sure that this binding can be trusted seems to be a critical area that has not been fully covered.

 

Abbie agreed.

 

Andrew commented in deliverable 3, there is a heavy emphasis on authentication. In-person events are sparse.

 

Abbie built on what Diana said. We could issue a credential. What we need to keep in mind is we [a business] know you have been using a credential forever, and have history. Now you come in from a mobile phone. The proofing has been done already. Now we need to step-up.  There is a missing credential of known LOA that determines how much step-up you can do with a device…. A proxy should be able to step-up attributes based on means [of access], a lot of things change.

 

Andrew replied there is a space for that. Let’s see where that fits in coming down the pike. One of the things I clarified for myself is this is a step-up.  So trust-el happens after the RP determines the initial credential is insufficient. So there is a CSP0, the credential service provider that issued the initial credential. The main trust-el happens after it is determined that the initial credential is insufficient.

 

Abbie elaborated so for example, the trust-el is dynamic based on what you are trying to do. There is a continuous trust-el session and transactional basis. So if you conduct a $100 transaction (LOA-2), and then pay a $1000 visa bill this triggers extra security, and then maybe we now request a voice print.  After a while you want to pay an electric bill of $1000, it has to use a token that has not been used before in case the session is compromised. If the end-user device doesn’t support any suitable combination, the end-user may be asked to come to the bank. The abstracted protocol will be a policy engine that points back to a selector that selects suitable tokens based on device and situation. So our architecture needs to be flexible.

 

Convention 4 introduces the concept of a trust elevation method service provider TEMSP.

 

Slide 10 is the conceptual flow.

 

Don commented about the reference to an actor [TEMSP]. Actors have duties and liability.  A new actor introduces complexity. This is distinct from the notion we have worked with before. Implicit in the role of SaaS Provider, this may be part of a service offering,

 

Andrew clarified that this may be a role, not a [new] service provider.

 

Colin commented fair enough.

 

Peter said isn’t this a text iteration of the graphic in our fourth deliverable?

 

Andrew replied it is, except for separation of initial credential and additional trust-el methods.

 

Peter commented, ok, I get that.  It would be easier for me to follow in a graphic.

 

Abbie said he has an issue with your calling this a RP.

 

Peter said he liked the previous graphics.

Shaheen said what may be missing is some definitions.  We may need to further define RP, and explain the duties of others. Right now we each have own definitions.

 

Slide 11 is a graphic, use case A. The initial credential is sufficient. In this scenario there is no authentication at the RP, just at the IDP.

 

Abbie remarked you bring a good point here. An example is coming to a bank site. The bank wants to have the option to block you or not.  I need to know that I have seen this device or am learning about it.

 

Shaheen said we need to know who it is, but don’t need to identify.

 

Abbie said we only care if the device has been seen before or is registered.

 

Slide 12 is use case B, initial credential is not sufficient. The RP says your initial credential is insufficient, and I need trust-el and the user agent asks for trust el categories. It gets the categories. Assumes the end-user agent can give, for example, location info. 

 

Shaheen commented this assumes the end-use agent is software on the client? And that is a mandatory step? 

 

Andrew explained the arrows are going the other way. The RP provides the list of categories (may be just one) and the user agent can or can’t supply the elevation method.

 

Shaheen asked what if it is a native mobile app?

 

Abbie said that is ok. But I think we can add enrollment. We need to make some assumptions. When you enroll the agent you know up-front what the max trust-el is possible with the existing base. After that the total set decreased, not increased (a device’s trust may go down, it may be in the wrong location, pickup malware, etc.)  I don’t know if we need to illustrate this as part of the interaction.

 

Andrew said one of the flows that is missing is that initial enrollment. You can imagine in an enrollment flow the CSP is interacting with relevant entities. That part of the flows isn’t done, but this where it would fit.

 

Shaheen said it is necessary that for each transaction the client needs to provide what the client can actually do.

 

Andrew said it is not mandatory for each transaction.  It would be an optional flow. 

 

Shaheen commented if each time we need to ask the end-user to provide information, there will be too much overhead.

 

Peter explained what we wanted to do in the draft is to present the basic workflow and build a generic model of the base flow. What I’m seeing here is a lot of spawning of variation.  I think it is more important for us to stay at a higher conceptual level

 

Abbie remarked that is achievable Peter. This becomes an example flow. We could do an API and some message flow from this.  How many messages are needed then becomes a state diagram that is local. This is where the higher level architecture needs to come in.  We need to bind this to the original flows that Shaheen presented.

 

Peter suggested the way to present that is with transparent overlays. The bottom sheet is the basic flow, then overlay it with exchanges and then overlay it with metadata related to exchanges.

 

Diana said one of the things that occurs to me is these cases do answer some questions and standards organization do put out user guides, and these examples may be appropriate in a user or implementation guide. Going through this exercise is helping to provide clarification.

 

Abbie said definitely we can add that. This is a specific flow.

 

Peter commented we also know how we can nominate someone to write the user guide.

 

Andrew explained that one of the purposes of this middle level is to just sort out some of this stuff.  I’m just looking for confirmation that something like this set of flows is anywhere close. If this is close, I can abstract from this and keep going.

 

Abbie said we will continue this on the editor’s call.  We are putting stakes in the ground now. We need to have a TC agreement on the level of abstraction and quickly converge to the working model.

 

We still need to have F2F. We have one possible host. He will revisit this.

 

6. Adjourn

 

Abbie asked for a motion to adjourn.

Shaheen made the motion

Colin seconded the motion.

                              

The meeting was adjourned.

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

abbie-canada morphed into abbie

 

abbie : agenda

 

anonymous morphed into Don Thibeau

 

abbie : 1. roll call

 

2. approve minutes

 

3. agenda bashing

 

4. Review latest editor update as posted on the tc website see

 

https://www.oasis-open.org/apps/org/workgroup/trust-el/download.php/54939/TrustEL%20Architecture%20v01.pdf

 

5. roll call

 

6. adojourn

 

abbie : Please use this webex link

 

Note: Donot use the telecom bridge from the link just keep using the TC regular bridge

 

Bridge 1-866-222-6652, Passcode 637 218 8139

 

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

 

https://attend.webex.com/attend/j.php?MTID=ma50be6cb04e5b2d19ef6cdb5c673545b

 

anonymous morphed into Diana Proud-Madruga

 

anonymous morphed into Rick Grow

 

Please change your name from 'anonymous' using the Settings button