[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wss] Minutes from September 7 meeting (corrected)
|
[updated with correction from Frederick Hirsch]
Minutes for the 9/7/04 teleconference
1. Call to order, roll call Alan Geller - minutes Steve Anderson - roll call
Attendance of Voting Members Gene Thurston AmberPoint Frank Siebenlist Argonne National Lab Hal Lockhart BEA Corinna Witt BEA Thomas DeMartini ContentGuard Sam Wei Documentum Tim Moses Entrust Dana Kaufman Forum Systems Toshihiro Nishimura Fujitsu Kefeng Chen GeoTrust Irving Reid HP Kojiro Nakayama Hitachi Paula Austel IBM Derek Fu IBM Kelvin Lawrence IBM Mike McIntosh IBM Anthony Nadalin IBM Nataraj Nagaratnam IBM Don Flinn Individual Bob Morgan Internet2 Kate Cherry Lockheed Martin Paul Cotton Microsoft Vijay Gajjala Microsoft Alan Geller Microsoft Chris Kaler Microsoft Richard Levinson Netegrity Prateek Mishra Netegrity Abbie Barbir Nortel Lloyd Burch Novell Steve Anderson OpenNetwork Ben Hammond RSA Security Rob Philpott RSA Security Martijn de Boer SAP Blake Dournaee Sarvega Coumara Radja Sarvega Pete Wenzel SeeBeyond Jeff Hodges Sun Microsystems Ronald Monzillo Sun Microsystems Jan Alexander Systinet Symon Chang TIBCO John Weiland US Navy Phillip Hallam-Baker VeriSign Maneesh Sahu Westbridge Technology
Attendance of Prospective Members or Observers none
Membership Status Changes Ramanathan Krishnamurthy IONA - Requested membership 9/3/2004 Jerry Schwarz Oracle - Lost voting status after 9/7/2004 call Nazrul Islam CommerceOne - Lost prospective status after 9/7/2004 call
2. Reading/approving minutes of last meeting (August 24th) Unanimously approved
3. Administrivia Kelvin - we've completed run out of phone call sponsors. if anybody would be prepared to sponsor an upcoming call please send him an email off-line. Martijn de Boer, SAP - would like more notice; would like the TC to keep a list of upcoming calls and sponsors Kevin - he gave notice two weeks ago; each meeting notice at OASIS has the sponor in it
4. Public review discussion/feedback Chris - we are now closed Kelvin - only comment is from August 27th, "Great job, now finish it" Chris - would like to get an endorsement from the SAML group Rob Philpott - thinks we're OK without anything Chris - next step is to re-affirm the current versions and then decide how to move forward; a 2/3rd majority is required Pratik - Moved that the TC approve the current SAML draft as a committee draft Jeff - Second Mike Macintosh - Moved that the TC approve the current REL draft as a committee draft Tony - Second Tony - (friendly amendment) Moved that we combine the two motions into one so we can do one vote Jeff Hodges - Objects Kelvin - so let's vote SAML vote: no objections, approved unanimously REL motion: no objections, approved unanimously 40 out of 54 voting members in attendence Chris - we need to decide how to move these forward with OASIS. There a are a couple of things we could do: send each of these individually; send them as a unit; bundle them with 1.0 errata, etc. OASIS has requested sending large bundles in the past; we're not sure why. We're also not sure how these profiles bear on 1.1; we need to have that Rob - To bundle with updates would push things back a month or two. Chris - are either of them dependent on text changes in 1.1 Ron - we talked about 2 things for SAML, one of which may have gone to errata (coding type for key identifiers) Chris -- wanted to get the sense of the group; there is a current work item to change "bas64 encoded" to "set by profile". He is a bit worried that the current spec says "must be base64" and so doesn't match SAML profile. Ron - that information was generally unspecified before. THe SAML token profile is a new use of key identifiers so new code will be written to handle it. Chris - someone who has written a WS Security parser based on 1.0 might have code that assumes that the key identifier is always base64 and if that code encounters something non-base64 it might fail Ron - the spec says that base64 is the default, not required Chris - but the SAML profile says the default is profile-specific Ron - the current behavior is an error in the core spec Chris - agrees Ron - so is this an errata or a function change? Chris - agrees that this is exactly the issue Paul Cotton -- confused about discussion on what's an errata and what's not; do we believe that the core spec is broken here CHris - yes Paul - Do you have a proposed errata to fix it? Chris - we have a proposed change Paul - Do we need to make this change to allow people to build SAML token processors? Would it cause people to change their core code? Chris - Asking the TC, is this a functional change or errata? Paul - Errata should be kept to the minimum; additions go in a doc change; if the spec is truly broken, though, it should be fixed ASAP Chris - the spec is broken if the key identifier can't be base64 encoded Hal - We're confounding the question of whether code changes will be required with whether or not this is errata, and confounding that with what to do with the SAML profile Chris - But wouldn't it be wrong to send on a profile that doesn't work on the published spec? Hal - not necessarily Hal - I tend to agree that it's not errata, but I tend to agree that we should send it (SAML profile) on Chris -- the BSP is not blocked on these, right? Paul - right; they've worked aggressively on this Chris - we need to get a motion on the table to decide whether the change (key identifier encoding) is errata or functional change, and then another to decide how to move forward Ron - the way key identifiers are described today in the core document requires unnecessary processing Rob - the core document doesn't make the SAML profile unusable, does it? Ron - the SAML profile says you don't need to specify an encoding because the key identifier isn't encoded, the core says the default encoding is base64 Tony - we're broken with 1.0 Ron - the core definition of key identifier has an errata in it because it specifies an arbitrary encoding even when there's no value to it Chris - I agree we should remove the requirement, the question is whether this is an errata or a functional change Paul - why can't we adopt the errata and have the SAML profile point to that errata? Chris - the errata is non-normative; we could add it to the SAML profile and vote it together as a unit Paul - don't understand the notion that errata is non-normative Chris - we want to only point to approved specs; errata is not voted on by OASIS membership Ron - Hal, why do you think this isn't errata Hal - I thought I was echoing the concensus of the call Ron - I'm not trying to put pressure on you; I think we have an extensibility problem with the way core is defined Steve - We are referencing SAML tokens using a Key Identifier and the SAML token profile defines a value type that this is a SAML token ID and core only defines a base64 encoding type Ron - SAMl could have defined an encoding type "do no encoding" but instead decided to ask core to change to not require encoding Steve - Had we realized this earlier on, we could have defined a new encoding type and not had a problem Ron - we would have had to define an encoding type that sais "do nothing" and we discussed that in email and on this call and it was felt that core shouldn't require encoding Steve - but now we have this timing problem Broad discussion restating the above points in other ways Ron - we could change SAML to add a new encoding type that we would remove later, but that seems wrong Chris - any suggestions on how we should move forward? Ron - it would be best if we could have new versions, but it's most practical to clarify in errata what the purpose is of encoding types; also, shouldn't each profile point out the existence of the errata Rob - doesn't each spec point out the existence of the errata? Jeff -- there's a pointer on the cover page of the core spec to the errata location Rob - Steve brought this up, shouldn't there be a pointer in the token profiles? Chris - that's a great idea and we should do that no matter what Steve - what I meant was add text to the SAML token profile that the token profile depends on the core errata document Steve Anderson - move to make this clarifying change with regard to no encoding type on key identifiers in the SAML token profile with the intent of approving it as committee draft\ Ron - the SAML token profile says "the key identifier MUST NOT have an encoding type attribute and MUST be encoded as xsi:string" Steve - the SAML token profile should say that this is based on an errata change to the core spec Ron - take whatever we would have sais in 1.1 and put it in the errata instead Chris - this is issue 290; TOny, is it in 1.1 yet? Tony - this is in the next version of the spec, it hasn't been published yet Chris -- can you send around that text? Chris - path: get text mailed around; agree on it; vote that in as a new version of errata; in parallel vote in new text in a new version of the SAML CD; then move forward with a vote at OASIS Ron - he sent around a suggestion to the TC in email Steve - move the plan as described by Chris Ron - seconded CHris -- Steve, can we have a roll call? Steve - should we see if we can have a unanimous consent first? Chris -- any objections? Vijay - yes Discussion around timing: goal would be to vote new SAML CD at next call Steve - roll call: 22 yes, 3 abstain CHris -- the motion passes; we have a plan; let's get this closed before the next call Ron - sent the text change for SAML profile
5. Errata status Tony - uploaded the latest errata as of last night but hasn't seen it on the OASIS site yet CHris - can we get the wording done and be posted in the next couple of days? Tony - yes Chris - can it be ready for viting before Monday so we can vote before the next call? Tony - yes Chris - Will the SAML token profile be ready for Monday? ROn - yes Chris - we need a version of REL before Monday Thomas - yes
6. Status of other profiles SwA: Frederick is not on Dana Kaufman - SwA - draft 9 at the end of last week; working on clarification of items on the issue list; there will need to be at least a draft 10 to fix some of the issues Kerberos: TOny - no update
7. Issue list review Issue list 48 posted
Pending issues: Issue 282: pending Issue 290: done in 1.1 (needs to be posted); needs to be copied to errata; Tony would like to agree on the errata text before he puts the text into the core document 298: pending 309: Frederick fixed in the SwA profile; text in the core may need to be changed; pending 312: closed 313: closed 314: closed
New open issues: 321: Pending 322: Closed 323: Closed 324: Still open 325: Still open 326: Still open
Old open issues: 67: Closed; Hal has sent around a document. 310: Still open; Vijay will have a new proposal in the next couple of days 315: Still open; Hal posted something yesterday that hasn't shown up yet 317: Pending; Editors should put this on the queue to put into a 1.1 working draft 318: Pending; Hal raised the point that the glossary calls a token something that contains claims, but now we're talking about a token that just contains a key -- but we need the functionality as a practical model; Ron said that this seems like very common functionality and should be part of core rather than a profile, just "how to use symmetric keys"; action to editors to incorporate this into a future draft of core. 319: Pending; There was a proposal from Eric Gravenguard (sp?) related to this in the past; we should compare his proposal to the current one; Vijay has the action item to do this comparison 320: Still open; Dana to get status
8. Interop planning status (Kerberos, SwA) SwA: Blake Week of 10/24 or 11/15; looks like 11/15 will get more people, 10/24 will get 2 or 3 less 3 scenarios chosen 4th scenario will be added for encrypted headers Chris, Tony: it would be nice to do both 10/24 and 11/15 to get started as early as possible, to unblock BSP, etc. Can we try to do a "pre-interop" on 10/24 and then the full interop on 11/15?
Kerberos: Alan No update.
9. Other business None.
10. Adjournment Adjourned at 11:58am EDT
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––- Alan Geller
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]