I2 RP Profile Token Validation

This section represents variations in presentation & format of a returned token that an RP should deal with in a graceful manner.

* I2-Barcelona   * I2 Relying Party Profiles      * I2 RP Profile Claim Processing    * I2 RP Profile Token Validation

The Higgins team reviewed this table on Oct 10, Higgins comments are in [H: ].

Component Support
Legend: Yes = supported; No = not supported; ? = unknown; tbd = support possible near term; some = some features supported

Section Two

 * It became clear during the run-up to the interop that no standard set of token and claim validation procedures had been defined for RPs. (Bob)
 * Matching rule issues caused some failures (for example, is a URL with an appended "/" the same as or different from the same URL without the "/"?) (Bob)
 * Some RPs rejected claims because they did not recognize the claim namespace generated by the IDP. (Bob)
 * Some RPs rejected claims because of case-sensitivity issues. (Bob)
 * SAML token version requirements are underspecified; IDPs and RPs need to be able to agree on the supported token versions. (Bob)
 * Base-64 encoding issues caused some failures due to incompatible assumptions about where line breaks may legally occur. (Bob)
 * Adherence to robustness principle would help a lot here. I.e. receiver of base-64 encoded stuff doesn't care where line breaks happen. (Eric)
 * Some RPs rejected claims because of ambiguities in what token information was to be included in the scope of hashes in signed tokens. (Bob)
 * Some RPs encountered issues with XML canonicalization of tokens. Use of a standard canonicalization library may be desirable. (Bob)
 * Some issues were encountered with how plaintext data was padded prior to encryption. (Bob)
 * SOAP versioning (1.1 vs. 1.2) caused compatibility issues. (Bob)
 * Some RPs could not decrypt tokens because they lacked support for the encryption algorithm used; furthermore, since the failure resulted from inability to use 256-bit AES encryption, which is subject to US export controls and other international deployment and use restrictions, this problem may not be straightforward to fix. (Bob)
 * Certificate path validation is handled in a variety of ways by RPs; some RPs experience serious performance problems due to path validation. (Bob))
 * I see from the report that a lot of the problems were caused by picayune syntactic stuff. E.g. namespace comparisons, case differences, slashes on URLs and so forth. How about encouraging folks writing code to write it in such a fashion that it would be forgiving of such transgressions.  For example, if a comparison with what's expected fails, then just log the failure and continue as if there hadn't been a failure.  N.B. this is just for testing, not production, code. (Eric)
 * RP security best practices for Token Validation. What is a minimum set of verifications that a RP needs to perform in order to make the use case provably secure. (Uppili)