[OpenID] Building on the OpenID PAPE specification

[Brian Kelly]

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