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


> -----Original Message-----
> Of Chris Drake
> Sent: Wednesday, October 04, 2006 8:26 PM
> To: Kevin Turner
> Cc:
> 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 mailing list

Reply via email to