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'; 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

Reply via email to