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


Title: RE: MIME type for SAML messages

I have minimalist approach to this issue. The problem I see is proliferation of xml
acronyms to the point when it becomes unmanagable. We can argue for soap, saml, xaml,
xmlp, etc... It is a dispatching hint, but for me more of a headache than a benefit.

Other than that new content subtype for saml is fine.

Simon

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, July 27, 2001 10:45 AM
To: Simon Godik
Subject: Re: MIME type for SAML messages


The SAML specific media subtypes aren't necessarily *for* the
HTTP binding. They/it would be generally useful. I don't know
if this has been discussed, but it seems to me that a SAML assertion
(or a SAML request/response message) might be used in some
context such as multipart/mime (as in the case of SOAP Messages
with Attachments) or possibly DIME.

NB that text/xml is what SOAP1.1 specifies, but the XMLP WG *may*
choose to adopt something else (there is a groundswell of support
lately for application/soap+xml) for SOAP1.2.

Cheers,

Chris


> Simon Godik wrote:
>
> I would agree with application/xml versus text/xml
>
> I'm not sure why we want to create saml-specific content sub-type for http binding.
> Even if we did, saml is also bound to soap, which is used on top of http with text/xml
> So there is a chain of xml processing (soap - saml) based on top level element that
> you can not avoid. Why not use the same dispatching code all the time?
>
> Simon
>
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Friday, July 27, 2001 9:45 AM
> To: Simon Godik
> Cc: 'Tim Moses'; 'Oasis security services bindings'
> 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