RequestedAuthnContext with a Comparison="maximum"

[Cantor, Scott]

On 9/22/16, 11:52 AM, "users on behalf of Benjamin Lewis" <users-bounces at shibboleth.net on behalf of bhlewis at bhlewis.me> wrote:

> Yes, that's true. The app is communicating with the SP via a built-in
> browser of some sort and then is being redirected to our IdP with an
> AuthnRequest in hand.

Ok. Well, again, the real answer is to fix that SP. Operating in a mode which is non-interoperable with most IdPs by default and most IdPs period is just, well, not smart.

> What I've been thinking is that we'd want an entry in the map for every
> class that we consider to be at least as strong as one of the two SAML2
> classes we actually do support so that we can proceed with using the
> strongest class we do support that is less than or equally strong.

Only if you intend to support requests for absolutely any possible class, which is itself unbounded, so it's not possible to do that anyway.

So, no, I wouldn't try to do that. What I said was that if your login flows support A, B, and C, you should at least try and express the necessary relationships between those classes and the classes for which you expect to get a request with an inexact matching rule.

Since hardly anybody uses inexact matching rules, that's not really a huge set in practice.

-- Scott