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