[OpenID] Building on the OpenID PAPE specification

[Peter Williams]

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