atom feed4 messages in and AuthnContextDeclRef
FromSent OnAttachments
Eric TiffanyMar 1, 2007 11:02 am 
Eve L. MalerMar 1, 2007 12:54 pm 
Eve L. MalerMar 1, 2007 1:56 pm 
Greg WhiteheadMar 1, 2007 3:52 pm 
Subject:AuthnContextDecl and AuthnContextDeclRef
From:Eric Tiffany (
Date:Mar 1, 2007 11:02:05 am

Another issue from our recent SAML testing.

A question arose whether an IdP can use an unspecified authentication context when the SP did not specify how it wished to be authenticated. One vendor was returning in its authentication statement

<saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </saml:AuthnContextClassRef> <saml:AuthnContextDeclRef> name/password/uri </saml:AuthnContextDeclRef> </saml:AuthnContext>

Another vendor rejected this statement saying the URI is proprietary and does not recognize it. They quoted from SAML CoreŠ

²<AuthnContextDecl> or <AuthnContextDeclRef> [Optional] Either an authentication context declaration provided by value, or a URI reference that identifies such a declaration. The URI reference MAY directly resolve into an XML document containing the referenced declaration.²

And from SAML Core 7.2.1

³The following constructs in the assertion schema allow constructs from arbitrary namespaces within them: <AuthnContextDecl>: Uses xs:anyType, which allows any sub-elements and attributes.²

So there are a couple of issues:

- The <AuthnContextDeclRef> in the example above is a relative URI, so it is questionable whether it "identifies" a declaration, particularly in the absence of any base URI.

- The text describing AuthnContextDecl and AuthnContextDeclRef is a bit confusing, since it says "either [...] a declaration provided by value, or a URI reference". Of course the schema is clear on which is which, but an implementer might be confused and think that either element may contain either a URI or a anyType

- In this case, where the SP didn't specify the AuthnContext in the request, the IDP is free to do what it wants. However, perhaps there should be some guidance about how this should be handled in practice.

Consulted on the matter, Greg Whitehead noted that this was more of a configuration issue where both parties needed to agree out-of-band rather than a failure to be conformant to the standard. It might be worth adding some language to this effect in the discussion of the <RequestedAuthnContext> element (sec 3.4.1, line 2034 of saml core).

Also, it might be worth clarifying the language at so that the type of the two elements is less ambiguous.