Strong Authencation (was [PROPOSAL] authentication age

[Drummond Reed]

Dick,

You say, " 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."

Can you explain how this might work, i.e., how can the RP have a
relationship directly with the strong auth vendor and not the IdP? Would the
IdP be outsourcing authentication to the strong auth vendor? In which case,
isn't the strong auth vendor the IdP?

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
Sent: Thursday, October 05, 2006 9:36 AM
To: Gabe Wachob
Cc: specs at 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: specs-bounces at openid.net [mailto:specs-bounces at openid.net]  
>> On Behalf
>> Of Chris Drake
>> Sent: Wednesday, October 04, 2006 8:26 PM
>> To: Kevin Turner
>> Cc: specs at 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 at openid.net
>> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs