OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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



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


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



10. Adjournment

Adjourned at 11:58am EDT



Alan Geller
Advanced Web Services


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