Hi Gabe Agreed that things like strong auth would be extensions.
I still think auth_age is something that RPs expect to be able to influence (primarily being able to ask for the auth ceremony to be performed) and should be in the current spec. -- Dick On 5-Oct-06, at 9:47 AM, Gabe Wachob wrote: > 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