[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: MIME type for SAML messages
text/xml? I would think application/xml would be more appropriate if a specific media type registration such as application/saml+xml is not deemed necessary by the TC. A SAML assertion isn't text that is meant to be read by a human. From RFC2046: 3. Overview Of The Initial Top-Level Media Types The five discrete top-level media types are: (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". The line above: No special software is required to get the full meaning of the text, aside from support for the indicated character set. is key. A SAML assertion requires digital signature processing software at the very least to be even remotely meaningful. Also from RFC2046: (5) application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The subtype "octet- stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging. These issues are discussed later in this document. The media type of 'application' for SAML is more appropriate IMO. Choice of a subtype(s) should follow RFC3023. It may be appropriate to register different types to permit differentiation between say a SAML assertion from a SAML request or response message. e.g. application/saml-assertion+xml application/saml-message+xml or it may be deemed sufficient to simply use: application/saml+xml so that a SAML specific handler can be dispatched as opposed to simply dispatching a generic XML parser as would be the case for application/xml. Cheers, Chris Simon Godik wrote: > Tim, > I think that content type text/xml is fine. It is enough to dispatch content to the xml processor. > Top-level saml element will identify saml namespace and saml schema location so it can be processed > by the saml component. > Simon Godik -----Original Message----- From: Tim Moses [mailto:tim.moses@entrust.com] Sent: Friday, July 27, 2001 6:22 AM To: 'Oasis security services bindings' Subject: MIME type for SAML messages Prateek - I have investigated this topic a little. The SAML servlet on an HTTP server will have a distinct URL (the "partner ID" of the artifact will map to the SAML servlet URL). So, all SAML messages over HTTP will go to a servlet that is expecting to process only SAML messages. For this reason, a MIME type for SAML messages is not strictly needed. However, in the fullness of time, HTTP servers may be receiving XML messages for a large number of different purposes. So, we should consider registering a MIME type to distinguish the SAML messages from all the other stuff. Best regards. Tim. ------------------------------------------------------------------------ Tim Moses Tel: 613.270.3183
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC