[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes from February 20th call
Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee February 20, 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)
71 percent of the voting members were present at the meeting. We did have quorum. 2. Agenda review and approvalWe 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. The agenda was approved. 3. Approval of the Minutes We deferred voting on the minutes from February 6, so next time we need to approve two sets of minutes. 4. Editor updateAbbie said we need one more editor. He asked for volunteers. Cathy?Cathy said she will get back to Abbie offline.Abbie it would be good to have a bridge with IDESG and also with ITU-T. He said to put him as a co-editor temporarily.Shaheen explained that where he needs help is filling in with the actual meat. He needs to transfer the meeting into the document. He time is challenged.Abbie said we have funding as an editor.Steve reported that to date we have not received any comments on the third deliverable.Shaheen began to go thru the slides on WebEx.Abbie asked should we say Trust-el specification or should we call it a protocol. He wants to say process.Colin asked what is wrong with specification. Abbie replied we want to say this is for an interoperable process. If we call it a protocol, that causes alignment problems with ITU-T.Abbie continued, we need an acronym that is “catchy”. We need to have a competition.Shaheen began reviewing the slides of the current draft. He explained everything remains the same until slide 6, he thought about the process for coming-up with use cases. Abbie commented authenticate with factor 1 should be factors or agreed factors. The IDP could be a set of IDPs. We need to have some general purpose diagram for the general model. For now, with tight coupling, it may default to the traditional triangle. All the attributes may not be accessible for a transaction at the same time. As long as they combine to a policy acceptable number, they may be sued.Shaheen replied we will change that to authenticate with agreed factors. In this whole process, we want to separate these entities and make them stand by themselves. The LOA assessor and trust-el determinator will need to work hand and hand. Abbie said that makes sense. But the violet box is a policy informer. Is it a PEP?Shaheen replied kind of. It is more determining.Abbie said you can determine LOA-2, but the app may say this credential is LOA-2, but not good enough for me. That is the difference between the assessor and the determinator.Shaheen said the RP will ask who is the IDP that provided the credential. I may need to look for an IDP that supports NIST LOA-x.Abbie said the assessor is saying this is a valid combination of tokens. The assessor may connect from the DMZ to the back end and say this is what was used to authenticate and we have LOA-y, what can you do with that number? It will be an input to the policy engine. There may be more than one entry point depending on the application and transaction requested. That violet thing (on the diagram) is also the connection to SAML and UML and XACML. So we need to investigate it more.Abbie noted we need Peter’s opinion on what Safe-BioPharma will expect.*** Action item for Abbie to follow-up with Peter.Abbie said we need to be very careful with our flows. Authentication flow is different from authorization flow. Some may be entry points to a policy engine. That engine takes different parameters.Abbie said the boundary needs to be clearly established.Shaheen said let me know if the violet box needs to be changed. Abbie said with the bank, we have a clear differentiation between the entitlement engine and policy engine. Abbie continued we can have different flows later, after we agree on the first flow on this slide. We can optimize depending on whether we know the device or not. We can tokenize, but need to know where it came from. We don’t need to ask all the questions each time.Shaheen asked what if we want the trust-el for a critical transaction. We need to provide a provision for time out after the transaction (e.g., step down immediately).Abbie replied, of course.Abbie announced on the next call we will have Nat from OIDF to present on OpenID Connect.Shaheen said next is Slide 14, use cases. I have a device, I want to use a RP, the RP says your presented credential came from this IDP, it needs to check is it the right LOA, and goes to the determinator, then performs the step-up.Abbie commented this is nice.Shaheen moved on to use case 2. The difference is the LOA assessor and determinator are operated by separated entities. The IDP just provides credentials, and you rely on the assessor. For example, I’m coming from a Blackberry registered to this institution.Abbie said a bank need to know the user is really x, not fake x. There may be a federation between Amazon and a bank, but the bank may layer multi-factor. Abbie said it is the norm for IDPs to also provide attributes. So we need to start including the attributes. We need a use case where the IDP is an Attribute provider (AP).Shaheen began the 3rd use case, multiple IDPs that can talk to each assessor. Abbie said we can call them identity service providers. They may be an IDP and or AP.Cathy commented we need a standard language for this.Abbie replied we need to synchronize terms with ITU-T.Colin commented on use case 3, it is only the IDP 2 that would be an attribute provider.Shaheen began use case 4; this is using an out of band authentication. You come through your laptop, but I know you have a registered phone to augment the authentication. So this is a case with a second device.Abbie said device two could be wearable in proximity with device one, with a pre-established handshake.Shaheen said if I use my laptop, the RP sees this registered device and knows I also have a registered phone. Abbie said if I am issued a device and need a handshake before use, we need to not exclude proximity.Shaheen replied then proximity is another context.Abbie said he has another use case. I think we are using the traditional road, where the server tells the client it is not good. We also need to elevate trust in the server thru the same route. We need to make sure the RP is not a fishing site.Shaheen said there is new work on certificate validity.Abbie commented the whole certificate system is broken. Even with the mutual trust between Facebook and the server, we can use that info for trust. Even the fact that Facebook trusted going to the website, helps to establish the validity of the RP.Abbie said we need to scope the trust.Steve said an outstanding issue is timing.Colin commented we need to try to get a list of the attributes in the message. In an LOA assistance request, there may be 6-7.Abbie replied you are right Colin, in an OAuth implementation.Abbie commented this has been a good call. We are progressing. 5. AdjournColin asked for a motion to adjournShaheen seconded the motion. The meeting was adjourned. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>anonymous morphed into Shaheen Abdul Jabbar (JPMC) Shaheen Abdul Jabbar (JPMC): running a little late... will join in 2 minutes Shaheen Abdul Jabbar (JPMC): ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://jpmchase.webex.com/jpmchase/e.php?AT=MI&EventID=285493812&UID=0&RT=MiMxMQ%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://jpmchase.webex.com/jpmchase/e.php?AT=MI&EventID=285493812&UID=0&ORT=MiMxMQ%3D%3D Gershon Janssen: Joining late... previous overran... |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]