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-----
>> On Behalf
>> 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

specs mailing list

Reply via email to