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.


-----Original Message-----
From: Chris Drake [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 05, 2006 10:51 AM
To: Drummond Reed
Subject: Re[2]: 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

Is Dick a vendor himself? he no doubt knows other ways.

Kind Regards,
Chris Drake,

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
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
DR> IdP be outsourcing authentication to the strong auth vendor? In which
DR> isn't the strong auth vendor the IdP?

DR> =Drummond 

DR> -----Original Message-----
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:
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-----
>>> 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

DR> _______________________________________________
DR> specs mailing list

DR> _______________________________________________
DR> specs mailing list

specs mailing list

Reply via email to