2013-01-07 eGov Meeting Minutes
1. Administrative section
Date and Time
Date:Â 7. Jan 2013
Time:Â 11:00 PDT | 14:00 EDT | 20:00 CET | 08:00 NZ(+1)
Role Call
Anil John
Scott Cantor
Thomas Gundel
Colin Wallis
Rainer Hörbe
Sal D’Agostino
Ken Dagg
Allan Foster
Matt Tebo
Approval of minutes from Dec. meeting
Ken asks to change Bob Sunday’s affiliation from „ex-Fed Canada“ to „individual“
Subject to the above change, Ken moves, Rainer seconds
2. Agenda
2.1 Privacy Enhancing Web SSO
Colin: Same topic under different names at different places? It seems closely related to joint Kantara eGov/FI WG project to update eGov SAML 2.0 Conformance/implementation profile, and to integrate ‘refresh efforts’ from Saml2Int and various eGov deployment profiles. The topic was also discussed at the last FI WG Meeting in December.
Rainer: the scope is not unlinkability of PI between SPs (this is well understood and deployable), but non-traceability for IdPs and APs (for example in a IdP initiated flow).
Scott: Higher Ed see no incentive in doing work on this; In particular since businesses (Google, FB) make it a business model to collect and use data of their users. However, session keys give a lot of visibility .. More incentive around increasing security - market pressure is increasing against protocols with minimal security and privacy.
Matt: Trade-off between privacy and Security is a question of policy.
Colin: US wants to bring the requirements of a refreshed FICAM deployment model to Kantara.Â
Anil: Current eGov profile is a conformance profile. Are we refreshing eGov profile with updates from SAML 2.1? The challenge I have with deployment profiles is that it requires me to bake profile features deeply into products.
Scott: Implementers should not use deployment profiles, they are for deployers. Conformance/implementation profiles are for implementers.
If deployments could be better aligned, implementation profiles could be made smaller.
Regarding SAML 2.1 and the eGov profile, the reality is the reverse. eGov 2.0 profile is in effect feeding back stuff to 2.1, so not a lot of work will be needed on the Kantara side, because 2.1 will be more aligned.
Remark: Governments who don’t want to do MetaData-based trust would need to agree on a PKI-based trust profile to achieve Interoperability. Primary authors of eGov profile do support PKI in this way and therefore did not write it into eGov 2.0.
Colin: Canada has a number of deployments underway/planned with the current CATS deployment profile.
Ken: CATS restricts the eGov profile a bit. Going forward, do not know if more profiles needed. Comments are lacking. From technology point of view SAML will respond to needs, venders will implement what is requested.
Rainer: Géant is sponsoring a project at fed-labs with the involvement of the Austrian government to elaborate SAML test cases. That is a possibility to help SAML profiles converge. Kantara FI-WG is involved in the effort.
Colin: Asks for comments from other deployers (Anil/Matt, Thomas)?
Anil/Matt: Interested about posting ideas about privacy. Interoperability of Authentication is a solved problem, but MD is still a big pain. In 2004 plain SSO message exchange did not work, today that is OK. But privacy control, MD, policy is difficult.
Thomas: Danish govt officials are not seeing problem with interop, there is no existing need for updates. On privacy side a handful of IT architects would like to work on the topic, but the message did not arrive at the govt. U-Prove pilots show nice features, but the motivation to improve privacy not showing up on the govt agenda yet.
2.2 New topics for 2013:
Rainer suggests to ask a few volunteers (6?) to give short presentations (e.g. 10-15 Min) about achievements and issues in their (eGov) domain. This shall serve for mutual learning and support.
Rainer: SAML Test cases are a topic at FI-WG; eGov-WG only reporting in/out.
Blog from Anil (attribution to Ken, Andrew Hughes and other IAWGers). http://blog.aniljohn.com/2013/01/separating-token-attribute-model.html I did only mapped the terminology and framework to NIST 800-63-1. If the entity who is linking credential and token is not RP, then there is a lot of discomfort (privacy-wise).
(Remark: that why there HoK exists, yes?)
Anil: Canada Treasury Board is doing work on anonymous credential coming from 3rd Parties, and keeping the identity binding ‘in-house’. What are the trade-offs?
Ken: Practical reasons to do this, plus a very active privacy commissioner. Design started in 2004/2005 to come up with a solution that would have her blessing. That solution had to be reasonably simple, and technical issues could be overcome. Had a massive learning experience during the last years. How do we bind identity attributes, without having to do it at each department, which is both costly, complex and (CW:) duplicates PII.
Anil: WAYF solution is an alternative approach - has centralized consent solution. Vendors do not see that as a requirement – more a general trend in demand.
Colin: NZ also building a centralized consent solution for its refreshed igovt solution ‘Real Me’ (see eGov wiki ‘outside contributions’ for draft papers). In NZ, attributes can only be transferred across a domain if user has given consent beforehand. Or there is a very cumbersome privacy invasive out-of-band process to get around that using information sharing agreements between govt agencies which in effect overrule the privacy legislation. Therefore the deployment profiles should include the ‘directed/informed consent’ feature. (In NZ the privacy legislation mandated for govt, encouraged for private sector).
Ken: CA has same restriction around consent. However, govts are a small part of the universe in terms of # of transactions. (CA: general rule)
Rainer: Suggest to handle the privacy/do-not-track in steps: (1) collect requirements (e.g. how are requirements derived from DP law?); (2) collect and review solutions; (3) review impact on eGov profile. Let us handle the topic first in eGov (mostly govt issue). Then we can move results to FI WG if there is a need to enhance a profile in step (3).
AOB
Invitation letter
Colin: I hoped to be able to show the contacts list to send the letter to, on webex for this meeting but not available. Will do so next meeting.
Â
Next Meeting
Date and Time
Date:Â 4. Feb 2013
Time:Â 11:00 PDT | 14:00 EDT | 20:00 CET | 08:00 NZ(+1)
This call will be using WebEx. If you are using WebEx the first time, please try to joint the test meeting in advance to verify that you browser settings are sufficient.
Meeting Number: 591 288 060Â
Meeting Password: (This meeting does not require a password.)Â
-------------------------------------------------------Â
To join the online meeting (Now from mobile devices!)Â
-------------------------------------------------------Â
1. Go to https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=218430412&UID=1557917202&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 view in other time zones or languages, please click the link:Â
https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=218430412&UID=1557917202&ORT=MiMxMQ%3D%3DÂ
-------------------------------------------------------Â
To join the teleconference onlyÂ
-------------------------------------------------------Â
DIALÂ INÂ INFORMATION:Â
Skype:+99Â 051Â 000Â 000Â 481Â
Conference iD: 613-2898Â
USÂ Dial-In:Â +1-805-309-2350Â Â
http://kantara.atlassian.net/wiki/display/GI/Telco+Bridge+InfoÂ
-------------------------------------------------------Â
For assistanceÂ
-------------------------------------------------------Â
1. Go to https://ieeemeetings.webex.com/ieeemeetings/mcÂ
2. On the left navigation bar, click "Support".