<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Shade,<div><div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</font></p></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Responsible, yes; trusted, maybe; vulnerable, definitely.</font></p></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</font></p></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">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!</font></p> </blockquote></div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><a href="http://www.internet2.edu/presentations/spring08/20080421-shibwg-chadwick.pdf">http://www.internet2.edu/presentations/spring08/20080421-shibwg-chadwick.pdf</a></div><div><br></div><div>Take care,</div><div>Nate.</div></body></html>