OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

[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