[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