...
I'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.
Nathan:
In the use cases that I need to support, our policies might not end up being defined my a straight numeric scale where the concepts of "better" and "worse" are agreed-upon across the entire organization. This means that in some cases, an app (or a set of apps run by a particular department) might reject an authentication method (considering it weaker) that the rest of the organization has deemed acceptable and considers stronger. Certainly it would be GREAT if we could just force agreement, but that just isn't the case where I work. I need to be able to support exceptions to the rule.
In the use cases that I need to support, our policies might not end up being defined my a straight numeric scale where the concepts of "better" and "worse" are agreed-upon across the entire organization. This means that in some cases, an app (or a set of apps run by a particular department) might reject an authentication method (considering it weaker) that the rest of the organization has deemed acceptable and considers stronger. Certainly it would be GREAT if we could just force agreement, but that just isn't the case where I work. I need to be able to support exceptions to the rule.
----
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 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 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 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)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).
Nathan:
In the use cases that I need to support, our central IT policies and concepts of "better" and "worse" most likely won't be agreed-upon by the entire organization. This means that in some cases, an app (or a set of apps run by a particular department) might reject an authentication method (considering it weaker) that the rest of the organization has deemed acceptable and considers stronger. Certainly it would be GREAT if we could just force agreement, but that just isn't the case where I work. Our central IT department doesn't have that authority. It would be very helpful to be able to support exceptions to the rule.
In the use cases that I need to support, our central IT policies and concepts of "better" and "worse" most likely won't be agreed-upon by the entire organization. This means that in some cases, an app (or a set of apps run by a particular department) might reject an authentication method (considering it weaker) that the rest of the organization has deemed acceptable and considers stronger. Certainly it would be GREAT if we could just force agreement, but that just isn't the case where I work. Our central IT department doesn't have that authority. It would be very helpful to be able to support exceptions to the rule.
Another way to think of it is this: This concept extends beyond pure "levels" of authentication (where one is always better than another) to "types" of authentication (where each type has pros and cons that make it better or worse under varying circumstances). One example would be related to PCI compliance. As an organization, we might say that the two-factor combination of a simple password plus Google Authenticator is stronger than a complex password. But PCI rules might say that all users need a strong password regardless of whether or not they have Google authenticator. Thus, the systems that need to be PCI compliant would need to be configured to handle an exception to the rule and reject something that the rest of the organization thinks is strong.
V. Main algorithm
A) Diagram
...