[DG-IDoT] Fwd: [WG-UMA] NIST Seeks Comments on New Project Aimed at Protecting Privacy Online

Scott Shorter sshorter at electrosoft-inc.com
Fri Nov 6 09:32:31 CST 2015


FYI an interesting conversation, and see Eve's link for that paper I
mentioned.

---------- Forwarded message ----------
From: Eve Maler <eve at xmlgrrl.com>
Date: Thu, Oct 29, 2015 at 2:23 AM
Subject: Re: [WG-UMA] NIST Seeks Comments on New Project Aimed at
Protecting Privacy Online
To: Mark Dobrinic <mdobrinic at cozmanova.com>
Cc: "wg-uma at kantarainitiative.org UMA" <wg-uma at kantarainitiative.org>


Okay, I’ll be the contrarian, just for fun.

As I commented to a couple of people regarding the relatively recent
academic paper Toward Mending Two Nation-Scale Brokered Identification
Systems
<http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/popets15-brokid.pdf>,
everything is tradeoffs. And it’s arguable that the governments in those
cases made the operationally and more citizen-acceptable tradeoff for
privacy vs. what the researchers recommended.

Quoting/paraphrasing myself from previous threads on this topic:

I suspected from a brief article
<http://www.computing.co.uk/ctg/news/2414194/govuk-verify-identity-management-system-riddled-with-severe-privacy-and-security-problems-warn-ucl-academics>
on
the subject that the reporter probably had trouble divining exactly what
the problem with the FCCX and UK.Gov <http://uk.gov> Verify systems
actually was, since it wasn't explained at all, nor what the proposed
solution was... and it's all extremely subtle. And I'm not even seeing a
huge outcry or even all that much gov followup/panicked defense after.

The researchers found a limitation in the tradeoff choice that the FCCX and
UK.Gov <http://uk.gov> Verify system designers made. This tradeoff
prizes the ability for the user to use an online service ("relying party")
and an identity provider, free from worrying that the two will discover who
the other is, over the perfect ability for a pseudonymous identifier and
attributes representing the user to pass unseen through the broker in
the middle (the broker makes this "service blinding" possible). The
researchers propose some clever encryption tricks to guard against
the broker seeing things, and go further and propose a new user-chosen
"identity integration" service that could handle the tricks. Given
that brokered systems, and the "older" protocols such as SAML already in
use, and the encryption tricks they suggest, and user interfaces that force
users to choose services, are all considered extremely heavyweight and
expensive in various ways, I give the researchers' suggestions a nil chance
of succeeding in the current environment. And given that users have a
variety of incentives to share enough attributes in everyday circumstances
to routinely become identifiable (Latanya Sweeney's research in particular
is famous for discovering these properties), it's very questionable whether
the researchers' preference for tradeoffs vs. the nations' preference is
the correct one.

On 25 Oct 2015, at 7:49 AM, Mark Dobrinic <mdobrinic at cozmanova.com> wrote:

Yes, that.

Always looking at privacy from linkablility and anonymity perspectives.
An Identity Broker with privacy in mind has the responsibility to
protect those properties. Through policy, but also some funky
cryptography could be applied to assist there.

But yeah, in the end they have the potential to only make things worse
from a privacy point of view, and not better.

Cheers!

Mark

On 24/10/15 08:24, Justin Richer wrote:

My view on this remains “to increase privacy get rid of brokers”. A full
mesh SAML or PKI federation is untenable, so that’s why we’ve deployed
brokers in the past. But OIDC, with dynamic client registration and
server discovery, is built for this. I believe wee need to move towards
this model.

Is anyone interested in writing up a response to that effect with me?
Perhaps we could run a session on it at IIW this week for those of us
that will be there (including myself).

— Justin

On Oct 23, 2015, at 8:29 AM, Andrew Hughes <andrewhughes3000 at gmail.com
<mailto:andrewhughes3000 at gmail.com <andrewhughes3000 at gmail.com>>> wrote:

Hi UMAnitarians - not sure if you've seen this notice yet

I'm vice-chair of IAWG & we are probably going to assemble comments on
this.

"Privacy-Enhanced Identity Brokers"

Comments to inform a new collaborative project & eventual 1800 series
Practice Guide at the NIST NCCoE

Due 18 December

http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

o  +1 650.209.7542 <tel:%2B1%20650.209.7542>
m +1 250.888.9474 <tel:%2B1%20250.888.9474>
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000 at gmail.com <mailto:AndrewHughes3000 at gmail.com>
ca.linkedin.com/pub/andrew-hughes/a/58/682/
<http://ca.linkedin.com/pub/andrew-hughes/a/58/682/>
*Identity Management | IT Governance | Information Security *


_______________________________________________
WG-UMA mailing list
WG-UMA at kantarainitiative.org <mailto:WG-UMA at kantarainitiative.org>
http://kantarainitiative.org/mailman/listinfo/wg-uma




_______________________________________________
WG-UMA mailing list
WG-UMA at kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma


_______________________________________________
WG-UMA mailing list
WG-UMA at kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma



Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl |
Calendar: xmlgrrl at gmail.com


_______________________________________________
WG-UMA mailing list
WG-UMA at kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma




-- 
==========================================================
*Scott Shorter, Principal Security Engineer*
Electrosoft *–* Fueling Customer Success Through Outstanding Value and
Trust!
*Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2 *
sshorter at electrosoft-inc.com (Email);   http://www.electrosoft-inc.com (Web)
==========================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20151106/24680146/attachment.html>


More information about the DG-IDoT mailing list