!!! Overview
[{$pagename}] is an __OPTIONAL__ parameter that is a Space-separated string that specifies the [Authentication Context Class Values] within the [Authentication Request] that the [Authorization Server] is being requested to use for processing requests from this [Client|OAuth Client], with the values appearing in __order of preference__. 

[{$pagename}] was originally specified within the [JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants] ([RFC 7523])

The [Authentication Context Class Reference] values actually utilized by the [Authorization Server] is returned within the [Identity Token] in the [acr] parameter.

!! [OpenID Connect MODRNA Authentication Profile 1.0]
[OpenID Connect MODRNA Authentication Profile 1.0] made the [{$pagename}] [REQUIRED]. For [OpenID Connect MODRNA Authentication Profile 1.0] this parameter is [REQUIRED] in order to enable the [Relying Party] to indicate a [MODRNA] conform [Authentication Request] to the [OpenID Connect Provider]. Allowed values are defined [{$pagename}] Section 4.

!! acr_values request values and [level Of Assurance]
The service's terms of service will specify a [Trust Framework] for [Identity Provider (IDP)s] to follow for general business processes and other related account security issues.

This specification defines an initial set of [{$pagename}] that clients can use to request the [Identity Provider (IDP)] mitigate specific authentication risks.

The initial set of [{$pagename}] contain no requirements for the [Identity Provider (IDP)s] to make any guarantee of [Identity Proofing] the subject of the authentication beyond what is required by business practices for account recovery and customer service as defined in the [Trust Framework]. Prepaid [anonymous] users may be included in responses conforming to these values.

The [An IANA Registry for Level of Assurance (LoA) Profiles] ([RFC 6711]) will be used to register the short names for these [LOAs], and any future additional [LOAs].

! http://schemas.openid.net/policies/modrna/phishing-resistant

Short-Name: [mod-pr] This mitigates phishing of credentials. 

The user is authenticated via possession of a [Mobile Device] (phone) containing a [secret-key]. The user is required to provide no additional authentication information to use the key. The user is interactively prompted to confirm the [authentication]. The storage mechanism for the secret key and other relevant authentication information is returned via the [amr]. The user is not re-prompted for credentials if the value of prompt is not login and max_age is more than the elapsed time since the user last authenticated at the requested [acr].

! http://schemas.openid.net/policies/modrna/multi-factor
Short-Name: [mod-mf]
 
This mitigates [phishing] and proves the device is recently in the possession of the [authorized] user via pin or device unlock. 
The user is [authenticated] via possession of a [Mobile Device] (phone) containing a [secret-key]. The user is required to provide additional [authentication] information via a biometric, pin code or other appropriate factors such as bluetooth paring with a watch. Given suitable [Mobile Device] management unlocking the device is also sufficient along with user confirmation of desire to authenticate. The storage mechanism for the [secret-key] and other relevant [authentication] information is returned via the [amr] value. The user is __NOT__ re-prompted for credentials if the value of prompt is not login and max_age is more than the elapsed time since the user last authenticated at the requested [acr].

[Identity Provider (IDP)] [MUST] recognize and process __short registered forms __of the authentication context strings. They may recognize and process long forms for custom authentication contexts.

Clients [MUST] send the short registered forms of the authentication context strings, if the authentication context is registered.

The [OpenID Connect Provider] [MUST] support receiving [{$pagename}] as a space separated list in order of preference per [OpenID.Core] section 3.1.2.1.

The [OpenID Connect Provider] [MUST] support receiving [acr] as a claim request in a signed request per [OpenID.Core] 5.5.1. This method prevents the request from being modified by the user, and allows the requested [acr] valued to be considered essential claims causing the [Identity Provider (IDP)] to respond with an authentication error if no requested [acr] value can be fulfilled.

Depending on the [authentication] capabilities of the users device, the [OpenID Connect Provider] [MUST] attempt to match the highest requested [acr] value that the AD is capable of. If the [acr] claim is not marked as [Essential Claim] in the request object, the [OpenID Connect Provider] may return another [acr] value that the device is capable of rather than an error if it cannot match any of the requested [acr_values].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]