[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]