Dick, You say, " The strong authentication will be supplied by a vendor that has been certified to provide standardized levels of authentication. The IdP will often NOT be the strong auth vendor."
Can you explain how this might work, i.e., how can the RP have a relationship directly with the strong auth vendor and not the IdP? Would the IdP be outsourcing authentication to the strong auth vendor? In which case, isn't the strong auth vendor the IdP? =Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 05, 2006 9:36 AM To: Gabe Wachob Cc: specs@openid.net Subject: Strong Authencation (was [PROPOSAL] authentication age The vision I have is that strong authentication to your IdP will be common in the future. The strong authentication will be supplied by a vendor that has been certified to provide standardized levels of authentication. The IdP will often NOT be the strong auth vendor. The RP will have a trust relationship with the vendor, likely through a vendor consortium that delegates to vendors that their product is certified, ie. the RP will not need to trust each vendor, just the certification body. I would hope that OpenID can be extended over time to be able to move around these types of strong auth assertions. -- Dick On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: > Chris- > As someone who has recently come from working in the financial > sector (Visa), its clear that OpenID is NOT intended for > authentication > where the *relying party* cares about how the authentication is > performed. > > At places like Visa and for home banking, this means that OpenID, > without something more, is clearly a non-starter. These relying > parties want > to know exactly how their users are being authenticated because their > business is all about risk management and creating business > opportunities > around very good knowledge of the risk profile of each transaction > type. > > That all being said, I believe it should be possible to layer on > OpenID a form of IDP control such that a relying party can require > a certain > class or group of IDPs be used when presenting authentication > assertions to > them. The actual *policy* for how these IDPs are approved is probably > orthogonal to the protocol spec, but "secure" identification of > those IDPs > (relative to some trust root, etc) could probably be made into an > extension > usable for those parties who want it. > > My guess is that culturally, most people involved in OpenID have > *not* been interested in addressing these concerns. However, > expectations > need to be better managed around these sort of "relying-party cares" > scenarios, because its not obvious without actually reading the specs > themselves... > > -Gabe > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On Behalf >> Of Chris Drake >> Sent: Wednesday, October 04, 2006 8:26 PM >> To: Kevin Turner >> Cc: specs@openid.net >> Subject: Re[2]: [PROPOSAL] authentication age >> >> Hi Kevin, >> >> Sounds like you're leaning towards a root authority for IdPs who can >> audit procedures and verify protection in order to sign the IdP's >> keys? >> >> Joe blogger doesn't care much about identity assertions from an IdP, >> but it's a reasonable bet to expect that a Bank might care... >> >> Kind Regards, >> Chris Drake >> >> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
