[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: For Shaheen: RE: [trust-el] Notes from Jan 22 call.
|
Shaheen I see an action down to me on these Minutes. (Sorry I did not pick it up in time for today’s call.) Not sure what notes I took.. Mary’s are the only notes I think I have.. and they’re pretty comprehensive. Can you deduce whatever points I was trying to make, from them? Cheers Colin
From: trust-el@lists.oasis-open.org [mailto:trust-el@lists.oasis-open.org]
On Behalf Of Mary Ruddy 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)
75 percent of the voting members were present at the meeting. We did have quorum. 2. Agenda review and approval We 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 Don asked if there were any corrections for the minutes posted. Hearing none, the minutes for the January 8th meeting were adopted. 4. Editors Update on 3rd deliverable.
Mary congratulated Steve for getting the third deliverable into public review.
Don echoed this.
5. Presentation for 4th deliverable
Shaheen distributed a .ppt (first draft) on the Trust Elevation Specification yesterday.
Abbie set it up on webex.
Shaheen began with slide 2. We have a framework and we are trying to come up with a spec to retrofit existing authentication (AuthN) schemes. He reviewed specifications we have considered as a starting point so far. We could extend a framework to meet the need.
Slide 3, review of goal.
Slide 4, approach, he asked if there were any OIX restrictions on using JSON.
Colin commented there was an obvious question, why are SAML and CAS not on the list?
Shaheen replied that the rest of the presentation is on SAML. SAML is a framework.
Don commented that OpenID Connect is expected to be finalized on Feb 26. OIDF will launch it from the RSA show (in San Francisco) and Mobile World Congress in Barcelona.
Shaheen went through this process and the use case sequence from deliverable 3. He found that everything from user to auth service can stay as is. When the auth service talks to the trust elevation method determinor, we want to make sure that it talks with the same language. If the LOA assessor and trust-el assessor are independent entities, they can work together. That is the mind set for this draft. He asked for questions.
Peter said it was not clear what you mean by what we considered. We also considered a lot of techniques in the previous deliverable.
Shaheen replied it is more what frameworks we considered. This is just an initial draft.
Next
Cathy asked if the user is logged in at LOA-2 and the request is at LOA-3, it knows the details needed to get to LOA-3? Is that the idea?
Shaheen said the auth service may know the level of the login. Does that makes sense?
Peter agreed.
The token will be a SAML assertion. That we don’t have to reinvent.
Cathy asked what statefulness will be required. If you are elevating trust from one level to another it requires information about the original trust level. Someone in the system needs to know that.
Peter replied absolutely.
Shaheen said you are right.
Colin said we need an implementation specific way of establishing that.
Shaheen said he should have included existing LOA, so the auth service can determine what statefulness currently is. The response the assessor provides the auth service is evaluated to see if it if it is enough. If not, it sends the info to the determinor to learn what method should be used to elevate trust. Then the service tries to authenticate the person using the identified technique. The type of info that will be sent from the auth service to the assessor may vary if all are independent services. The auth token could be SAML or another token. The token needs to be examined. What is the time span of this token? is the token untampered? Then we have the auth context element, location, time, etc. Should we be specific about the types of attributes, or keep it open? Any thoughts?
Colin said he is definitely veering to the latter, as a list would get long and date quickly if we try to list it up front.
Shaheen said yes, let the assessor decide.
Cathy commented she likes that one can specify a token. In NSTIC policy, can only request an LOA, not request more specifics.
Abbie said discovery of what is supported could be done by offline negotiation or online. There should be something like WS-policy. Need to go through triangle of trust. This may be an option, specified or not. Discovery should be part of what we do. It should be an end-point that could be used.
Shaheen asked discovery of what LOA you are using?
Abbie said if the RP requires LOA-3, but the IDP only goes to 2.5, then the transaction can’t go through. Not every LOA request could be fulfilled.
Peter replied that is interesting point. We need an exit for requests not fulfillable. Are there any suggestions for how to tackle that?
Colin said this is now a discussion of details. We need to provide something better than an error 404 message.
Shaheen said the table in deliverable 3 had multiple options. We need to specify what LOA we are using, and this would help service providers doing this LOA assessment. For this token, this is the LOA that we find, so there is an assertion from the assessor this is the strength and you can trust me. Does that make sense?
Peter replied yes it does.
Shaheen said going back to the diagram, once you know LOA, and if it is not enough, then the determinor needs to determine what it should use to elevate trust. That request would have all the information in the LOA assessment request plus response from assertor and send all to the determinor. There should be options for format. (Still on slide 5)
Shaheen asked does it make sense?
Colin replied sort of. Too much of 800-63 is telling me there is a different way of describing this. I don’t disagree.
Abbie said one could do a specific binding of SAML or OIDC.
Shaheen said yes, that is the idea.
Abbie said Nat spoke to ITU-T and he presented OIDC. Abbie asked him where on his flow one could plug in trust-el. It is doable because they have an end-point for auth context. Can jump outside for resolution of that. It is not clear if you can negotiate, but the point is the extension point in OIDC is already here. He asked Nat to present to the TC and Nat agreed. So we have one option.
Abbie said they are working on the multi-agent work for mobile devices. They are inserting a token agent. This is how RSO will happen on the mobile device. He said that same trust-el could happen in a group. So we will also negotiate an extension point with them. This is the way it will be on smart phones for the foreseeable future.
Don said as one of the co-chairs of the working group, he can present,
Abbie said he sees us doing an open source implementation. He thinks we would do all a favor if we could plug in with Gluu and OIDC, etc.
Colin commented that WS-Trust should be on list of frameworks in slide 2.
Abbie said we can plug this into Ping too. They have a nice implementation of WS-Trust. Don, can you call in John Bradley?
*** Action item for Don to call in John Bradley.
*** Action item for Colin to send Shaheen his notes.
Abbie said we need to document this is the format of the fourth deliverable.
Don asked if there was any other business.
None noted.
6. Adjourn
Don asked for a motion to adjourn
Peter and Abby made a motion
The meeting was adjourned.
Don said he appreciated Shaheen’s courage of the first draft.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
abbie: on the call on skype so i will be on mute
anonymous morphed into Shahrokh
anonymous morphed into Shahrokh
Mary Ruddy: very little snow in boston
abbie:
https://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php
don thibeau: What are some good links to find out more about OpenID Connect?
The OpenID Connect Work Group site is a good place to start. Also the Work Group leaderss blog sites are helpful Mike Jones at
http://self-issued.info/?p=1160 and Nat Sakimura at
http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/
don thibeau: As part of its collaboration with the OpenID Foundation, the GSMA is building a profile for mobile network operators based on
the OpenID Connect standard. Both organizations are getting ready for a simultaneous launch of OpenID Connect at the Mobile World Congress in Barcelona and the RSA Show in San Francisco on February 26th.
don thibeau: We will be following up with OpenID Workshops in London and working closely with the OIX UK IDAP pilots and the four Mobile
Network Operators in the UK the first week of March. Part of these pilots will engage trust elevation in government and commercial contexts |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]