RE: [wss] Minutes from September 7 meeting

There should be a correction for pending issues in the 
minutes for 7 Sept - regarding issue 309:

 

Replace 

"

309: 
Frederick fixed in the X.509 
profile; text in the core may need to be changed; pending"

with

"

309: 
Frederick fixed in the SwA profile; text in the core may need to be 
changed; pending"

 

This is just a correction for the minutes, the issues 
list requires no correction.

 

regards, Frederick

 

Frederick Hirsch

Nokia

From: ext Alan Geller 
[mailto:] 
Sent: Tuesday, September 07, 
2004 2:02 PM
To: 
Subject: [wss] 
Minutes from September 7 meeting

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 X.509 
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 
Advanced Web 
Services