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] Proposed addition to Section 3.3 of Conformance


I concur on the need for further clarification, although it needs tweaking. Since the 2nd paragraph refers to both attr-format identifiers (section 8.2) and name identifier formats (section 8.3), the additional text needs to work for both of these types of identifiers.  I've reworked the text a bit to hopefully add additional clarification.  How's this?

-------------
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 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.

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. 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
________________________________________
From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com] 
Sent: Tuesday, January 04, 2005 7:11 PM
To: Scott Cantor; Philpott, Robert; 'prateek mishra'; security-services@lists.oasis-open.org
Subject: RE: [security-services] Proposed addition to Section 3.3 of Conformance

Scott, yes I did mean the Name identifier content being equal. 
Your statement about "both parties agree on its interpretation" 
is what I think is missing in Rob's original email. For Saml 
transient and persistent identifier formats this is defined. 
However, for the others, the interpretation of the Name 
Identifier content data is not clear. As you point out, there's 
probably a better way to word my statement. 
Tom. 

-----Original Message----- 
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, January 04, 2005 6:11 PM 
To: 'Thomas Wisniewski'; 'Philpott, Robert'; 'prateek mishra'; 
security-services@lists.oasis-open.org 
Subject: RE: [security-services] Proposed addition to Section 3.3 of 
Conformance 

> Does it make sense to add a clarification statement around 
> what consumption means (i.e., what it does not imply for  
> conformance). For example, changing the last sentence in the 
> second paragraph to: 
> 
> ------------- 
> The remaining identifiers in these sections do not specify normative 
> processing rules. Therefore, their generation and consumption will only 
> be valid when both providers share common values for these identifiers. 
> Additional mapping or federation of these identifier formats is 
> implementation specific. 
I think you have the word identifiers overloaded here, but the sentiment is 
fine. When you say "share common values", you mean the NameIdentifier 
content, not the format identifiers, right? The latter is a given, 
obviously. 
Clearly, any semantically meaningful identifier is only useful (apart from 
treating it opaquely as a handle) if both parties agree on its 
interpretation. 
> I would also like to confirm that support for the persistent 
> name identifier and therefore the normative text around it will be 
> required for conformance based on the wording changes below. I ask this 
> because on the call, I asked if there were any objections to saying that 
> at least this one would be mandatory if we narrowed the list. And there 
> seemed to be objections -- so I would assume those objections would no 
> longer be relevant. 
I wasn't sure whether anybody objected or not, I just wasn't sure that if we 
tried to narrow the list, that everyone agreed on that one. I didn't hear us 
put it to a question. 
-- Scott 


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