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] | [List Home]


Subject: RE: [security-services] Another PE/editorial change for B&P when no/expired assertion for artifact is encountered...


I agree with this change as well.  I've had to chase down this answer before, and reached the same conclusion.  So stating it clearly will help interoperability.
--
Steve


-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Thursday, May 01, 2003 10:24 AM
To: security-services@lists.oasis-open.org
Subject: Re: [security-services] Another PE/editorial change for B&P
when no/expired assertion for artifact is encountered...


I think we should make this change, but be especially alert to 
complaints during last call, in case someone wants to argue that this 
*isn't* editorial and needs a vote/fix (since we're doing it as a 
last-minute thing).

	Eve

Jahan Moreh wrote:
> First, I agree with the proposed change.
> Second, I have created PE 19 detailing this editorial correction. 
> Assuming there are no objections, I will dispose of the PE as proposed 
> by Rob.
>  
> Jahan
> ----------------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
> 
>     -----Original Message-----
>     *From:* Philpott, Robert [mailto:rphilpott@rsasecurity.com]
>     *Sent:* Wednesday, April 30, 2003 3:00 PM
>     *To:* 'security-services@lists.oasis-open.org'
>     *Subject:* [security-services] Another PE/editorial change for B&P
>     when no/expired assertion for artifact is encountered...
> 
>     Hi folks,
> 
>     Lines 505-507 (section 4.1.1.6) of the -02 draft B&P Word document
>     state:
> 
>     "If the source site is able to find or construct the requested
>     assertions, it responds with a <samlp:Response> message with the
>     requested assertions. Otherwise, it returns an appropriate status
>     code, as defined within the selected SAML binding."
> 
>     This is not really clear and will probably be construed by the
>     reader to mean either that a SAML error status code should be
>     returned in a samlp:Response or that a SOAP fault error should be
>     returned (assuming the "selected SAML binding" is SOAP over HTTPS). 
>     I believe that we've all agreed that the "appropriate" result is to
>     send a samlp:Response with a status code set to "Success" but that
>     the response contains no assertions.
> 
>     At least this is consistent with what we state in -core regarding
>     Query/Request processing.  It is also consistent with my research
>     through the archives since I recalled this being discussed once upon
>     a time.
> 
>     Last February, Dipak Chopra from SAP submitted a lengthy list of
>     comments/questions to the -comment list on the specs. Hal fwd'ed the
>     message to the main list.  The link for the fwd'ed message is:
> 
>     http://lists.oasis-open.org/archives/security-services/200203/msg00026.html
> 
>     Item 30 in that list was:
> 
>     "30. Bindings & Profiles Doc. If the assertion is created at the
>     time of
>     artifact creation and the request for this assertion comes after the
>     assertion has expired, will the source site return the expired
>     assertion or
>     an error response or a successful response with no assertion? 
> 
>     Prateek responded to a number of the comments/questions on 8-Mar-02
>     in message:
> 
>     http://lists.oasis-open.org/archives/security-services/200203/msg00045.html
> 
>     His specific response was:
> 
>     -----------------------------
>     [Prateek]
> 
>     Any one of the following responses is conformant: (1) no assertion
>     is returned with SUCCESS status code, (2) the expired assertion is
>     returned with SUCCESS status code.
>     -----------------------------
> 
>      From what I can find in subsequent minutes and email exchanges,
>     there wasn't much more said about it and there wasn't an action item
>     to clarify it in B&P. 
> 
>     Soooo... since Prateek's response clearly states the expected result
>     and, as I mentioned, this is consistent with what we state in -core
>     regarding Query/Request processing, I would really like to clarify
>     the B&P text and treat it as an editorial/errata change.
> 
>     DOES ANYONE OBJECT to treating it as such with the following
>     replacement text:
> 
>     "If the source site is able to find or construct the requested
>     assertions, it responds with a <samlp:Response> message with the
>     requested assertions. Otherwise, it responds with a <samlp:Response>
>     message with no assertions and a <samlp:StatusCode> element with the
>     value Success." This would be consistent with the wording in -core.
> 
>     *Rob Philpott*
>     *RSA Security Inc.*
>     /The Most Trusted Name in e-Security/
>     *Tel: 781-515-7115*
>     *Mobile**: 617-510-0893*
>     *Fax: 781-515-7020*
>     mailto:rphilpott@rsasecurity.com
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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