Unobservability: Summary of discussion in eGov-WG

Problem statement: Trusted third parties like Identity and Attribute Providers tend to accumulate a lot of traffic data and 'RP graph' data about its user population. This might create some risk, in particular when identities are used across domains like professional and private context or different government agencies.

Requirements 

(t.b.d. How can these requirements be deducted from FIPs? Is a Privacy Impact Assessment needed? Is there a requirement at all?)

Solutions

Discussion in Kantara eGov WG listed approaches to mitigate this risk in 5 categories:

Identity Escrow. The IdP/AP is taken out of the interaction with the RP, using cryptographic technologies like in Idemix and uProve. This provides an assertion to the RP without the IdP knowing to which RP they are asserting an identity for.

Pro: Technical control that satisfies the unobservability requirement

Con: (1) Capability of large-scale deployment not in near future; (2) Issues with other requirements (revocation, federation, IdP/AP business model); (3) Increased user dependency to trust technology provider.

Late Binding. Credential Providers provide pseudonymous credentials to users, and RPs will bind attributes to those credentials. While traffic is observable, it is difficult for IdPs to link the RP-usage graph with known users.

Pro: Straightforward architecture, goes well with existing technology.

Con: (1) As IP-addresses are unavoidable an address-lookup (or worse cookie-stealing) will weaken this control. (2) The burden of binding attributes per RP diminishes the benefit of identity federation so some extent.

Proxy Pool. Proxies that play RP to IdP/AP and IdP/AP to RP can significantly reduce the amount of data collection, if there is a large enough number of them.

Pro: (1) Lives with existing (SAML) technology, and (2) a proxy (broker/hubs) has commercial advantages in certain cases servicing SPs.

Con: (1) Proxies provide no arbitrary choice, but one more actor in the equation and add vulnerability. (2) Limited constraint, should however improve with scale of federation.

User-based IdPs. As proposed by IMI, the client would hold the credentials.

Con: (1) deployment problem and (2) with PKI-based credentials there is still the tracking issue with OCSP-responders.

Organizational Controls.

(a)  Providing choice with IdPs and enforcing transparent and efficient markets will drive providers to comply with privacy requirements.

(b)  Regulation with preventive organizational safeguards, liability and legal enforcement will mitigate the risk.

Pro: This works well in the financial services industry, where banks have a panoptical view on financial transactions, but are still trusted due to the regulation.

Con: Not a technical control, abuse would be possible without collision with another actor.