Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Liberty Alliance Project:Liberty ID-FF Bindings and Profiles SpecificationVersion: 1.2-errata-v2.0400401402403404405406407408409Additionally, to support the optional identity provider introduction profile, either the user agent or a proxy mustsupport session cookies (see [RFC2965]). The issue of using persistent cookies or session-length cookies is discussedin [LibertyImplGuide].3.1.2. Formatting and Encoding of Protocol MessagesAll protocol messages that are indicated by the profile as being communicated in the component of the URLMUST adhere to the formatting and encoding rules in Section 3.1.2.1.3.1.2.1. Encoding URL-embedded MessagesURL-embedded messages are encoded using the application/x-www-form-urlencoded MIME type as if theywere generated from HTML forms with the GET method as defined in [HTML4].The original XML protocol message MUST be encoded as follows:410411412413414415416417418419420421422423424425426427428429430431432433• The component parameter value MUST be the value of the XML protocol message element or attributevalue.• The value of the component parameter MUST be a space-delimited list when the original messageelement has multiple values.• Some of the referenced protocol message elements and attributes are optional. If an optional element or attributedoes not appear in the original XML protocol message, then the corresponding data item MUST be omitted fromthe URL encoded message.• URLs appearing in the URL-encoded message SHOULD NOT exceed 80 bytes in length (including %-escapingoverhead). Likewise, the data value SHOULD NOT exceed 80 bytes in length.• The URL-encoding of status codes in the responses RegisterNameIdentifierResponse andLogoutResponse may be taken from several sources. The top level codes MUST be from SAML.Other codes (including Liberty-defined values) MAY be used at the second or lower levels. The URL parametervalue should be interpreted as a QName with the "lib", "saml", and "samlp" namespaces pre-defined to theirrespective namespace URIs. Query parameters with the name "xmlns:prefix" can be used to map additionalnamespace prefixes for the purpose of QName resolution, so long as the xmlns:prefix URL parameter appearsbefore the URL parameter containing the QName which needs the prefix definition.As elements may be nested hierarchically (see [[SAMLCore11]), there may existmultiple values for in the response messages. These multiple values MUST be encoded byproducing a URL-encoded space-separated string as the value of this query parameter. An example is as follows:Value=samlp%3AResponder%20lib%3AFederationD oesNotExist• Certain XML protocol messages support extensibility via an element. Messages that are to beURL-encoded MUST adhere to the following restrictions when including extension content:434435436437438• Only attribute values and elements with simple content models are permitted.• All attributes and elements MUST have an empty namespace and MUST have unique local names.• Each value included SHOULD NOT exceed 80 bytes in length (including encoding overhead).XML digital signatures are not directly URL-encoded due to space concerns. If the Liberty XML protocol message issigned with an XML signature, the encoded URL form of the message MUST be signed as follows:Liberty Alliance Project13