Overview#

Acr_values 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, with the values appearing in order of preference.

Acr_values 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 Acr_values 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 Acr_values 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 Acr_values that clients can use to request the Identity Provider (IDP) mitigate specific authentication risks.

The initial set of Acr_values 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 Acr_values 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:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-16) was last changed on 27-Jun-2017 08:10 by jim