...
We already have the LPPE feature which addresses this issue (only for LDAP though) : an exception is thrown by authentication handler for password renewal and a screen for to renew password renew is displayed. I think we should try to stick to this existing feature.
...
- many interactions (at least one).
An interaction manager is in charge of finding the right interactions to try for a given list of authentication handlers. The interactions are returned as a list to specify in which order interactions are to be tried.
F) Authentication manager (update)
So far, an authentication manager takes credentials as input.
To support LOA, it will now take a numeric level of assurance as input also.
I prefer to think of the "name" of the assurance level as it's primary key, and to think of the numeric value as an attribute. Therefore, I think the authentication manager should receive the name instead of the number. -Nathan
Jérôme :
I prefer using numeric value because this way, you can have an authentication handler with a LOA value (for example : 49) which is not equals to an already existing LOA.
G) Registered service (update)
So far, a registered service supports attributes : id, name, theme, description, isAnonymous...
To support LOA, it will now define what authentication handlers it supports. None selected means all.
I think it would be better for the registered service to define a list of assurance levels (from the server's policy) that it accepts. -Nathan
H) Assurance evaluator (new)
The assurance evaluator is in charge of evaluating the LOA of the authentication given as input. It returns a numeric value.
Generally, it returns the numeric value of the LOA associated with the authentication handler used to authenticate previously the user and stored in the authentication.
In case of remember-me, the LOA returned is not the one of the authentication handler but is computed.
...
- renew=value, the numeric value is strictly positive, it's meant to be a requested numeric LOA
- renew=name, name is the name of an authentication handler or the name of a level of assurance. (I recommend allowing the client to specify either a minimum number or a list of names of the level of assurance and not an individual authentication handler. If that level of flexibility is desired, then the client should be able to specify a complete authentication constraint expression and not just an authentication handler name. Noe that with a list of names, only exact matches count. Even if the user has fulfilled a higher number but not fulfilled the requested type of authentication specified by the named level, then it doesn't count. -Nathan)
Jérôme :
I think I'd prefer if we created a new parameter named "loa" or something like that'm not sure if we should keep the availability to request LOA by authentication handler name of by constraint expression. Does it match real use case ? Does it make sense ? I think we should always request a LOA by name or numeric value, meaning a specific level and ALSO the "superior" levels.
I think I'd prefer if we created a new parameter named "loa" or something like that, instead of reusing "renew". We would still want to preserve the behavior of "renew=true", but I think that we don't gain much by piggy-backing on the existing parameter. I don't think it really "costs" us much to add a new "loa" parameter and it makes the protocol more understandablemakes the protocol more understandable.
Jérôme :
I agree. We can use a parameter named "loa" instead of "renew" to avoid confusion.
Note that behavior is slightly different whether the client requests LOA by name or by number. Here's an example. Refer back to the table above under the "Example Assurance Policy" section. Let's say that a user has satisfied the requirements for level 47 (renewed LDAP authentication with strong password). In this case, the user's numeric LOA value would be 47, and they would have satisfied the following named levels: strong_ldap_renew, strong_ldap, any_ldap_renew, and any_ldap. If a service requests "loa=30" (meaning any numeric value >=30), then the user would be allowed to access the service. But if a service requests "loa=public_idp" (level requested by name), then the user would be prevented from accessing the service, even though their numeric value is higher.
Jérôme :
Using a name or a numeric value of LOA must lead to the same result. The only diffrence between name and numeric value is that a name should match a defined name whereas a numeric value doesn't need to match a numeric LOA because it only relies on numeric comparison (and not on exact matching).
V. Main algorithmalgorithm
A) Diagram
B) Requested LOA
...