I'm just talking security. Things like FIDO and ApplePay make sense because they link authentication to a secure and non-repudiable credential. I don't see any obvious reasons why communities and institutions would not move to a higher security process that assumes that everyone has a secure element controlled by a biometric and a recovery mechanism around it. Apple's new laptops just joined smartphones and tablets in this respect.

Adrian

On Wed, Nov 2, 2016 at 3:58 PM, Eve Maler <eve.maler@forgerock.com> wrote:
Even the Sovrin materials mention IdPs as one kind of "customer". And I've learned (through the hard experience of "living in the future" -- I thought SAML V1.0 was going to be deployed right away when we published it in 2002 :-) ) that technology adoption can move slowly indeed.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
The ForgeRock Identity Summit is coming to Paris in November!


On Wed, Nov 2, 2016 at 12:48 PM, Rainer Hoerbe <rainer@hoerbe.at> wrote:
IDPs are different things depending on communities and situations. A federated institutional IDP - in a wider sense) as a business function has to register users and provides authentication and attribute services, and pseudonymization services in more advanced cases. Whether that is a combo of SAML IDP + LDAP + Registration, or the data lives on a gated block chain and policies are defined in smart contracts does not change these functions. Saying good-by to SAML and welcoming BC/SC would not change the concept of federation.
If you mean that this class of federated IDPs can be replaced by an open user-centric system then there are business structures to change: institutions would not own their user accounts any more ("bring your own identity"), which would upset regulations, processes and liabilities.

Am I missing something in your concept?

- Rainer


Am 02.11.2016 um 18:13 schrieb Adrian Gropper <agropper@healthurl.com>:

Blockchain identity makes IDPs irrelevant because it's more secure in the sense of non-repudiation. The triple blind issues may or may not matter (as you say) but that doesn't change the reality that federated identity is not long for this world.

Adrian

On Wednesday, November 2, 2016, Eve Maler <eve.maler@forgerock.com> wrote:
In yesterday's call, I mentioned that there was a scholarly critique made last year on systems such as FCCX (afterwards renamed Connect.gov and since apparently scrapped -- or being rebuilt??) and Gov.UK Verify. These systems leverage a (centralized) broker to effect a "triple-blind" design in terms of IdP<->RP identification in the context of a specific user. Here's an article describing the problem and pointing to the technical paper. (If you have trouble getting through the paywall with this link, search for the title "Gov.UK Verify identity management system riddled with 'severe privacy and security problems', warn UCL academics" using Google News.)

The opinion I shared with a number of people at the time went like this:
  • I'm pretty suspicious of scholarly critiques of unlinkability claims, since most users end up voluntarily sharing sufficient attributes to be linkable anyway.
  • The article doesn't make very clear what the exact risk is nor what the proposed solution is, which doesn't surprise me because it's all very subtle.
  • The researchers have found a limitation in the tradeoff choice that the 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" (II) service that could handle the tricks.
  • Given that brokered systems, and the "older" protocols such as SAML already in use, and the encryption tricks the researchers suggest, and user interfaces that force users to choose services, are all considered expensive and unpleasant in various ways, and given that the notion of an II service is 100% novel, I give the researchers' suggestions a nil chance of succeeding in the current environment. And given users' incentives to share enough attributes in everyday circumstances to routinely become identifiable, it's questionable whether the researchers' preference for tradeoffs vs. the nations' preference is the correct one.
With hindsight, it's possible to observe that this specific critique didn't make that huge a splash at the time. However, we can also observe that these solutions have been struggling for a variety of other reasons (cost, complexity, politics, resulting pace...). I believe that in the Canadian province of BC, for example, they're not (or at least weren't as of a year ago) even using the triple-blind approach favored at the whole-of-Canada level and are going for a straight federated identity approach -- in other words, trading away both tradeoff choices discussed above in favor of even more back-end and front-end simplicity.

Maybe the II service would now morph into a user-chosen blockchain-based identity source, or something like that, in the current rendering. Or such technology might have other roles to play; the US Postal Service (which took over FCCX/Connect.gov last year) does mention validating and authenticating user identities in its blockchain report issued in May of this year. Then we're back to assessing the same propositions we've been looking at of late, I think.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
The ForgeRock Identity Summit is coming to Paris in November!



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc


_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc





--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

DONATE: http://patientprivacyrights.org/donate-2/