modrna as an Individual Claim request parameter proposal in draft-mobile-authentication-01.txt

Issue #33 closed
Matthieu Verdier created an issue

In the last draft-mobile-authentication-01.txt the modrna OP behaviour is requested through the explicit use of modrna acr_values. Proposed here is to de-correlate the two acr_value and modrna behaviour request by using a modrna individual claim request.

Also proposed is a structure of a modrna context reference value and modrna context value. This could provide a mean to define the modrna OP behaviour regarding the RP trust (or reliability) through its registration and authentication and the mobile context reference claim value he requests, (as discussed in section 8 of the draft).

The proposal would modify section 3 and 7 as follows :

Proposed section 3 : 3. Authentication Request

acr_values OPTIONAL .

Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this Authentication Request, with the values appearing in order of preference. The Authentication Context Class and satisfied and Authentication Method Reference by the authentication performed is returned as the acr Claim Value and the amr Claim Value.

login_hint_token OPTIONAL. A parameter to be passed in the authentication request. The login_hint_token is used to transport a user identifier from the discovery service to the OpenID Provider without revealing this identifier to the client.

id_token_hint OPTIONAL. A parameter to be passed in the authentication request. The id_token_hint is used to transport an id_token. It MUST be encrypted using the public key of the OpenID Provider.

modrna OPTIONAL. JSON Individual Claim Object. Default value is null. For MODRNA the parameter is REQUIRED to enable the Relying
Party to indicate a MODRNA conform authentication request. Used to provide additional information values about the modrna Claim being requested.
Mobile Context Reference value and Mobile Context values that the Authorization Server
is being requested to use for processing this Authentication Request. How the modrna Claim request is satisfied or how to ensure that the relevant message is actually shown on all relevant devices is out of the scope of this document. Result is returned as the modrna Claim JSON Value. The modrna Claim is requested as an Individual Claim by this parameter.

Proposed section 7 : 7. Values of the modrna Individual Claim request

Adds specific claims to the request object such as a specific consent or a transaction message or a one-time code value message. The request object MUST then be signed to prevent manipulating the transaction message.

modrna is a Individual Claim Request, a JSON object of urn:modrna values followed by optional values, that specifies the modrna context reference (mcr) and mobile context value (mcv) that the Authorization Server is being requested to use for processing this Authentication Request.

The generic format of modrna_values is :

"modrna":{"values":["urn:modrna:mcr:value_example”,“modrna name”,
                               ["urn:modrna:mcv:value_example”,“value_example”]}

By default, modrna defines one mobile context reference value ‘local’ and a mobile context value 'message' for the modrna OP own services :

'local' modrna context reference : urn:modrna:mcr:local", “local_OP_context _name”

'message' modrna context value : ,urn:modrna:mcv:message, “local_OP_context_message”

For example :

"modrna":{"values":[ "urn:modrna:mcr:local”,“Local OP carrier billing.”, "urn:modrna:mcv:message”,“Validate example.com purchase of 15,50 euros” ]}

Which would appear on the mobile authenticator display, if the authentication method used is PIN based as :

"Local OP carrier billing. Validate example.com purchase of 15,50 euros. Enter Personal Code ?"

Comments (4)

  1. Jörg Connotte

    I think this is somewhat similar to the discussion of the 'context' parameter. the inner structure of 'moderna' makes sense if a specific context is required i.e. a specific authorization is needed. As moderna authentication is about verifying an identity and no so much about authorizing a specific transaction I would vote to put this mechanism in a different document. Most probably a new scope 'moderna' to indicate to the OP that a different payload is expexted. Merge with #22?

  2. Log in to comment