Incorrect ECP Accept header

[John Dennis]

We've been doing some ECP interoperability testing and have uncovered 
what appears to be both a mistake in both the SAML spec and in the 
mod_shib implementation (v2.5.3).

The following SAML specs:

"Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 5 
OASIS Standard, 15 March 2005"

"SAML V2.0 Enhanced Client or Proxy Profile Version 2.0 Committee 
Specification 01 26 August 2013"

both use the following non-normative example of an Accept header:

Accept: text/html; application/vnd.paos+xml

In this example there are supposed to be two media types, html and paos, 
but the separator between the media types is a semicolon when instead it 
should be a comma, at least that's how I'm reading the HTTP spec

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

A semicolon is used to separate the type from it's optional parameters, 
types and their associated parameters are separated by commas. The 
example appearing in the SAML specs is illegal HTTP syntax because it's 
stating there is one media type of text/html with a parameter of 
application/vnd.paos+xml (which is nonsensical).

So why does this work in mod_shib? In the v2.5.3 code (the only version 
I checked) shibsp/handler/impl/SAML2SessionInitiator.cpp line 249 uses 
this code to test for paos in the accept header:

request.getHeader("Accept").find("application/vnd.paos+xml")

however doing a string search is not the same thing as parsing the 
header and can lead to erroneous results.

So it seems like there are two independent issues:

1) The SAML specs need to be edited (I checked the most recent errata 
and the error is still there).

2) mod_shib consumes a syntactically incorrect header and processes the 
request without error.

BTW, the reason this came up is because our SP never recognized the 
example ECP request because it thought the only media type in the Accept 
header was text/html (it ignores type parameters and does an exact match 
on the media type).

-- 
John