[OpenID] Building on the OpenID PAPE specification

[Peter Williams]

Id expect the rp to sgnal that it want the op to only use eaptls, say, and for the op to signal back the ca its authenticator accepted for the client cert (or a saml hok assertion). I would not expect as a rp to signal or to know whether the supplicant was native microsoft, native apple, installed  cisco or the open source xsupplicant.

If the ca is not one using verisign ev certs, I the rp may alter my posture for that user. Id expect to notify my fraud engine of that fact, and let it adjust the sessions (sp centric) risk score suitably - which may affect transaction limits etc.


Nist levels are far to vague for the kinds of fraud engines online commerce sites use. They may be fine for web2.0 sites with advertising based revenue models, tho.

-----Original Message-----
From: Dick Hardt <dick.hardt at gmail.com>
Sent: Wednesday, October 08, 2008 11:26 AM
To: Taylor Venable <taylor at metasyntax.net>
Cc: general at openid.net <general at openid.net>
Subject: Re: [OpenID] Building on the OpenID PAPE specification


Please reread what I wrote. If the goal is to require OPs to implement
a specific vendors technology, that is not very open, and creates a
closed system.

I don't disagree with what you say below. See my other post on how
namespaces can be used to create custom policies and attributes.

-- Dick

On 8-Oct-08, at 11:22 AM, Taylor Venable wrote:

> On Wed, Oct 08, 2008 at 09:47:07AM -0700, Dick Hardt wrote:
>> If your goal is to narrow the number of OPs that can meet an RP's
>> requirements to being OP's that implement a specific technology
>> (yours? :-) -- you are going counter (IMHO) to the objectives of
>> OpenID.
>
> I don't think so; or if this general statement really is the case then
> there are other parts of OpenID which must bear this sort of criticism
> as well.  SREG has required fields which must be supplied to complete
> registration -- if the OP does not provide these then the RP will not
> perform the registration.  PAPE states that for an OP which does not
> fulfill the RP requirements, "the OpenID login process cannot proceed
> due to not meeting policy requirements."  Even moreso than SREG, this
> allows RPs to limit available OPs to those which support
> authentication via a specific subset of available technologies.
> PAPE-AM simply adds more detail and finer controls.  If PAPE-AM is
> contrary to the spirit of OpenID, then so are other OpenID extensions
> which have already been, or are about to be, approved standards.  With
> all due respect to Mr Hardt, this conclusion is slightly absurd.
>
> Furthermore, since a major goal of OpenID is to be a "way to use a
> single digital identity across the Internet," obviously it would be
> nice to have as many RPs get on board as possible.  Some of these RPs,
> such as Microsoft's HealthVault service, want to narrow the list of
> providers to those that they can trust will do a sufficiently good job
> of authenticating users.  (Actually, to say "narrow" has a negative
> connotation; Microsoft is not trying to force certain providers out of
> the picture, but they are trying to ensure that ne'er-do-wells cannot
> log into their service as other legitimate users.)  I would venture to
> say that a number of relying parties, among them government sites and
> financial institutions, would be interested in OpenID if they could be
> more certain of specific high-quality origins of authentication.
>
> --
> Taylor Venable            http://real.metasyntax.net:2357/
>
> foldr = lambda f, i, l: (len(l) == 1 and [f(l[0], i)] or
>                         [f(l[0], foldr(f, i, l[1:]))])[0]

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