[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AI #88 - AuthnContext clarification
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]