[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Proposed addition to Section 3.3 of Conformance
Any other comments? If not... Prateek, can you make the proposed edit and add a statement about consent not being MTI? -------------------------- Conforming SAML implementations must provide facilities that permit consumers and producers of SAML messages to support all constants described in Sections 8.2 and 8.3. SAML message consumers must be able to process messages with constants present in these sections. SAML message producers must be able to create messages with constants present in these sections. A SAML implementation can provide the facilities described above through direct implementation support for the identifiers or through the use of supported programming interfaces. Interfaces provided for this purpose must allow the SAML implementation to be programmatically extended to handle all identifiers in section 8.2 and 8.3 that are not natively handled by the implementation. Note that only sections 8.3.7 (persistent name identifiers) and 8.3.8 (transient name identifiers) define normative processing rules for the producer of such identifiers. The remaining identifiers in sections 8.2 and 8.3 specify no normative processing rules. All normative processing rules in sections 8.3.7 and 8.3.8 must be supported. Since no normative processing rules exist for the other identifiers in 8.2 and 8.3, generation and consumption of these identifiers is meaningful only when the generating and consuming parties have externally-defined agreement on the semantic interpretation of the identifiers. <need additional text explaining that the consent identifiers (section 8.4) are not MTI> --------------------------- Rob Philpott Senior Consulting Engineer RSA Security Inc. Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com > -----Original Message----- > From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] > Sent: Wednesday, January 05, 2005 9:29 AM > To: Scott Cantor; security-services@lists.oasis-open.org > Subject: RE: [security-services] Proposed addition to Section 3.3 of > Conformance > > Agree on both points. > > Rob Philpott > Senior Consulting Engineer > RSA Security Inc. > Tel: 781-515-7115 > Mobile: 617-510-0893 > Fax: 781-515-7020 > mailto:rphilpott@rsasecurity.com > > > -----Original Message----- > > From: Scott Cantor [mailto:cantor.2@osu.edu] > > Sent: Wednesday, January 05, 2005 1:40 AM > > To: Philpott, Robert; security-services@lists.oasis-open.org > > Subject: RE: [security-services] Proposed addition to Section 3.3 of > > Conformance > > > > > A SAML implementation can provide the facilities described > > > above through direct implementation support for the > > > identifiers or through the use of supported API's. API's > > > provided for this purpose must allow the SAML implementation > > > to be programmatically extended to handle all identifiers in > > > section 8.2 and 8.3 that are not natively handled by the > > > implementation. > > > > Can we s/APIs/programming interfaces? Sounds a little less wonkish for > the > > document to me. > > > > > Note that only sections 8.3.7 (persistent name identifiers) > > > and 8.3.8 (transient name identifiers) define normative > > > processing rules for the identifiers. The remaining > > > identifiers in sections 8.2 and 8.3 specify no normative > > > processing rules. All normative processing rules in sections > > > 8.3.7 and 8.3.8 must be supported. > > > > The only normative rules that apply to an SP are that you shouldn't > store > > a > > transient (so it's not a "do this", but a "don't do this"). I think > it's > > worth saying that, maybe changing the first sentence to: > > > > "Note that only sections 8.3.7 (persistent name identifiers) and 8.3.8 > > (transient name identifiers) define normative processing rules for the > > *producer of such* identifiers." > > > > -- Scott > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-services-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: security-services-help@lists.oasis- > open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]