[OpenID] Building on the OpenID PAPE specification

Thu Oct 9 18:39:00 UTC 2008

A general observation that avoiding the suggestion of specific URIs in a
spec where such URIs are essential for interoperability in a recipe for
non-interoperability.

I agree with Brian that if only three URIs are provided in the spec, the
RP/OP community will almost certainly gravitate toward these three URIs. But
removing those URIs in order to encourage adoption of a larger set of URIs
is backwards. If you want to encourage the adoption of a larger set of URIs,
include the URIs in the spec - even if you do it in appendicies or by
reference.

I have not been active on the PAPE WG and this is probably a subject for
that mailing list, but to the extent that there is tension between PAPE and
PAPE-AM, perhaps the PAPE WG would consider adding the PAPE-AM URIs as an
appendix?

=Drummond 

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Brian Kelly
> Sent: Thursday, October 09, 2008 7:47 AM
> To: Peter Williams
> Cc: OpenID List
> Subject: Re: [OpenID] Building on the OpenID PAPE specification
> 
> Peter, Thank you for the detailed analysis & example using the latest
> draft #5 of the PAPE spec.
> 
> As you mentioned, the power to provide and use detailed information
> about the authentication policies and methods used is there, but it is
> all very optional, and a bit obscure.
> 
> If the power to extend the policies requested using namespace is
> there, why even offer _any_ default policies in the PAPE spec?
> 
> 	http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
> 	http://schemas.openid.net/pape/policies/2007/06/multi-factor
> 	http://schemas.openid.net/pape/policies/2007/06/multi-factor-
> physical
> 
> To me, this gives bias towards using these policies, rather then
> having them extended. OPs/RPs not intimately involved with the group
> that created these specs will take these three at-a-glance and not
> bother with extensions.
> 
> How about not suggesting any default policies, keep it extensible, and
> let the best policies (NIST, JISA, etc.) find their way to the top?
> 
> Brian
> 
> On Oct 9, 2008, at 8:46 AM, Peter Williams wrote:
> 
> >
> >
> > Ok. Given all that , I cannot bring myself to comment in a detailed
> > and careful manner on the rest. It was doing fine in general, until
> > the last issue.
> >
> > Peter.
> >
> >
> > -----------
> >
> >
> > Ok I relented. It's just too  interesting. Rather than read it like
> > a standard, I focused on understanding by example testing.
> >
> > The text does needs organizing (so levels are properly introduced,
> > and the concept of a policy namespace is given an example early on
> > (perhaps alongside the example of a level namespace)), but I could
> > mostly make sense of it if I read the end parts, first-and then
> > ignore all the suggestions concerning policy, mechanisms, stuff
> > about phishing UIs, and the stuff about mapping US and Japanese
> > 'standard' levels as equivalents. (Its not really clear why XRDS
> > metadata cannot advertise levels, tho....having been restricted to
> > policies.)
> >
> > I crafted the following example, to ensure it would hold under the
> > model, playing the role of evil vendor subverting the wider openid
> > movement:-
> >
> > a. RP declares policy namespace URI and level namespace URI, and the
> > resources define the policies and levels in normal "controls"
> > language. To be safe about authorities, the URIs are URLs and the
> > URLs bear the RP's .com domain-name, for which it has an SSL cert
> > from VeriSign. The one and only one policy refers to a single Auth
> > Mechanism, EAPTLS - a vendor-neutral auth method available in a
> > billion PCs.
> >
> > b. To aid mandatory RP discovery - as defined in RP's auth policy -
> > RP publishes an XRDS on an SSL endpoint (backed by the cert
> > mentioned in (a)) containing within one or more service elements
> > types that advertise the RP's auth policy requirement and the level
> > requirement, defined also in (a)
> >
> > c. During an OpenIDAuth run, RP applies the openid.pape.max_auth_age
> > to force the OP to apply SHOULD handling rules concerning the 1 and
> > only 1 authentication policy listed in
> > openid.pape.preferred_auth_policies.
> > openid.pape.auth_level.ns.<cust>  is provided (as the URI defined in
> > (a)), but openid.pape.preferred_auth_level_types is omitted (for
> > now, see below).
> >
> > d. In the case that the evil vendor supporting the RP has defined
> > EAPTLS as its auth policy/mechanism, the OP may send back in the
> > openid.pape.preferred_auth_policies a string which is, say, not an
> > integer but the ldapURI encoded name of the CA used confirm the
> > client cert in EAPTLS authentication. If EAPTLS is using SAML HOK
> > assertions rather than X.509 client certs, the ldapURI might
> > identity the SAML authority, instead. As ldapURI of authority names
> > would normally be considered a weak form of authority resolution in
> > open systems, SHA-2 fingerprints of the authority's cert might
> > accompany the ldapURI, for either X.509 certs or HOK assertions.
> >
> > e. the RP ultimately interprets the OP's auth level exactly as https
> > browser interpret VeriSign Class X roots and EV roots, today. Green
> > flashing address bars in browser (and the like) may result. The
> > VeriSign CPS would then assume control over the transaction, to
> > impose a self-consistent legal model that binds the openid legal
> > semantics to those of the underlying https bearer, and get the
> > parties access to legal warranties and assurances of that bearer's
> > control certs.
> >
> > f. in the case the RP wants the OP to only consider a particular CA,
> > the auth request's pape extension's
> > openid.pape.preferred_auth_level_types might indicate a namespace
> > concoted beneath the level namespace declared in (a) to imply a
> > class of cert.
> >
> > g. Fancifully, in the case the RP wants the OP to only use a
> > particular SSL ciphersuite when engaged in EAPTLS, the auth
> > request's pape extension's openid.pape.preferred_auth_level_types
> > might indicate a namespace concoted beneath the level namespace
> > declared in (a) to imply a SSL ciphersuite. The evil vendor is
> > entirely entitled to signal its own ciphersuite, using TLS 1.2
> > private ciphersuite naming.
> >
> >
> > I think, Brian, in the auth pape spec and when type evaluation Iused
> > above is applied to its meaning, one DOES actually have the
> > equivalent of what SAML2 has - but only when properly apply all of
> > (i) the XRDS metadata controls, (ii) the request/response signals,
> > and (iii) a careful binding to https (used under a decent CA's CPS).
> >
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general