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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [security-services] Action A9: Error handling for SOAP profil e

> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> >>If the receiving party understands the SAML assertion in the 
> >>SOAP header,
> >>but considers the assertion invalid, the receiving party 
> >>SHOULD return a
> >>SOAP message with a <Fault> element as the message body. 
> What about the case where the SAML assertion is malformed or
> the receiving party cannot find extension schema etc. etc. It seems
> to me these are all reasonable grounds for returning a SAML error.
> Basically, we are saying that we are providing an error for the
> case where the recipient has a problem in dealing with
> the assertion.
> - prateek

This comes down to the discussion we had at F2F5 about the distinction
between the "SOAP processor" and the "SAML processor". If the receiver can't
parse the SOAP message because it's not valid XML (which may include schema
validation of the SAML-specific contents), it will most likely return a
standard SOAP <Fault> and the SAML processor will never be invoked.

Once the message gets through the SOAP processor and into the SAML
processor, we can talk about what sort of <Fault> we return.

I don't want us to constrain this too tightly, because different SOAP
infrastructures will likely provide different levels of support for schema
checking of message contents. That means some implementations may not have a
choice of returning the SAML-specific <Fault> for schema errors.

 - irving -

The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC