[You may also read this blog post by Nandana on "OpenID, Phishing & PAPE, Are we there yet? "]
Let me first explain what PAPE is.
PAPE stands for OpenID Provider Authentication Policy Extension - which is an extension to the OpenID Authentication.
An extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.
With PAPE, an OpenID Relying Party can add additional information into the OpenID Authentication request - such as;
1. preferred_auth_policies
2. max_auth_age
Let me explain what each one of them means.
With preferred_auth_policies, an RP can attach zero or more authentication policy URIs that the OP SHOULD conform to when authenticating the user. If multiple policies are requested, the OP SHOULD satisfy as many as it can.
Let me make this much clearer.
If RP wants it's users to be authenticated in a phishing resistant manner, then RP will attach the policy URI, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant as the preferred_auth_policies.
If RP wants it's users to be authenticated in both a phishing resistant manner and a multi-factor way , then RP will attach the policy URIs, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://schemas.openid.net/pape/policies/2007/06/multi-factor as preferred_auth_policies.
One thing I want to emphasize here...
Given the fact that RP requested OP to do the user authentication in such a manner - does not mean OP will follow the exact authentication policy request.
In other words, an RP could request OP to authenticate it's users in a phishing resistant manner - but in case OP does not support phishing resistant authentication, then it will simply authenticate the user with the available method. But... OP will also let the RP know the method it used to authenticate the user. So - it becomes a decision up to the RP to decide whether to let user in or not.
Let's see how this works in a practical scenario.
We have hosted the WSO2 Identity Solution at https://is.test.wso2.org and the PAPE demonstration is available at https://is.test.wso2.org/javarp/.
Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your Yahoo OpenID there.
Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.
In this case an OpenID RP sends a PAPE request to an OP which does not support PAPE [Yes, Yahoo still does not support PAPE].
This is what you get as the response.
Authentication Policies: none
NIST Auth Level: 0
Auth Age: -1
For the time being lets only focus on "Authentication Policies" - here Yahoo OP returns no policies. That is Yahoo has ignored the PAPE request by the RP. So, now RP can decide whether to let user in or not.
Let's try another example. This time we use an OpenID from WSO2 OpenID Provider. You can go there, register yourself and get an OpenID.
WSO2 OpenID Provider supports login with both the username/password and Information Card based logins.
First directly login to the OP and then register a self-issued Information Card with the OP. We'll be using this Information card later-on to login.
Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your WSO2 OpenID [http://is.test.wso2.org/user/test] there.
Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.
In this case an OpenID RP sends a PAPE request to an OP which supports PAPE.
So, once you are redidirected to OP for authentication, login with your registered Information card.
You'll get the following as the PAPE reponse.
Authentication Policies: http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
NIST Auth Level: 1
Auth Age: -1
This indicates you've being authenticated in a phishing-resistant manner.
In no means, PAPE does not limit you to the following three authentication policies.
1. http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
2. http://schemas.openid.net/pape/policies/2007/06/multi-factor
3. http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
Additional policies can be specified elsewhere and used between OPs and RPs.
For example, myOpenID defines the policy URI, http://janrain.com/pape/callverifid.html for it's CallVerifID. In this post I blogged about how CallVerifID works.
Hope, by now it's very much clearer how PAPE works.
There are few things I skipped during the discussion.
Let's go back to them.
In PAPE request, RP also can add the parameter "max_auth_age" as well.
This is an optional parameter in the PAPE request, where the RP may or may not request.
Once max_auth_age is set in the PAPE request, if the End User has not actively authenticated to the OP within that number of seconds [max_auth_age] specified in a manner fitting the requested policies, the OP SHOULD authenticate the End User for this request.
Let's go back to the PAPE response. I skipped explaining two parameters, NIST Auth Level and Auth Age.
If the RP's request included the "max_auth_age" parameter then the OP MUST include "auth_time" [Auth Age] in its response. If "max_auth_age" was not requested, the OP MAY choose to include "auth_time" in its response or just send "-1" as the value.
The NIST Auth Level is the the Assurance Level as defined by the National Institute of Standards and Technology (NIST) corresponding to the authentication method and policies employed by the OP when authenticating the End User.
This value varies from 0 to 4 (inclusive).