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

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

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:pmishra@principalidentity.com]
Sent: Monday, December 27, 2004 12:01 AM
To: security-services@lists.oasis-open.org
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: security-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: security-services-help@lists.oasis-open.org