[OpenID] E-mail verification is MultiAuth

[Nate Klingenstein]

Shade,

> Sure it is - but, at the same time, we can't place all the power to  
> impersonate users into the hands of any one third party.

That's an extremely strong requirement, beyond the ability of most  
current deployments and even the requirements of NIST 800-63 Level  
4.  I don't think calling for it in general practice is reasonable  
today.

> Responsible, yes; trusted, maybe; vulnerable, definitely.

It's the responsibility of any issuer of credentials of any value to  
do a reasonable job securing both its systems and its procedures.   
While any system may be considered vulnerable, I worry far more here  
about applications relying purely on cookies and compromised  
clients.  They're definitely the weaker link.

> If (for example) Facebook asserts that it can be trusted as OP to  
> verify a user's E-mail address (at another domain), we haven't  
> solved any security problems; we've only shifted their burden onto  
> another host. It's then *worse*, actually, because we double the  
> exposure of those credentials (attackers can compromise the E-mail  
> provider *or* they can compromise Facebook, either one will work),  
> and also because Facebook becomes the centralized repository of  
> that authentication measure, actually *removing* veto power from  
> 3rd-party hosts that might want to protest "Wait, this user isn't  
> who they say they are!". Aggregation is one of the *implications*  
> of a user-centric (digital) world: we deal with more spokes in a  
> peer-to-peer environment than in a server-terminals environment.

I agree that aggregation will become increasingly important as users  
are allowed to make their identities portable.  It's one of the key  
challenges federated identity must address for applicability to most  
use cases and deployments.  I'd also agree that involving more OP's  
where their singular compromise also represents compromise of a set  
of identities weakens the security of a system.

> Re: misbehavior, I still think the "majority of OP's" requirement  
> would restrict the danger posed by lone misbehaving OP's - indeed,  
> the possibility of one or more of them "going rogue" was explicitly  
> acknowledged and specifically addressed in that proposal!

It's difficult to build aggregation flows where any OP/IdP acting  
maliciously can't independently do a few bad things, including  
authenticating the user autonomously.  Requiring the client to  
successfully authenticate at two providers constrains the aggregation  
solution set while introducing additional user confusion(didn't I  
already login?) and protocol complexity.  That's not to say there is  
no value in it, but there's a lot of work to do until it can be  
considered practical.

Here's a recent demonstration with loose consensus and running code  
for attribute aggregation.  It doesn't require multiple  
authentications, but it does constrain attribute quality by  
authentication quality and ensures any given OP/IdP is not aware of  
identities at other OP's or IdP's.  I consider it our best  
approximation at addressing your concerns unless clients are made  
more intelligent.

http://www.internet2.edu/presentations/spring08/20080421-shibwg- 
chadwick.pdf

Take care,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090501/af223fc7/attachment.htm>