[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
Paula Austel IBM
Derek Fu IBM
Kelvin
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
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
Phillip Hallam-Baker VeriSign
Maneesh Sahu Westbridge Technology Attendance
of Prospective Members or Observers
none Membership
Status Changes
Ramanathan Krishnamurthy
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 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 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: 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: 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]