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: Minutes from SSTC COnference Call, August 10

SSTC COnference Call, August 10, 2004

1. Roll call

36/41 voting members present.

Attendance of Voting Members

  Conor P. Cahill AOL, Inc.
  Hal Lockhart BEA
  Rick Randall Booz Allen Hamilton
  Ronald Jacobson Computer Associates
  Gavenraj Sodhi Computer Associates
  Tim Alsop CyberSafe
  Paul Madsen Entrust
  Dana Kaufman Forum Systems
  Irving Reid Hewlett-Packard Company
  Paula Austel IBM
  Maryann Hondo IBM
  Michael McIntosh IBM
  Anthony Nadalin IBM
  Nick Ragouzis Individual
  Scott Cantor Internet2
  Prateek Mishra Netegrity
  Forest Yin Netegrity
  Peter Davis Neustar
  Frederick Hirsch Nokia
  John Kemp Nokia
  Senthil Sengodan Nokia
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Ari Kermaier Oracle
  Vamsi Motukuru Oracle
  Darren Platt Ping Identity
  Jim Lien RSA Security
  John Linn RSA Security
  Rob Philpott RSA Security
  Dipak Chopra SAP
  Jahan Moreh Sigaba
  Bhavna Bhatnagar Sun Microsystems
  Jeff Hodges Sun Microsystems
  Eve Maler Sun Microsystems
  Ron Monzillo Sun Microsystems
  Emily Xu Sun Microsystems
  Mike Beach The Boeing Company
  Greg Whitehead Trustgenix
  James Vanderbeek Vodafone

Attendance of Prospective Members or Observers

  Cameron Morris Novell
  Scott Kiester Novell
  Rebekah Metz NASA

Membership Status Changes


2. Hal Lockhart alerts SSTC to WSSTC "CD Draft" status for SAML Token Profile
Will forward/generate message with a link to the document.


3. Minutes from August 3, Conference Call accepted


4. General sentiment to work with dates specified in

Eve: conformance document will list all the normative documents.

Voice vote scheduled for August 17 as discussed on August 3 conference call.
Vote scheduled for first part of August 17 meeting.


a. proposed new text for X.500/LDAP attribute profile

Scott: Proposes we adopt text, main change is a new encoding attribute specific
to this profile.

Conor seconds. 

Call for discussion, objections. Motion carries.

b. Addition of more wildcarding

Scott: separate discussion of any attribute from discussion of ID attribute.
Initiates discussion of any attribute flexibility.

Proposal is to add schema flexibility of any attribute to all root elements, assertion,
request, response. 

Eve: concern about this type of flexibility without concrete use-cases. 
This can be achieved via schema-extension in any case.

Ari: Also prefers schema-extension as the correct route going forward.

Conor: concerns that a validating parser would fail with the schema extension model.

Scott: shifts to discussion of ID attribute issue. Suggests that by allowing arbitrary
attributes and making ID attribute optional in schema but required in prose, 
in SAML 2.1, we can begin using the forthcoming XML ID proposal (still emergent).

Conor: Why don't we change schema in SAML 2.1?

Eve, Scott: dont want to make schema changes in a DOT release. 
Ron: Have we discussed the possibility of an attribute choice at this level?

Scott: Not supported by XML Schema.

John Kemp: Feels a little odd that we are opening up our schema with a view to
incorporating as yet unknown XML attribute.

Scott: Make ID attribute optional in schema but required in prose.

Eve: Only a single ID attribute may be present but schema may include many ID attributes.

Ari: concern that we should not make changes based on behavior of popular parsers.

Eve: Motion to change the cardinality of the current ID attributes 
in schema to be optional with prose making it required. 
This is contingent upon schema permitting schema permitting 
multiple optional ID attributes and implementations correctly implementing this rule.

Eve will resolve schema issue, Scott will resolve the implementation issue.

Tony: Why do we need to address this issue at this time?

Scott, Eve: Motion is withdrawn but with non-normative text in ID, IDRef section that
speaks to the possibility of a standardized XML ID attribute. Includes reference
to XML ID issue draft. Action to Eve.

      c. proposed updates to conformance document

      Conformance with identifiers/affiliations (long)   

      Re: [security-services] MTI security models for SOAP Binding


    MTI Security model for SAML URI Binding

     All of the formats and semantics in Section 8.3 of core are MTI

    d. Comments on SAML 2.0 Core draft-19...


Why do we have separate attributes for MajorVersion and MinorVersion?   
Can't we have a single attribute called version with a fixed decimal format (2.0).  
Also, can't we make MinorVersion optional so that if it isn't present it defaults to zero.  
This applies to the assertion itself, as well as the RequestAbstractType.

Motion: Replace the pair of attributes by a single attribute and update text accordingly.

Steve takes roll. Vote carries. Action to Scott Cantor to propose text and make changes.

Lines 560-565:  The way this is laid out in the schema, 
I can have 0 or more of the 4 statements in a random order.  I would rather see this 
done by removing the choice and then having the 4 statements listed with min=0, max=unbounded.
That way the statements of the same type all come together. 

Irving: Why add order when it has no semantic significance to it? What about the case where
additional statement types are included.

Rob: consensus that this could be deferred to a future release.

Lines 722-731: These make statements as to the validity of the assertion based upon the 
conditions.  I think that it should refer to the condition check step in the validation 
process rather than saying that the assertion is valid.   So, if the condition is not met, 
the condition check step fails.  If the conditions are not specified, empty or all are met, 
the condition check step is passed.    I don't like the current statement on line 724-5 
that says 'the assertion is considered to be Valid".  Similarly, I would say that conditions 
are met or not met (as opposed to valid or invalid -- the conditions themselves are (almost) 
always valid, it's just whether or not they are met that is of interest here). 

Action Item to Scott: Clarify text around 724/730 to say: assertion is considered valid subject to
other processing or contingencies.

Line 1873: Strongly recommend that IsPassive default to "false" not True.   
The passive request is the exception to the rule and the default should be set accordingly. 

Greg: The reason this defaults to "True" because the thinking was that URL-encoding would
be minimized with this default. This is the history in Liberty, my opinion is that we should
change it.

Motion: Conor, Seconded: Scott.

Motion carries with unanimous consent. Action to Scott to make changes.

Lines 1942-1946: I thing this is a bit watered down from what it should be.    Essentially this
is specifying that the Requesting Entity is asking the Identity Provider to establish a 
new relationship identifier (federation identifier) for the subject at the relying party. 
I also think the default should be "False".  Suggested wording: 
A boolean value used to indicate that the requesting party would like the 
Identity provider to create a new federated name identifier (if one doesn't already exist) 
for the subject at the relying party.  Defaults to "false".  When "false" the AuthnRequest 
should fail unles an existing federated name identifier exists for the user at the relying 

Scott moves, Conor seconds. Motion carries unanimously, action to Scott to make changes.

Line 1430:  Status should not be required.  If not present, it should be interpreted as: 
    <StatusCode Value="urn:oasis:names:tc:SAML:20.:status:Success" />
(Note that I think this awful lot of stuff to just say "OK".)

Jeff: Prefers to keep it this way. Prateek agrees. No change to specification.

Conformance with identifiers/affiliations (long)   

Scott: Strike first two rows of Table 3 Extended profile matrix, replace with language
that states all IdP, SP, support the name formats in Section 8.3 of core.

Nick: Seconds. 

Motion carries by unanimous consent. Action to Prateek.

> 2.3 Security models for SOAP Binding
> The following security models are MTI for profiles that use the SOAP
> binding. The SAML requester and responder MUST implement the following
> authentication methods:
> 1. No client or server authentication. 
> 2. HTTP basic authentication [RFC2617] with and without SSL 3.0 or TLS 1.0.
> The SAML requester MUST preemptively send the authorization header with the
> initial request.  
> 3. HTTP over SSL 3.0 or TLS 1.0 (see Section 6) server authentication with a
> server-side certificate. 
> 4. HTTP over SSL 3.0 or TLS 1.0 mutual authentication with both server-side
> and a client-side certificate. 
> If a SAML responder uses SSL 3.0 or TLS 1.0, it MUST use a server-side
> certificate. 

Greg moves, Mike seconds. Motion carries unanimously - Prateek to implement.

Scott moves that the same security model be MTI for URI binding, Jeff seconds.
Motion approved unanimously.

Eve moves that There were other conformance considerations included in 
that document that we may want to bring forward (things like maximum 
number of nested elements etc.). Scott seconds. Unanimous consent.

Scott: a section in conformance to enumerate all MTI signatures and encryption
in SAML 2.0.

Jeff seconds. Unanimous consent. 

Scott proposes that a single matrix for IdP Extended, IdP, IdP Lite (and SP) be
maintained in the document.

Add text explaining that the matrix of implementations in Table 1 is an enumeration 
of all possible profiles and implementations.

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