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: <blah>].
Interoperability - Active
| Description
|
Acceptable
|
Not Acceptable
|
Examples/Tests
|
| Differing Token Type: RP handling of a token type other than what it asked for
|
accept or actionable message returned
|
no actionable message or failure
|
not yet
|
| Newlines in Signature: RP handling of a signature that contains line breaks or newlines
|
accept
|
exception or failure
|
IdP Signature with Newlines Test
|
| RP receives a token which does not contain an inclusiveNamespaces element
|
fail with actionable message (otherwise a brown bag attack is possible)
|
exception or ignore
|
not yet
|
| RP handling of a token that is encrypted in a way that the RP can not decrypt (eg: 256-b AES encryption)
|
actionable message (e.g. "US Govt export control violation")
|
exception
|
not yet
|
| RP receives a token whose notBefore and notOnOrAfter elements are outside an RP-defined window of error (eg 5-second window of error).
|
failure with actionable message
|
exception, continue
|
not yet
|
| RP receives a token whose X509 certificate path does not validate.
|
failure with actionable message
|
exception, continue
|
not yet
|
| RP receives token with a WSU 'expires' element that is expired
|
failure with actionable message
|
exception, continue
|
not yet
|
Interoperability - Deferred
| Description
|
Acceptable
|
Not Acceptable
|
Examples/Tests
|
| Presence/Absence of Trailing Slashes: RP handling a claim with a name whose last character either ends with '/' when the requested claim type did not, or returns a claim with a name whose last character does not end with '/', when the requested claim type did contain a '/'
|
accept [H: reject] (ANSWER UNDER REVIEW)
|
exception or failure [H: accept]
|
not yet
|
| RP handling a claim whose short name matches a requested attribute, but whose namespace is different
|
fail with actionable message
|
failure with no actionable message, accept
|
not yet
|
| RP handling a claim whose name is different in case than what was requested by the RP
|
ignore case [H: fail on differing URI path](ANSWER UNDER REVIEW)
|
failure [H: accept on differing URI path]
|
not yet
|
| RP handling a SAML token containing an audience restriction parameter (e.g. URL of the RP) that does not include the namespace of the current RP
|
failure with actionable message
|
accept, ignore, failure without actionable message
|
| RP receive a token that does not have a NotBefore and NotOnOrAfter element (note that misspelled elements do not count)
|
failure with actionable message
|
exception, continue
|
not yet
|
Component Support
Legend: Yes = supported; No = not supported; ? = unknown; tbd = support possible near term; some = some features supported
Section Two
| RP to IdP
|
Description
|
Acceptable
|
Not Acceptable
|
| Token Encoding
|
SAML version: 1.0, 1.1, 2.0
|
accept or ignore or actionable message returned
|
no actionable message or failure
|
|
|
Base 64 line break
|
accept or ignore
|
no actionable exception or failure
|
|
|
SOAP version: 1.1, 1.2
|
accept or ignore
|
no actionable exception or failure
|
|
|
URL with trailing extra '/'
|
Ignore or parse if extre '/' causes different behavior
|
failure
|
|
|
claim namespace unrecognized
|
ignore
|
failure
|
|
|
case-insensitive
|
parse, ignore or retry ignoring case.
|
failure
|
|
|
hashes in signed tokens
|
parse or ignore or return error code to IdP for retry. See error codes (TBD)
|
failure
|
|
|
XML canonicalization library mismatch
|
ignore
|
failure
|
|
|
text padding
|
strip padding and proceed or ignore
|
failure
|
|
|
256-b AES encryption unsupported
|
ignore or user-message "US Govt export control violation"
|
failure
|
|
|
path validation timeout
|
5 seconds max
|
failure, more than 5 seconds
|
|
|
|
|
| RP to IA
|
Description
|
Acceptable
|
Not Acceptable
|
| Multiple cards
|
Users can have different cards representing the same claims and IdP on different systems; i.e. cards are not exported and then imported to another system.
|
Accept card from either system without requiring re-registration. This may not seem relevant to information card technology, per se. What relevance is has is that RPs need to be able to associate more than one information card with an account.
|
Cancel one card and register new one when systems are changed. This includes actions like validating email addresses.
|
- 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)
