RE: [security-services] Editorial Update to Section 3.3 of conformance

Title: RE: [security-services] Editorial Update to Section 3.3 of conformance

Prateek, I would agree with your changes for 8.3 identifiers.

For 8.4, since there is no normative processing rules, let me apply the intent of the section: "... it should be possible to configure a conformant SAML 2.0 implementation to generate and consume assertions containing [consent] identifiers ..." Since there are no rules for consuming assertions with consent identifiers (i.e., what should be done based on the presense or lack of a consent identifier), consumption is fairly trivial to implement by anyone (just ignoring it will suffice). For generation, the rules around this are not defined but what can be present/sent is defined. So this is still ambigous. I.e., for a conformant SAML 2.0 implementation, does an implementation need to be able to support the ability to generate any consent identifier (and the underlying meaning of it). For example, being able to ask the user for consent prior, implicit, or explicit (or any combination of these). There's a fair bit of work in implementing this and it's not clear if being conformant requires this.

For 8.2, I would have the same questions as in 8.4. One example, if being able to generate attributes using the URI name format. Does that imply that a conformant SAML 2.0 implementation is able to generate X.500/LDAP style attributes, UUID style attributes, DCE PAC style attributes and XACML style attributes? Same goes for consumption.

Tom.

-----Original Message-----

From: prateek mishra [mailto:]

Sent: Monday, December 27, 2004 12:01 AM

To: 

Subject: [security-services] Editorial Update to Section 3.3 of

conformance

On the December 21 conference call, Thomas W. and

Scott C. suggested that Section 3.3 of the conformance

document might require some additional text clarifying

intent. I had taken an action to start a thread on the

subject.

Section 3.3 includes the following text (lines

192-196):

---------------------------

All relevant operational modes MUST implement the

following SAML-defined identifiers:

1. All Attribute Name Format Identifiiers as defined

in Section 8.2 of [SAMLCore].

2. All Name Identifier Format Identifiers as defined

in Section 8.3 of [SAMLCore].

3. All Consent Identifiers as defined in Section 8.4

of [SAMLCore].

-----------------------------

The intent here is the following: it should be

possible to configure a conformant SAML 2.0

implementation to generate and consume assertions

containing the identifiers described in these

sections. One question that might then be asked is

whether consuming/generating such assertions implies

implementation of additional processing rules (e.g.,

integration with a Windows NT identity store).

A close reading of Sections 8.2-8.4, reveals that with

the exception of 8.3.7 and 8.3.8, no normative

processing rules are prescribed. In other words,

leaving aside these sections, all of the remaining

material is concerned with constraints on the element

(attribute) values or the intent of the message

issuer.

I would propose we add the following sentences

following line 196 to Section 3.3:

Sections 8.3.7 and 8.3.8 prescribe normative

processing rules for persistent and transient

identifiers requiring implementation by conformant

implementations. Sections 8.2-8.3 do not specify

normative processing rules for any of the remaining

identifiers.  

---------------------------------------------------------------------

To unsubscribe, e-mail: 

For additional commands, e-mail: