OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] AuthnContextDecl and AuthnContextDeclRef


Tom S. sent me mail asking about someday removing the "must consist 
of at least one non-whitespace character" portion since it seems 
redundant (URIs being real strings).  I remembered we had that in 
there for a reason, so I took a walk down memory lane and found a 
thread from June 2002 called "ISSUE: Fragment identifiers for URI 
references on the Format attribute".  Here's one key message in it:

http://lists.oasis-open.org/archives/security-services/200206/msg00036.html

I recall that in V1.0 we had urn:blah#emailAddress and so on as our 
name formats, and someone in early interop testing assumed urn:blah 
as the base URI and just supplied #emailAddress.  This caused all 
kinds of grief.  So we ultimately undid that, and ensured that 
"empty URIs" (which are not the same thing as relative URIs) weren't 
an option by means of the above constraint.

IETF RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt), which replaced 
2976 for URI definition a little while back, still has the 
"path-empty" option for the "hier-part" of URIs, so I think we don't 
have any redundancies in there, though it's perhaps inelegantly 
expressed.  (I haven't dug very deeply into this RFC series in many 
years and may be missing other tricks here, but that's the gist.)

And That's The Way It Was.

	Eve

Eve L. Maler wrote:
> The Core spec (Section 1.3.2, lines 303-305) says:
> 
> "Unless otherwise indicated in this specification, all URI reference 
> values used within SAML-defined elements or attributes MUST consist of 
> at least one non-whitespace character, and are REQUIRED to be
> absolute [RFC 2396]."
> 
> We did away with (implicitly) allowing relative URIs after running into 
> problems in V1.0, if I remember correctly.
> 
>     Eve
> 
> Eric Tiffany wrote:
>> 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 2.7.2.2Š
>>
>> ²<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 2.7.2.2 so that the 
>> type
>> of the two elements is less ambiguous.
>>
>> ET
>>
> 

-- 
Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]