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] Editorial Update to Section 3.3 of confor mance


I think you are suggesting we look at the details of
sections 8.2, 8.3 and 8.4 in clarifying the intent of
Section 3.3 in conformance. I think this is a good way
to take this issue forward. 

Section 8.2 deals only with values for Name and
NameFormat attributes. Conformant implementations
should be able to generate and consume assertions with
these particular values. It should be possible to
configure a conformant SAML generator to create
assertions with any one of these values. It should be
possible to configure a conformant SAML consumer to
accept only some of these values. There is no
implication as to support for particular attribute
profiles etc.

Section 8.3 is similar except that 8.3.8 and 8.3.7
include some processing rules concerning persistent
and transient identifiers.  In the first case, the
assertion generator must guarantee that the identifier
is unique to an SP relationship or affiliation and, in
the second, that the identifier is never re-used. All
the remaining name identifiers restrict the syntax of
permissible values for NameID/Issuer/NameIDPolicy.
Exactly how the implementation obtains these values is
out-of-scope for SAML 2.0. This is an area where
different implementations will provide added value
thru flexible configuration, APIs etc.

Section 8.4 deals with consent and, as you have
pointed out, probably has the largest scope for
confusion on the generation side. Certainly, 8.4.5
(explicit) suggests that the conformant implementation
has some means of obtaining consent. The exact form is
again out of scope for SAML 2.0. Implementations can
compete for greater expressiveness/flexibility in this
space, but overall it seems a reasonable requirement
that conformant implementations have at least one way
to explicitly ask for consent from a user.

8.4.3 (Prior) and 8.4.2 (Implicit) are much weaker
notions: prior indicates that the implementation
believes that consent was obtained "recently" (this
could be based on some previois explicit consent) and
implicit seems to be purely a configuration issue. 

I think you are correct to say that consumers can
basically ignore consent values; only the ability to
differentiate between different values would be
required as in 8.2 or 8.3.

Let me know if this fits with your reading of Section
3.3 in conformance. I can then re-spin the proposed
text to include those parts of the guidance that we
agree we need to make explicit.

- prateek

--- Thomas Wisniewski <Thomas.Wisniewski@entrust.com>

> 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

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