[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
Thomas, 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> wrote: > 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]