← Prev in month
← Prev in thread
Next in thread →
Next in month →
Minutes for Telecon, Tuesday 31 August 2004
Minutes for SSTC Telecon, Tuesday 31 August 2004 Dial in info: +1 865 673 6950 #351-8396 Minutes taken by Steve Anderson ====================================================================== Summary ====================================================================== Votes: - Minutes from 17 August 2004 call accepted - Adopt posted schema to fix current CD - Amend currently posted metadata schema, deleting line 107 - Make DEFLATE encoding MTI in HTTP Redirect Binding - Add text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00191.html > regarding MTI Encryption to conformance document - Accept text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00194.html > - Accept text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00214.html >, with removal of MTI requirement for Excl-C14N - Add text to line 1905 of core making ACSIndex and ACSUrl mutually exclusive - Adopt text similar to Conor's < http://lists.oasis-open.org/ archives/security-services/200408/msg00221.html > in core Status Changes to Previous Action: - #0193: Minor fix for Schema Encoding - CLOSED - #0176: Provide sequence diagrams for profiles - CLOSED New Action Items: - Scott will review minutes of F2F regarding SessionIndex and make proposal addressing Paul and Conor's comments - Rob to contact Tony regarding XML-Encryption thoughts ====================================================================== Raw Notes ====================================================================== > > Agenda: > > 1. Roll call > - Attendance attached to bottom of these minutes - Quorum achieved > > 2. Accept minutes from previous meeting, 17 August > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00153.html > > - [VOTE] unanimous consent, accepted > > 3. Proposed normative update to sstc-saml-schema-assertion-2.0.xsd > (VOTE) > > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00218.html > > - Scott: corrects errors in some extension work - updated version now passes schema checker at IBM's alphaworks site - biggest highlight was around BaseID element, which can now be extended via complex content - anyAttribute is still in there, but could be taken out - decoupled NameID and EncryptedID - mostly left SubjectConfirmation stuff alone - this should all be less stressful on various tools - Prateek: any functional impact? - Scott: no, would only affect extensions - also now provides common type hierarchy for encryption, which JohnH had wanted, but wasn't previously feasible - Rob: for formal process, we were already going to have to do another CD, so we can consider making this the schema for the next CD - Scott: there is another content ambiguity issue that can be rolled into this - Rob: we'll do them separately - [MOTION] Adopt posted schema to fix current CD - [VOTE] no objections, passes - Scott: should be minimal changes required to prose - [MOTION] Amend currently posted metadata schema, deleting line 107 - Scott: functional impact is that extensions will derive from RoleDescriptor - [VOTE] no objections, passes - Rob: is any text needed in metadata spec? - Scott: a little, should already have it - Scott: there's another set of changes we could make, regarding "other" namespace - will send mail to list to describe > > 4. Revised Schedule > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00091.html > > > (a) CD vote on August 17, 2004 > (OASIS 30 day review period ends September 16, 2004) > > (b) Final disposition of all comments on September 21, 2004. > Editors prepare revised document set for second CD vote. > > (c) Final disposition of all comments received during second CD > cycle by October 19 > (OASIS 30 day review period ends October 14, 2004) > > (d) Editors submit final document set for OASIS standardization on > October 26 > - Prateek: (b) is the proposal - Rob: 2nd CD review can't end 14 Oct - Eve: the review timelines have to begin when Karl posts the CDs - Prateek: so the current review ends 19 Sept - so can we be ready with changes on 21 Sept, ready to vote for 2nd CD? - Rob: even if we vote on 21 Sept, probably wouldn't start review until 24 Sept - Prateek: we'll still aim for 21 Sept to receive and handle comments - Rob: we're looking at submitting to OASIS for vote mid Nov - Prateek: will update and repost this schedule info > > 5. Updates to conformance document (VOTE) > > (a) DEFLATE encoding as MTI > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00189.html > > - Prateek: was discussed on last week's focus call - currently unclear in text whether this is MTI, although our intent was fairly clear - Scott: should we put this MUST in the bindings doc? - Prateek: fair enough - [MOTION] Make DEFLATE encoding MTI in HTTP Redirect Binding - [VOTE] no objections, passes > > (b) Encryption as MTI > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00191.html > > - Prateek: was discussed on last week's focus call - Implementations MUST be able to process encrypted equivalents of name identifiers, attributes and assertions - Rob: does this apply to all operational modes? - Prateek: yes - Scott: where appropriate - Prateek: right, where the generic versions are produced or consumed - [MOTION] Add text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00191.html > regarding MTI Encryption to conformance document - [VOTE] no objections, passes > > (c) Sections 8.2 and 8.4 as MTI > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00194.html > > - Prateek: was discussed on last week's focus call - these sections define attribute name format identifiers and consent identifiers - notion is that all of these are MTI wherever relevant - Scott: similar in spirit to Section 8.3 - whatever "support" means - similar to situation in SAML 1.1, effectively but not formally MTI - Rob: just want to be clear on impact to implementations - [MOTION] Accept text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00194.html > - [VOTE] no objections, passes > > (d) MTI security algorithms > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00214.html > > - Frederick: repeats what is said in XML-Enc and XML-Sig, but also requires Excl C14N, some encryption algorithms, etc - Hal: I thought we already required Excl C14N - Scott: has been a should - Frederick: suggests modifying proposed text to eliminate MTI requirement for Excl C14N - Frederick: DSAwithSHA1 is required in XML-Sig, but no one appears to use it, so we should say that we're NOT requiring it, so that if XML-Sig changes, implementations will be clear that it is not needed for SAML - [MOTION] Accept text from < http://lists.oasis-open.org/archives/ security-services/200408/msg00214.html >, with removal of MTI requirement for Excl-C14N - [VOTE] no objections, passes > > 6. Discussion on list > > (a) AssertionConsumerServiceIndex vs. AssertionConsumerURL > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00200.html > > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00223.html > < < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00237.html > > - Scott: the Index and URL were intended to be mutually exclusive, so we can add text to that end - could have formed these in schema using a choice, but would have created long names - Prateek: ok with just adding a sentence to spec and leaving schema alone - [MOTION] Add text to line 1905 of core making ACSIndex and ACSUrl mutually exclusive - [VOTE] no objection, passes - Scott: Conor made a related suggestion that signing the AuthNRequest can also create the necessary trust - thinks this is a good comment to add, editorially - [MOTION] Adopt text similar to Conor's < http://lists.oasis-open.org/ archives/security-services/200408/msg00221.html > in core - [VOTE] no objection, passes - Scott: also coming out of this discussion is use of recipient attr to prevent certain attacks - SAML 1.1 used one way, and Liberty used another - current SAML 2 profile does both, which is overkill - Is the notion of recipient placed in bearer confirmation data still something we want to do, given that we have other mechanisms? - doesn't feel strongly about this - Prateek: isn't this all elective changes? there's no driving reason to change this - Scott: correct, not raising this as a problem, just a duplicity - Rob: doesn't see need to change - Scott: Is the recipient on the status response type still needed? < http://lists.oasis-open.org/archives/security-services/ 200408/msg00222.html > - We should either remove it (and add comparable mechanism to request abstract type) or say more about it - currently underspecified - prefers removing it - Scott will repost issue to solicit feedback from Liberty folks - > > (b) Comments on core-2.0-cd-01 > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00224.html > > - Paul: of the 4 points, they were all editorial and Scott has ideas on how to address all of them - Scott: correct > > (c) SessionIndex and Privacy Text > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00213.html > > - Paul: this thread has been going on a bit - originally was looking for caveat "only when privacy is a concern" - seems to have gotten agreement on that - discussion went on to mechanisms - Scott: points out that it's easier to say when NOT to do this - As for Conor's comments, this repeats discussion from a previous F2F - point is using AssertionID rather than SessionIndex - part of issue of using AssertionID was case of multiple Assertions - text for SessionIndex has been difficult to produce - Irving: can't remember particulars of F2F discussion, but suspects we had good reason to not just use AssertionID - and the small integer approach was intended to create blurring effect - [ACTION] Scott will review minutes of F2F regarding SessionIndex and make proposal addressing Paul and Conor's comments > > (d) Conformance requirements - SSL/TLS issues > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00216.html > > - Frederick: we should add comment citing FIPS equivalents - also, could add a common ciphersuite - Scott: would should move all this out of bindings and into conformance - Prateek: thinks this is editorial > > (e) Comments on profiles-2.0-cd-01 > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00235.html > > - Paul: the only non-editorial issue is within SLO profile - we give very little guidance to IDP regarding aggregating error info with other SPs, and propagating to initiating SP - Scott: JohnK, in ID-FF, don't you (as proxying IDP) stop on single failure? - JohnK: would have to look, but thinks so - Scott: probably need to tighten up our language - so, you would only get 1 error > > (f) Others? > - Frederick sent msg Thursday on encryption < http://lists.oasis-open.org/archives/security-services/ 200408/msg00228.html > - Frederick: point was there wasn't anything to say in these areas - need to review Tony's mention of a posting to WSS - everyone needs to review this, particularly those w/ experience implementing XML-Enc - would like Tony to explain his thoughts on this - [ACTION] Rob to contact Tony regarding XML-Encryption thoughts - Rob: Charles has posted drafts of Implementation Guide - need everyone to review - Prateek sent out solicitation for virtual interop > > 7. Open AIs > > #0193: Minor fix for Schema Encoding > Owner: Scott Cantor > Status: Open > Assigned: 31 Aug 2004 > Due: --- > Comments: > UTF-8 vs. US ASCII encoding > Scott Cantor to make proposal. > - [MOTION] Change declarations in schema files from UTF-8 and US ASCII - Irving: resists - Scott: would rather remove the declaration, but if not, would prefer more efficient form of US ASCII - Eve: resists also, as UTF-8 is more 'normal' - Scott: withdraws motion - Rob: need to fix schema dce files, so they can be viewed in browsers - CLOSED > > #0192: Propose changes to X.500/LDAP Attribute Profile > Owner: Bob Morgan > Status: Open > Assigned: 31 Aug 2004 > Due: --- > Comments: > < http://lists.oasis-open.org/archives/security-services/ > 200408/msg00180.html > - RLBob: in process > > #0160: Separate Privacy concerns language from Element/Attribute > descriptions > Owner: Prateek Mishra > Status: Open > Assigned: 30 Apr 2004 > - no update > > #0158: Propose changes to definition of Federation in glossary > Owner: Prateek Mishra > Status: Open > Assigned: 30 Apr 2004 > - no update > > #0176: Provide sequence diagrams for profiles > Owner: Jeff Hodges > Status: Open > Assigned: 23 Jun 2004 > - CLOSED > > #0123: Obtain MIME type registration for HTTP lookup of SAML > Owner: Jeff Hodges > Status: Open > Assigned: 13 Feb 2004 > - Jeff: in progress - should have done in time for 2nd CD > > 8. Any other business > - Rob: Next week's call is a focus call - planning to return to weekly formal calls after that - in posting doc changes, need to keep all change history relative to CD 01, so they can be all visible in CD 02 > > 9. Adjourn > - Adjourned ---------------------------------------------------------------------- Attendance of Voting Members: Hal Lockhart BEA Rick Randall Booz Allen Hamilton Gavenraj Sodhi Computer Associates Paul Madsen Entrust Carolina Canales-Valenzuela Ericsson Dana Kaufman Forum Systems Irving Reid Hewlett-Packard Company Paula Austel IBM Maryann Hondo IBM Michael McIntosh IBM Nick Ragouzis Individual Scott Cantor Internet2 Bob Morgan Internet2 Prateek Mishra Netegrity Forest Yin Netegrity Frederick Hirsch Nokia John Kemp Nokia Senthil Sengodan Nokia Cameron Morris Novell Scott Kiester Novell 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 Bhavna Bhatnagar Sun Microsystems Jeff Hodges Sun Microsystems Eve Maler Sun Microsystems Emily Xu Sun Microsystems Mike Beach The Boeing Company Attendance of Observers or Prospective Members: Abbie Barbir Nortel John Hughes Membership Status Changes: none -- Steve Anderson OpenNetwork
← Prev in month
← Prev in thread
Next in thread →
Next in month →