1. Administrative section

Date and Time

Date: 4. Feb 2013

Time: 11:00 PDT | 14:00 EDT | 20:00 CET | 08:00 NZ(+1)

Role Call

Allan Foster

Andrew Hughes

Anil John

Colin Wallis

David Simonsen

Denny Prvu

Keith Uber

Ken Dagg

Lena Kannappan

Rainer Hörbe 

Sal D’Agostino

Scott Cantor

2. Agenda

2.1 Privacy Enhancing Web SSO

Anil: (on NZ RealMe consent service extension of its igovt logon service) I see blurring between WebSSO and Consent. Is there a more visual description of the flows ?

Colin: There is a swim lane diagram in each of the RealMe docs, but you really need to see all of them. Will try to find/publish something from earlier years which shows the ‘basic’ logon service to RP flow, and the later Context Mapping (web) Service, which equates to a kind of SSO but without the identity info flowing through the logon service (broadly described as an IdP but with no identity info).

Thomas: Are these requirements are really necessary. What are the canonical requirements?

Rainer: Stating the both requirements and solution architectures where part of the work item, so your question does fit here.

Scott: Privacy enhancing techniques add some benefit, but does not solve the problem of IP addresses.

Colin: Sure, even in our case where the logon service is stateless, and even with an artifact binding, and even with some services requiring parking the browser and doing back end web services, there is always some kind of ‘privacy leak’. Comes back to Thomas’s point that the user has to trust someone until there is a technically elegant way for the IdP to be (or be in control of) the user, such as with a user’s TPM mobile phone.

Andrew: What is the canonical list of privacy principles? There might be multiple ones. In my world they do not contain unlinkability and unobservability.

Thomas: How resistant are different models to different attacks? If the login service (along with its various facets like the credential provisioning service) is compromised, then everybody is revealed. Other architectures with minimal disclosure might be more resistant.

David: There might be an incomplete match of business models. Some providers must see where the authentication request originates from (e.g. government agencies). It is a requirement on the IdP side.

Matt: The ISP knows where you are going. Forensics requirements (.. ?)

Thomas: In some architectures you get privacy and accountability, e.g. identity escrowing techniques.

Rainer: At the ISOC FAB-meeting in Prague (Nov 2012) Ken Klingenstein looked into the possibility of integrating ABC4Trust (a project integrating uProve and Idemix) into SAML WebSSO. This looks like a lot of integration work. ABC4Trust did not address a number of topics that are solved in current federations.

Scott: I see no evidence that it is crucial to have privacy enhanced WebSSO. It would be a complete platform change. This will not happen if there is not both regulatory and user pressure to do so. Google/FB set a very low bar. What is the economic incentive to develop better privacy then?

Colin: You are saying that WebSSO is good enough then …

Scott: .. Certainly when compared to the alternatives on the market. There are easier targets to go after than unobservability. In particular in the US, because user data can be shared anyway.

Anil: I have a different view of that situation than Scott. US Govt is not as trusted as Govt might be in other places. Therefore we bend our back to put in place mechanisms to prevent data broking with user data in government web sites. For delivery for G2C services we need to make this investment. We need to prevent private sector IdPs trading this data.

Anil: Privacy principles (e.g. USA’s FIPs) – can we identify some common principles, at least from eGov perspective where Govt is RP?

Colin: Privacy legislation people are not really investing in technical reflections of the legislation to help developers with Privacy by design type support. Waiting for ISO to lead the way, like 29101.

Scott: Where do you see the pressure to build these solutions?

Anil: (? - Response not recorded).

Lena: Need to broaden the scope to BOYD and mobile deployments. We need to have this aspect as well, not only traditional web based IdPs.

Scott: We need to have options, choices of deployments, market, competition, low barriers, lots of IdPs.

Thomas: Extreme method would be the user-managed IdPs.

Scott: That’s the end state, but not practical/realistic soon.

Matt: CardSpace/IMI: nice technology. Lack of support.  We need to consider the market (mobile), to prevent new solutions having the fate of IMI.

Lena: In the federation context, uProve will not get support because it does not deploy well on mobile devices.

Rainer: How would you rate the Proxy solution vs other technical approaches?

Matt: Makes sense from technical side. On uProve we would wait for a long time.

Colin: NZ has an investment in this proxy-type architecture, so naturally rate it better than folks that don’t.

Scott: I am anti proxy. They are vulnerable for abuse. They might be useful for other reasons, but not for privacy.

Lena: Proxy and broker can do the same job.

Scott: Proxies provide no arbitrary choice, but one more actor in the equation. For me the only defense is choice (i.e. brokers), better than tons of proxies.

David: SPs have to negotiate with someone else about attribute release. The proxy should not have an interest; therefore it is more strict on attribute release. If the power of negotiation is with the SP, the equation changes.

Scott: Issue of attributes is overblown – if you have one, you usually can get the others in a model of some 4 core identity attributes. Would be different if you have a much more rich attribute model.

David: We operate 15 different attributes. We see the pressure to get more attributes.

Scott: SPs have a bias not to bother about attributes, because they would have to go to so many places to get them.

David: Who is driving the service palette? Is it the service consumer department?

Denny: The requirement usually comes from the technical side. Proxies do the filtering to fix the attribute set.

Colin: It becomes complex when you have several attribute providers needed to deliver a service to a user in a transaction. We have a backend (web service – context mapping service) to fetch those attributes from one agency to the other that is delivering the service to the user whose browser is parked at their web site to ease poor user experience by repeated browser redirect. Attribute release is done with the directed consent of the user.

Next Meeting

Date and Time

Date: 4. Mar 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: 597 795 626 
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=218781852&UID=1559870282&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=218781852&UID=1559870282&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". 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=218781852&UID=1559870282&ICS=MI&LD=1&RD=2&ST=1&SHA2=SOvae61506JiDql0knOL248gNFhnxm3bbcQFvSXqFno=&RT=MiMxMQ%3D%3D