Chris, Great examples. Signed credentials makes lots of sense. OpenID AuthN 2.0 doesn't handle them yet but I can completely understand them in the roadmap.
=Drummond -----Original Message----- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 10:51 AM To: Drummond Reed Cc: email@example.com Subject: Re: Strong Authencation (was [PROPOSAL] authentication age Hi Drummond, Example1: RSA would provide a signed response indicating that the user correctly entered the SecurID token code. Example2: The RP would have the public key of the company that supplies the fingerprint scanning hardware (although some extra thought as to how a fingerprint ultimately matches to an Identity is required, which will need an entirely different information flow to Example1). Is Dick a vendor himself? he no doubt knows other ways. Kind Regards, Chris Drake, =1id.com Friday, October 6, 2006, 3:19:44 AM, you wrote: DR> Dick, DR> You say, " The strong authentication will be supplied by a vendor that has DR> been certified to provide standardized levels of authentication. The IdP DR> will often NOT be the strong auth vendor." DR> Can you explain how this might work, i.e., how can the RP have a DR> relationship directly with the strong auth vendor and not the IdP? Would the DR> IdP be outsourcing authentication to the strong auth vendor? In which case, DR> isn't the strong auth vendor the IdP? DR> =Drummond DR> -----Original Message----- DR> From: [EMAIL PROTECTED] DR> [mailto:[EMAIL PROTECTED] On Behalf DR> Of Dick Hardt DR> Sent: Thursday, October 05, 2006 9:36 AM DR> To: Gabe Wachob DR> Cc: firstname.lastname@example.org DR> Subject: Strong Authencation (was [PROPOSAL] authentication age DR> The vision I have is that strong authentication to your IdP will be DR> common in the future. DR> The strong authentication will be supplied by a vendor that has been DR> certified to provide standardized levels of authentication. The IdP DR> will often NOT be the strong auth vendor. DR> The RP will have a trust relationship with the vendor, likely through DR> a vendor consortium that delegates to vendors that their product is DR> certified, ie. the RP will not need to trust each vendor, just the DR> certification body. DR> I would hope that OpenID can be extended over time to be able to move DR> around these types of strong auth assertions. DR> -- Dick DR> 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: email@example.com >>> 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 >>> firstname.lastname@example.org >>> http://openid.net/mailman/listinfo/specs >> >> _______________________________________________ >> specs mailing list >> email@example.com >> http://openid.net/mailman/listinfo/specs >> >> DR> _______________________________________________ DR> specs mailing list DR> firstname.lastname@example.org DR> http://openid.net/mailman/listinfo/specs DR> _______________________________________________ DR> specs mailing list DR> email@example.com DR> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs