[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for March 6 call
Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee March 6, 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)
58 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 Abbie asked if there were any objections to approving the minutes from February 6 and February 20. There were no objections The minutes for the two meetings were approved. 4. Presentation from Nat Sakimura – Chair of OIDF and co-chair of the OIDC working groupAbbie thanked Nat and John Bradley. He explained that we are looking at Trust-el between client and RP. Trust elevation can go both ways (elevate the client and/or the RP) we have asked if OpenID Connect (OIDC) can support this.Peter asked about time scales.Abbie replied 4 months.Calvin asked how confident Abbie was about the date.Abbie responded that at a higher level, he is confident. It is now about the details within existing standards (OIDC and SAML). If we decide to shift the work to other groups, we could be on hold until the actual work is done in those groups.Abbie continued we received money for an editor. We can’t release the final standard until we are a hundred percent sure the other groups are done.…Calvin asked is it possible to bring in the time scale a bit. To say end of May?Abbie replied the timing is not an issue now. We will focus on Nat now.Nat began. He prepared these slides for discussion. He doesn’t really know what we are trying to do. Since not all of you know about OIDF, here is basic info. It was founded in 2007. It has 200 members from 30+ countries. It has been doing specification standards and so far OpenID 2.0 and OIDC have been ratified as standards. OIDC was ratified as of 2-25-14. OIDC is the third generation. It is OAuth and JSON based. It is token-based. They do identity federation via ID tokens and can also provide aggregated attributes and distributed claims. ID token is a JSON based assertion (analogous to SAML XML based tokens). The JSON standard is at IETF. It may also contain other claims. Exp is expiry date. The assertion may be issued without re-authentication. ACR is like LOA. John said like SAML it can request an identity provider to meet some LOA. AMR is additional optional information. If methods are homogenous, may only care… in general we don’t recommend confounding the RP with specific auth methods. Otherwise it is brittle.Nat went through the general flow. Nat asked for questions.Nat then talked about OIDC request and response. There are two ways, as a parameter or as a claim in the request object. We can sort of do trust-el. OP is the OpenID provider or IDP. To get to the LOA-1 resource, the user requests the resource, ACR = LOA-1, it is redirected to the OP. The OP reads the ACR=LOA-1 request. The OP verifies it and if it is ok, it will return the token with ACR=LAO-1.John commented if you wanted to do LOA-2 or InCommon silver – if you wanted that you would ask for that as the specific authncontext.John continued assume started at LOA-1 and wanted to step-up to an LOA-2 context. The something is fundamentally orthogonal to SAML or OIDC. Doesn’t matter if use pseudo biometric on a device, it needs to conform to an approved policy. The interesting part is how do I know if the authnconext has degraded and the server detects it.Abbie commented I really like the way you are showing this. There is an invisible PDP that will determine to the resource what LOA is needed. There is still something after the OP in front of the RP that determines the assurance level of that resource. Keep in mind, the resource could be the same as go from LOA-1 to LOA-2.John said remember you’re talking about more parties, than normal. You have a protected resource and the service provider are not the same and you have an IDP or credential provider. Two of those parties may want step-up. For example, you are an API not a web browser, you need this additional scope, based on the additional scope the authorization server would step-up or one may be able to use fine grained requests to specify an individual authncontext. Need to determine what the current authnconext is.Abbie note you said the error response may drive the context of the next request. You can use the error message to change the state machine.John said if the API isn’t willing to satisfy the request based on the presented access token OIDC can say I want you to get this list of scopes from the AS. This can cover the cases when the client doesn’t have the right authnconext or the user hasn’t been granted assess to that particular resource.Abbie commented so we are covering the same cases here. It is within one trust domain. John said we could be federation between the auth server and resource server. Cross domain resource servers are covered in OIDC but not OAuth. That is the question of how do you federate an OAuth token which is a larger question.Abbie commented on the validation. We can authenticate with higher confidence based on better criteria. We may want to come back to you and inject that capability later. John commented there are ways to cross trust domains. Nat continued now the user wants access to a higher risk LOA-2 resource. The current station is LOA-1 so it doesn’t satisfy, so has to re-authenticate the user. So the auth request with ACR = LOA-2. ... If it is ok, it will return the token with ACE2. Now the resource evaluates the new token. If it is ok, than can get access.Colin commented so it is re-authentication. Nat said it assumes the resource can find the difference resource. I have magically assumed. How to find the current ACR can be an issue. One way is to remember. John said remembering doesn’t necessarily help.Nat said another way is to check id immediate.Abbie commented but this could be implementation – remembering may be ok for some apps, but this will be policy driven.John said right, may do check id immediately to refresh a token that has expired. That can allow you to, in a hidden iframe, check the identity provider. If there is an exception, you can bring up an interactive flow, but don’t want to necessarily interrupt the user experience.Abbe said this is very relevant requirement.Nat concluded so that is the basic OIDC way. John said we have an unfinished specification on session management. It is more ambitious than SAML. We want to provide a _javascript_ API that allows the RP to be signaled wen there are significant changes at the IDP. The user may have logged in with another credential. It may be monitoring your mobile device, or using some other continuous authN method. We want the session management to be able to signal to the RP that it needs to check with the IDP as there is a significant event, like the user has terminated their session.Abbie asked John how do you combine this with your NAC work? This may work for one app or for a group of apps.Nat said NAC, the native applications working group, is working on a proxy for the native apps that may be sharing a login session. That would build on top of this.The GSM is creating a standard for carriers in another working group. We are exploring other ways to provide continuous authncontext.Abbie asked how do we proceed from here. What we see today does validate our approach, but we need to dig deeper. You could do the work to support trust-el in OIDF or how do we address this. How do we formalize next steps?Colin said what they need is Shaheen’s early work. Abbie replied yes, Colin, .I know that flow. There is harmony, but it isn’t 1005 aligned. Need to understand how we should proceed. Do we need to have an official liaison or have one of our group be in your group? John said we already have a protocol and a bunch of methods and messages, so He isn’t sure. This working group started off researching something fairly abstract. Are you now working on a meta protocol?Abbie replied yes. You can negotiate in our protocol. Eventually it needs to be implemented in OIDC or SAML, etc. What you are showing here could potentially be the way to implement our protocol. We need to know how we proceed, i.e. to determine one way to implement.John commented we don’t know enough about what your protocol is at the detail level.Abbie said we will have something to share in a month: the conceptual design.John replied we would have to look at it and decide if it is a good idea or a rat hole.Abbie asked can you share those slides with us.John replied yes.Abbie concluded this was very helpful. Now we can go back to our TC and optimize.5. Editor updateNone.6. AdjournAbbie asked for a motion to adjourn.Gershon made the motion.Colin seconded the motion. The meeting was adjourned. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>anonymous morphed into John Bradley abbie barbir (BofA): 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 ------------------------------------------------------- abbie barbir (BofA): webex abbie barbir (BofA): To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://attend.webex.com/attend/j.php?ED=267269667&UID=1785079827&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". ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- Provide your phone number when you join the meeting to receive a call back. Alternatively, you can call: Call-in toll-free number: 1-8662226652 (US) Call-in number: 1-9809396928 (US) Show global numbers: http://bac.btconferencing.com/bankofamerica/globalaccess Attendee access code: 637 218 8139 abbie barbir (BofA): 1. roll call 2. approve minutes 3. editors update 4. Presentation on OpenId Connect by Nat Sakamura 5. roll call 6. adjourn Gershon Janssen: I'll join somewhat later... my previous is still ongoing.... Colin_NZ: OK, so we can still maybe use this to share dial in info..? John Bradley: So what are we doing now? abbie barbir (BofA): Call-in toll-free number: 1-866-7475167 (US) Call-in number: 1-704-6650860 (US) Show global numbers: http://bac.btconferencing.com/bankofamerica/globalaccess Attendee access code: 223 587 82 Colin_NZ: wrong passcode.. abbie barbir (BofA): Attendee access code: 223 587 82 abbie barbir (BofA): Call-in toll-free number: 1-866-7475167 (US) Call-in number: 1-704-6650860 (US) Show global numbers: http://bac.btconferencing.com/bankofamerica/globalaccess abbie barbir (BofA): Austria abbie barbir (BofA): 800070261 abbie barbir (BofA): 0280662408 abbie barbir (BofA): +43 1206091839 abbie barbir (BofA): New Zealand abbie barbir (BofA): 508098950 abbie barbir (BofA): 099151636 abbie barbir (BofA): +64 99151636 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]