4. Defined Authentication Policies
The following are defined policies and policy identifiers describing how the End User may 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 http://schemas.openid.net/pape/policies/.
When multiple policies are listed in the Relying Party’s request, the OpenID Provider SHOULD satisfy as many of the requested policies as possible. This may require, for instance, that a user who has already been authenticated using one authentication method be re-authenticated with different or additional methods that satisfy the request made by the Relying Party. It is always the responsibility of the RP to determine whether the particular authentication performed by the OP satisfied its requirements; this determination may involve information contained in the PAPE response, specific knowledge that the RP has about the OP, and additional information that it may possess or obtain about the particular authentication performed.
- Phishing-Resistant Authentication （耐フィッシング認証）
An authentication mechanism where a party potentially under the control of the Relying Party can not gain sufficient information to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User’s actual OpenID Provider).
- Multi-Factor Authentication （多要素認証）
An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor. Common authentication factors are something you know, something you have, and something you are. An example would be authentication using a password and a software token or digital certificate.
- Physical Multi-Factor Authentication （物理的多要素認証）
An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication 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. 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.
Of the policies defined above, two are not independent. All authentications satisfying the Multi-Factor Physical policy also satisfy the Multi-Factor policy. Therefore, whenever the OP returns a result saying that Multi-Factor Physical authentication was performed it MUST also indicate that Multi-Factor authentication was performed.
4.1. Custom Assurance Level Name Spaces
Custom Assurance Levels are optional. The namespaces may be defined by various parties, such as country or industry specific standards bodies, or other groups or individuals.
The namespace URI should be chosen with care to be unambiguous when used as a <xrd:Type> element to advertise the namespaces supported by the OP.
The custom Assurance Level namespace should define the meaning of the strings that are returned by the OP in the openid.pape.auth_level.<cust> element.