[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes for August 6th call
Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee August 6, 2015. 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)
We achieved quorum. 2. Agenda review and approvalWe used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-elThe agenda was approved. 3. Approval of the Minutes Don made a motion to approve of the minutes of the July 9 meeting. Gershon seconded the approval. There were no objections. The minutes were approved. Next, Abbie asked for a motion to send a note to the ITU-T to update them on our deliverable. Don so moved Andrew seconded Abbie noted that there were no objections and the motion was approved. 4. Editors UpdateAndrew reported that he is receiving updates. Version 0.4 was sent out just before this meeting. He has Peter’s and Don’s updates as well as from himself. He is holding off on including Abbie’s.Andrew reviewed some major sections of the draft document. Section 6, this is from the face-to-face (F2F) in May. One of the challenges with the previous version of the diagram is that it was hard to follow. So during the F2F, we came-up with a simplified example using the most frequent use case of transferring a lot of money when the user is already authenticated at lower assurance.Section 6.1.2, some of the look-up tables that have to exist to determine if trust-el is required and what is needed to satisfy the elevation requirement. The word document tables would need to be coded and installed and be readable and parsable by the method determiner. This section speaks to the need to describe how it might look. We aren’t trying to specify or constrain the repository. It is the concepts of trust-el that we are trying to come to common ground on rather than repository specific details. 6.2.2, the next table is the policy table. What we came to ground on is trust-el is policy evaluation. This table represents for each transaction risk level, for the specified uplift, the authentication methods required. At the F2F we discussed keeping state. There are a couple ways of keeping state. We need to know how the user achieved the level. The determiner informs the PDP.The situation with doing the tables this way is they are all established in advance (static). You will see in the preamble section that some combinations are not valid. The way to represent that is to not list them. If the policy is included it can be evaluated. If it doesn’t exist, it is not permitted. That is, it is a positive table. Next he described some process flows. He walked through a use case of decisions and methods that could be used. 6.1.4, sets out the information that needs to go back and forth. This is a way to determine the request response comments. He is trying to create a sequence diagram that encapsulates transaction 2.5, is implementation considerations. Abbie created some text that is not yet incorporated. Andrew asked Abbie to describe what he had written.Abbie is walking through a use case. If the app is expecting a specific LOA, what are the options to do that? How stepping-up could happen in the use case, and how it could be signaled.Andrew noted that once section 5 is done, the examples in section 6 can be updated so that the sections are reconciled. Andrew explained that Peter updated section 3.2. Andrew is still working on section 4.3Andrew has also rearranged the appendices. Appendix B is shortened. There is state diagram showing the time-based degradation of the authenticator. Andrew is still waiting to hear from John B and OIDC and OAuth. He will send a request to Eve to get a volunteer from the UMA group.Andrew suggested that Abbie may need to look at stepping up within, where you have a piggy back. We don’t support use cases with delegated authentication and access. An example is helping your mother-in-law. We define trust-el as additional AuthN info (step-up) or gathering of additional identity claims. That would currently be the place to invoke the whole delegation discussion.Abbie commented that it is too bad we didn’t cover that in the F2F. I think we need one meeting dedicated to that topic.Andrew replied this may be an additional example.Abbie suggested that UMA may help to address the delegation example.Don said we need to separate how the heart group is creating an OIDC/OAuth profile. Whose goal is it? Also the UMA group in Kantara is looking at consent flow.Until Abbie can talk, we need to not drop this ball.Colin agreed that Andrew has given us a way forward.Andrew will start attending their calls and aim to locate the specific heart use case that we want to use as an example and put in a place holder for that, (it is about patient enrollment at a doctor’s office) and see what cascades down.Don said making that specific to enrollment will be useful. The consent work on the UMA side is very complex for healthcare cases.Andrew asked people to read through the current version. He still owes the group a list of question to consider when reading the document. (For example, does your protocol have the ability to try again, etc.…)5. AdjournAndrew moved to adjourn the meeting.Don seconded the motion.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>anonymous morphed into Suzanne Gonzales-Webbanonymous1 morphed into Don Thibeauabbie: all we do have a webexabbie: https://aetnaonline.webex.com/aetnaonline/e.php?MTID=m17f9e023f90da9a7ccd1ebedaabaa763Don Thibeau: please send updated call in numberAndrew Hughes: (877) 658-8148 , (214) 556-4103; PC 58 5 07 44 9 77 #.anonymous morphed into Rick Grow |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]