Re: Federation protocols

Melvin Carvalho wrote:
>
>
>
> On 1 June 2013 23:16, Miles Fidelman <mfidelman@meetinghouse.net 
> <mailto:mfidelman@meetinghouse.net>> wrote:
>
>     Melvin Carvalho wrote:
>
>
>         I'm totally for using X.509 certificates for this and have
>         been arguing several years for their adoption.  The bigcos are
>         blocking it so far due to UX.  We were unable to get
>         status.net <http://status.net> <http://status.net> to support
>         it even though we had people ready to work on the code.  By
>         all means do try and get X.509 deployed, I'll write code for
>         it, and support your messaging, but expect pushback due to the
>         X.509 user experience.
>
>
>     X.509 is in extremely widespread use (can you say U.S. Federal
>     Government), it's built into browsers and mail clients, there are
>     modules to support it for Apache and other major web browsers, and
>     there's infrastructure for generating and managing certificates.
>
>     The problem is not with the technology, or its implementation.
>      The problem is that key players don't want to adopt ANY open
>     identity/authentication mechanism.  Creating yet another
>     technology or protocol won't change that.
>
>
> The key players tend to push the trusted third party paradigm and that 
> is understandable as it is a business model.  But it's not the only 
> way, so long as there is choice, then the end user has a chance to 
> choose their paradigm.
>

Umm... X.509 IS  trusted third party model - it requires a chain of 
trust back to a certificate granting authority.

As to end users choosing their paradigms, how can you possibly have an 
electronic identity/authentication model where everybody 
self-authenticates?  You (or a system) has absolutely no way of knowing 
if I'm really Miles Fidelman (or which Miles Fidelman I am), without 
some kind of chain-of-trust that involves either:
i. a trusted third party who vouches for my electronic credentials, or,
ii. a face-to-face exchange of crypto keys - and you still need some way 
to verify that I'm who I claim to be in person, like photo id issued by, 
you guessed it, a trusted 3rd party).

For any kind of identity/authentication system to be useful - 
particularly in a federated environment - it has to be broadly adopted 
and standardized, not a matter of individual choice by each end user.

And.. there has to be some kind of trusted third party / infrastructure 
involved, otherwise there's no basis for trusting the credentials that 
anyone presents.

The questions come down to things like:
- top-down vs. distributed identity provision (e.g. x.509 certificates 
that tier up to an ultimate authority vs. organization-based identity 
providers like OpenID or Shibboleth)
- schemes that require real-time authentication against a server (e.g., 
OpenID) vs. schemes that don't require real-time authentication (e.g, 
crypto credentials)
- where do access control decisions get made - at individual systems or 
by access control servers (e.g., Kerberos)

The issues are not technical ones - they're sociological, economic, and 
organizational.  We have multiple, well-established, well proven models 
for distributed identity/authentication/access control - both 
proprietary and open standards.

- US government agencies, and the DoD in particular, use X.509 
certificate based identity/authentication on a global basis, across 
1000s of organizational units and millions of users (including 
contractors and other non-government organizations).  There are probably 
millions of people carrying CAC cards,  plugging them into computers 
with CAC card readers on a daily basis, and using those credentials to 
access various government web sites.

- I'd guess the number of people who use MS Outlook, Exchange, and 
Sharepoint - backed by Active Directory services, is closer to a billion.

- In the university community, we have widespread use of Shibboleth and 
Kerberos.

- There's quite a lot of OpenID floating around (which, I believe, is 
the underlying mechanism for "login with your 
[FaceBook|Google|Twitter|... account]")

- Drupal sites support federated identity.

One of my favorite examples of all the pieces, all integrated nicely 
together, is MIT's Shibboleth-based Touchstone authentication system. It 
supports identity/authentication by:
- MIT Kerberos username/password
- MIT issued X.509 certificate
- federated authentication across members of the "InCommon Federation" - 
consisting of about 500 different organizations (universities, 
government agencies, corporate sponsors, etc.)
And provides single-sign-on access to both MIT-based resources and 
resources across federated institutions.
Details at http://ist.mit.edu/touchstone

And lest we forget:
- Google and Facebook both provide global, 3rd party 
identity/authentication services, as, in a sense, do:
- MasterCard, Visa, American Express, PayPal, etc. (what is a credit 
card number if not an identity, what is payment if not authentication?)

There's no lack of technology (models, protocols, software), or 
infrastructure (key generation, identity/authentication servers, access 
control servers, organizational/institutional support), and no lack of 
adoption.

If the issue is: Why is everyone using Facebook as the identity provider 
for social networking, the answers are:
1. They're not - Google and Twitter iare giving them a run for the money
2. They're an 800 pound gorilla that's cut deals with lots of different 
places (you can still set up an individual account on HuffPost, Disqus, 
and 100s of other sites; but it's sure a lot easier to simply click "log 
in with facebook" - and in some cases, like Zynga games, it's become 
impossible to recover a forgotten password, so facebook becomes the only 
way to log in)

Again - there simply isn't a technology question here, it's a a 
cultural/economic/organizational/.... question - what are the factors 
that lead to adoption of one scheme and infrastructure over another?

Why, by the way, does not mean there aren't serious issues, such as:

1. the standard ones of lost/stolen/forgotten credentials and mechanisms 
for dealing with these situations

2. permanent credentials, and more specifically what happens when 
someone stops paying - be it not paying an annual renewal fee, 
graduating from the institution that provides your identity service, 
leaving a job, etc.

3. what happens when you die (to accounts, to data locked up behind your 
key, etc.)

Which, I might add, are again organizational and legal issues, not 
technical ones.  (There are plenty of models for permanent email 
addresses, maintained by universities and professional organizations; 
key escrow; you can always put stuff in your will - but there's no 
widespread consensus on standard practices.)



Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

Received on Sunday, 2 June 2013 03:34:23 UTC