Hi Gabe

Agreed that things like strong auth would be extensions.

I still think auth_age is something that RPs expect to be able to  
influence (primarily being able to ask for the auth ceremony to be  
performed) and should be in the current spec.

-- Dick

On 5-Oct-06, at 9:47 AM, Gabe Wachob wrote:

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

Reply via email to