[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes from February 6th call
Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee February 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 the last meeting. None heard. Peter moved to approve the minutes. Gershon seconded. The minutes for the January 22th meeting were adopted. 4. Colin’s comment about completeness of the second deliverable.Colin sent an email with the issue to the list after the last call. He had thought there might be an issue with the completeness of the second deliverable (that he had a use case that didn’t fit). After further thought, he does not think there is an issue.Peter commented it seemed to him that Colin was taking a sideways cut, rather than a real issue.Abbie asked do we need to add anything? There were no additional comments. No action needed.5. Editor updateShaheen is preparing the uses cases for the 4th deliverable. He is trying to convert the flow diagram into IDP/RP language. So probably by next week, he should have a draft to share with the editors. 5. Hal Lockhart from OASIS asked to come in to talk about SAML.Abbie started the WebEx.Hal began. He was asked to speak on the SAML methods that support Trust-el. He is also going to speak a little about XACML. Then he will walk thru relevant flows and discuss some profiles.Hal explained SAML 2.0 has been an OASIS standard since March 2005. It is also an ITU-T recommendation. Since then, people have been working on additional profiles. There are now 30+ documents that have reached the committee specification level. Most are new use cases. If you look at the spec it is actually 8 documents. We are mostly today concerned with the core doc, the binding doc: how those messages can be communicated over a network, and profiles which are detailed specifications that say exactly what steps are required or prohibited, which really is the foundation of interoperability. There is also a document on authentication context. SAML is a standard for communicating security information between parties. The basis is the assertion that can be accepted and receive over various protocols (SOAP or HTTP typically). The profiles say specifically how some use case operates in detail.Hal continued. Assertions are declarations of fact. There are 3 types: authentication, attribute, and authorization decision, which has been obsoleted as XACML which is more complete. All the assertions have the same header info. This piece was reused by XACML and SPML. The assertion has one or more statements as the meat. The statement we care about today is the authentication context and has a required time field and optional fields for manipulation sessions and has an optional field for location, currently IPS address. There is no specific support for geo location, although there are ways to support it. Hal explained AuthN context details exactly how this done. We describe the mechanism. The intension was that vendors with specific authentication mechanisms would define their own classes and publicize them. For 2.0, the approach was to describe the mechanism in detail, e.g. x.509 and key length. The approach was to treat each authentication type as a unique thing and describe it. We decide not invent any authentication method and not get it into questions of: is A stronger than B. That is out of scope and up to the deployers.Hal continued; the other statement of interest is the attribute statement, attributes that apply to a particular subject. It is analogous to x.509 attribute certification. Moving up to the protocol level, there are various protocols defined by SAML. AuthN request - response pair is relevant.There are fields that are important. When requesting Auth, you can specify the subject. Sometimes this is an important security option; sometimes the requestor doesn’t know the subject. There is a field request authnContext, that is the actual authn context; there is also a comparison field – exact, min, better or maximum. Min means I want something at least as strong as specified. Max means no stronger than what I specified.There are also two Booleans in the message, both are optional. One allows forcing an interaction at the time of the request (the request could be machine-to-machine but do need to freshly verify the auth.) Next is passive. If false, can force the human to act. If true, don’t force the human to interact. Between these two, can say force auth = true and is passive=false and can force an interaction with the user.You can send a request and specify what you want and whether it is ok if it was done previously, or if it needs to be done immediately.Hal said the only profile he will talk about is SSO. There are several browser driven profiles that use redirections. ATCP has a mechanism called redirect, in some cases can construct a _javascript_ object on the fly, and then execute the _javascript_. When we say redirect, we mean that loosely. It may or may not be a true HTTP redirect. The basic idea is the message is received, you decide you can’t handle it so you redirect it.The question is how you deliver the request response protocol. There are two approaches. The first is artifact. You do a query on the back channel to get the assertion. The more popular one is the form post. The assertion is put in an invisible field in a form and transmitted in that way.In SSO, the basic idea is request some authN and the IDP returns an assertion with at least one authN statement and may return attribute statements.Hal explained there are two general flows. One starts with the service provider (SP) and the user goes to access something and it is discovered the party is not logged in. So there is a redirect to the IDP. Then it does the authentication. Assuming that is successful, the IDP will record all this information in a statement in an assertion put in a signed response.The other alternative is the IDP initiated flow. Say the IDP is in a portal, you might go to the portal first and sign on, then you click thru to a service and the SP generates a response (there was never any request) and the response. So the key point is in this flow the IDP doesn’t know what the user is doing or the policy, it can’t do anything specific about what authN is required. If there is only one form of authN this works fine.Hal continued. By step–up he means the user is already signed-in with a weak mechanism, and needs to do a more sensitive activity, and the policy says the user now needs a stronger form of authN. This is not a special case, the first flow works just fine. Abbie commented so basically the step-up happens within a session. For example, you logon to the bank and initially get read only access level. If you want to do bill payment, that requires a higher level of auth, and after you have made the payment, you default back to the original auth level. This is the flow that we would like to support.Hal replied this is easily supported.Abbie asked do we need to do a profile to support this use case? Do we need to publish something?Hal said let me finish the slides first. There are two other profiles that maybe relevant. One is the identity assurance profile, a document that codifies the way to express LOA. An SP can request “I want a LOA-3 or better, etc.” The LOA is specified by a URI. You can use any scheme you want. But if someone else has a scheme for LOA you can use that. Through metadata, an IDP may say “I’m capable at LOA-x.” So one can choose an IDP on that basis. The profile addresses the syntax.Abbie said we can point to our work. Can you extend the profile: I can do LOA-1 and LOA-2 in a combo to get to 2.5? Hal said we may need to define a specific URI. It is up to the SP to know it needs a certain level, and it is up to the IDPCathy asked when you are working in an SSO context, if the original sign on was IDP 1 and the person goes to login into another RP at that same level, how is this negotiated? What if the second RP doesn’t recognize it? Hal replied the assumption is that all participants in the group have agreed to the process. Also the levels are URI’s. There shouldn’t be any ambiguity. In principle, all the IDP’s have agreed to the same scheme. There should be agreement on what methods reach that level or the SP would just know I need LOA-X. The IDP would be expected to understand the LOA standard being referenced. For those methods supported, they should know.Cathy said so in a federated environment, it would be up to the federation to establish the equivalence.Hal said one could have some IDP using UK standard and some IDP using US standard. Would use metadata to define. If sent a request to an IDP that doesn’t understand the request, it wouldn’t do it.Cathy said if it doesn’t match, the SSO doesn’t occur.Hal replied it is always up to the SP. The SP has to make a policy decision. SAML is not about policy, it is about communicating the information. Hal continued; the other profile is the SP request profile: ask for a resource and as a side effect get logged-in or stepped-up. The SP will ask the IDP for an auth of a given kind. The SP can expose the choice of auth to the user or not. It is purely a request to drive some kind of auth. I mention these two as being potentially relevant. Hal continued; he is co-chair of the SAML TC. SAML is an ITU-T recommendation. It is a language for access control. The SAML TC is also working on a JSON format. It can use any available info to make a logic decision. It is designed to scale. It enables federated policy definition. The basic idea is it has a blank box PDP. General attributes decide if this is allow, can return, permit, deny or non- applicable (could then chain the PDP). There is also indeterminate. This can be caused if can’t determine policy value because don’t have all the attributes requested. Will return missing attributes detail, which may include request specific value of something– say an LOA-3.There are many features in the core that aren’t profiled anywhere and it isn’t uncommon to hear that SAML doesn’t do x, but actually it is in the core but there is no profile, so there are no implementations. It is good to have profile so contractors can ask for it and vendors support it. To get this done in the SAML TC, you need a champion. Historically this type of thing is done as a profile. FICAM has 3 profiles. There are 30 total. The work can be done in the SAML TC or our TC. It definitely would be very helpful to define a profile around step-up. In particular, all the issues about what do you ask for and how does the IDP determine what you want, and what to do if you don’t quite get what you expect. It would be very useful to define that rigorously. Most of the pieces do exist.Abbie said we need to have the proper profiles done. I don’t know do you want to do it here or in the SAML TC?Colin replied it is more appropriate in the SAML TC. Colin asked SAML has no notion of session, is that correct?Hal said there is a profile for that and he wrote it. In a federated environment, a log out with very strong semantics is very difficult. There are no guarantees. It is not practical to enforce a person only being logged in to one place at a time. Abbie asked Hal if he looked at OAuth and SAML. The trend is to use OAuth on mobile, then go into SAML.Peter commented I’m not so sure we should be working on a SAML schema. We might want to be working on a SAML schema in the SAML TC. That may be the more appropriate place. Abbie said we may not need to do that. The resource will decide what auth it needs, once it comes to the conclusion, it needs to ask for more via SAML. Peter commented I hear what you are saying. I think we need to unpack that more. I absolutely agree with what you are saying about SP/RP. (Peter paid for the FICAM profiles to be written.) It is the RP that says what it wants as part of the auth process. So it starts through the RP through some mechanism, (probably SAML) that I want more, then the end-use’s proxy uses SAML to provide moreAbbie said there are people at the bank who want this to support SAML.Hal said he would first develop a clear statement of use cases. What is fixed and what will vary between deployments. Then we could present that to the SAML TC, and do the editor part. We can provide the technical assistance and bless it in the SAML TC. Making the profile part of our TC would also be acceptable, but it may be harder to get expert attention, but we would be involved and personally he could devote some time to help. Scott Cantor is probably the biggest SAML expert in the world.Abbie commented that is excellent Hal. As a second step, we need to identify any gaps with OAuth; and we need to support SAML to support the RP and SP.Peter replied definitely in the SAML workgroup. You are right. We will need to express this process in alternative methods. A SAML process may need to be translated to other processes.6. AdjournShaheen asked for a motion to adjourn.Mary made a motion. The meeting was adjourned. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>anonymous morphed into abbie BofAabbie BofA: agendaabbie BofA: Passcode: 637 218 8139US toll free 1-866-222-6652Int'l Toll: 1-980-939-6928- Australia, Sydney: +61 (0) 2 8064 4811abbie BofA: Webex: Meeting scheduled: Trust Elevation TC Bi-weekly-------------------------------------------------------To join the online meeting (Now from mobile devices!)-------------------------------------------------------1. Go to https://attend.webex.com/attend/j.php?ED=179798197&UID=1382908852&RT=MiMxMQ%3D%3D2. 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".abbie BofA: 1. roll call2. agenda bashing3. approve minutes4. edior updtae5. Hal Lockhart form SAML TC to speak about SAML support for step up authenticationsee https://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2575 6. roll update7. adjournabbie BofA: hal is on the Webexabbie BofA: all please join it for the slidesabbie BofA: you can also download the slides from the website https://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2575anonymous morphed into Mohammad Jafari (VHA)anonymous morphed into Colin_NZCathy Tilton: I have to leave, but am interested in having biometric methods added to the list of SAML authentication contexts. Perhaps we could work with the Biometrics TC on this?Gershon Janssen: bridge connection dropped.. redailing... |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]