AI #88 - AuthnContext clarification

[Scott Cantor <cantor.2@osu.edu>]

I took an action to post something hopefully in the way of explanation on
how the AuthnContext work fits into the SSO messages and what the different
elements are in the input proposal from ID-FF.

I am *not* the authority on this stuff. I'm partly doing it to provoke a
response from those in Liberty who are, to correct any errors I make. So,
please correct me.

Basically, I see three ways in ID-FF of expressing an authentication
context, which to repeat, is a particular extensible vocabulary for
describing metadata about the acts of identification and authentication
peformed by an IdP. It's metadata, in the sense that much of is potentially
static information that applies across a range of principals and
transactions, but it's also potentially dynamic if the information can
change from transaction to transaction. The different representations
address these different cases.

I don't think there's any reason you couldn't embed a static context in
actual metadata (as we've defined the term so far), and maybe we want to
think about that. (Any Liberty folks willing to chime in, feel free...) I
suspect it was timing and the way both specs evolved more than any technical
reason, but I don't know.

Anyway, back to the three ways:

A) Context Statement Reference (URI)

This is a document reference to an actual XML document containing an
instance that conforms to the full AuthnContext schema. It could have just
about anything in it. The actual URI might or might not be resolvable to the
XML, but if it's not, there must be some OOB understanding about what's in
it or it isn't very useful.

B) Context Class Reference (URI)

Context classes are kind of tricky. Basically it's an extensible set of URIs
that represent a constrained schema (based on the full schema) that limits
the kind of information in a particular context. It narrows the field, so to
speak, so that you're only dealing with a subset of the potential
vocabulary. The purpose is to define commmonly-used subsets for vertical
industries or based on common technology that simplfy implementation.

Context class URIs do not refer to a specific context document, but simply
to the schema for what the context might contain. That is, they aren't an
actual context, but a range of possible contexts, with a fixed URI.

IMHO, they most resemble the existing SAML AuthenticationMethod because they
classify the method used without providing explicit detail (for example,
they tell you a password is involved, but not the minimum password length).

C) Inline Context

The last representation is the full context instance, as an XML fragment,
embedded directly in an assertion or in a stand-alone document.

Now, how do they get used in SSO in ID-FF?

An AuthnRequest can contain either a set of possible statement refs (A) or a
set of possible class refs (B), and optionally a quality parameter that says
"match, at least meet, or do better than". So you don't actually inline a
full context, though you could reference one as a statement ref that has a
ton of detail in it.

Using class refs is more likely, I would think, but I'd note that if you
used the class approach, you couldn't specify things like minimum password
length unless you defined your own class URI for that. Which seems like a
mis-use of the feature, so basically if you care about a lot of detailed
control, you'd use statement refs. I think.

In the assertion you get back, in place of or alongside
AuthenticationMethod, you get back either a statement ref (A) or an inline
context (C), plus optionally a class ref (B). The purpose of the class ref
seems to be almost like an XML namespace, to signal the vocabulary of the
actual statement. I think that's something that you don't get from a quick
read of the AuthnContext spec, but that's my sense of how it acts.

-- Scott