Dick That's sounds like a reasonable approach (if I understand what you are saying), and frankly one I hadn't considered. More importantly, it sounds like we agree that we expect this to lie in the domain of OpenID extensions and that we don't need to consider these scenarios/requirements now for the 2.0 specs?
-Gabe > -----Original Message----- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 9:36 AM > To: Gabe Wachob > Cc: 'Chris Drake'; 'Kevin Turner'; email@example.com > 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: firstname.lastname@example.org > >> Subject: Re: [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 > >> email@example.com > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > specs mailing list > > firstname.lastname@example.org > > http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs