[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 none 2. Hal Lockhart alerts SSTC to WSSTC "CD Draft" status for SAML Token Profile Will forward/generate message with a link to the document. http://lists.oasis-open.org/archives/security-services/200408/msg00092.html 3. Minutes from August 3, Conference Call accepted http://lists.oasis-open.org/archives/security-services/200408/msg00024.html 4. General sentiment to work with dates specified in http://lists.oasis-open.org/archives/security-services/200408/msg00091.html 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. 5. a. proposed new text for X.500/LDAP attribute profile http://lists.oasis-open.org/archives/security-services/200408/msg00064.html 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 http://lists.oasis-open.org/archives/security-services/200408/msg00033.html 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) http://lists.oasis-open.org/archives/security-services/200408/msg00020.html Re: [security-services] MTI security models for SOAP Binding http://lists.oasis-open.org/archives/security-services/200408/msg00046.html MTI Security model for SAML URI Binding http://lists.oasis-open.org/archives/security-services/200408/msg00070.html All of the formats and semantics in Section 8.3 of core are MTI http://lists.oasis-open.org/archives/security-services/200408/msg00074.html d. Comments on SAML 2.0 Core draft-19... http://lists.oasis-open.org/archives/security-services/200408/msg00057.html 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 party. 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: <Status> <StatusCode Value="urn:oasis:names:tc:SAML:20.:status:Success" /> </Status> (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. c. Conformance with identifiers/affiliations (long) http://lists.oasis-open.org/archives/security-services/200408/msg00020.html 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.