[OpenID Commits] r377 - provider_authentication_policy_extension/1.0/trunk

[drecordon at openid.net]

Author: drecordon
Date: 2007-10-22 18:41:23 -0700 (Mon, 22 Oct 2007)
New Revision: 377

Modified:
   provider_authentication_policy_extension/1.0/trunk/openid-provider-authentication-policy-extension-1_0.xml
Log:
More wording cleanups and clarifications, some from Barry Ferg <bferg at verisign.com>.

Modified: provider_authentication_policy_extension/1.0/trunk/openid-provider-authentication-policy-extension-1_0.xml
===================================================================
--- provider_authentication_policy_extension/1.0/trunk/openid-provider-authentication-policy-extension-1_0.xml	2007-10-22 23:56:08 UTC (rev 376)
+++ provider_authentication_policy_extension/1.0/trunk/openid-provider-authentication-policy-extension-1_0.xml	2007-10-23 01:41:23 UTC (rev 377)
@@ -77,7 +77,9 @@
         a single required trust model within OpenID allows Relying
         Parties to decide which Providers are trustworthy; likewise,
         RPs can decide whether to trust authentication policy claims
-        from such OpenID Providers as well.
+        from such OpenID Providers as well.  As with other OpenID
+        extensions, is is the Relying Party's responsibility to
+        implement policy relative to the OpenID Provider's response.
       </t>
     </abstract>
   </front>
@@ -229,7 +231,7 @@
         designed to be a starting point to cover the most common use-cases.
         Additional polices can be found at
         http://schemas.openid.net/pape/policies/.
-        
+
         <cref>
           There is ongoing discussion as to if a policy should be defined to
           represent technologies which help prevent phishing attacks though do
@@ -241,6 +243,21 @@
       </t>
       
       <t>
+        When multiple policies are listed in the Relying Party's request, it
+        is up to the OpenID Provider to satisfy as many of the policies as it
+        can.  This might mean that the OP needs to understand the relationship
+        between policies (such as if one encompasses another or if one is
+        stronger than another).  This also means that when the RP processes the
+        OP's response, it will have to make its own determinations as to if its
+        requirements were met.  For example it is recommended that if the OP
+        specified the Multi-Factor Physical Authentication policy and the RP
+        requested the Multi-Factor Authentication policy, that the RP's
+        requirements were met.
+      </t>
+
+      </t>
+      
+      <t>
       <list style="symbols">
         <t>Phishing-Resistant Authentication
           <cref>
@@ -285,8 +302,12 @@
                 factor where at least one of the factors is a physical
                 factor such as a hardware device or biometric. Common
                 authentication factors are something you know, something you
-                have, and something you are. An example would be
-                authentication using a password and a hardware token.
+                have, and something you are. This policy also implies the
+                Multi-Factor Authentication policy
+                (http://schemas.openid.net/pape/policies/2007/06/multi-factor)
+                and both policies MAY BE specified in conjunction without
+                conflict.  An example would be authentication using a password
+                and a hardware token.
               </t>
             </list>
         </t>