[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
with " 309:
This is just a correction for the minutes, the issues list requires no correction.
regards, Frederick
Frederick Hirsch Nokia From: ext Alan Geller [mailto:ageller@exchange.microsoft.com] Sent: Tuesday, September 07, 2004 2:02 PM To: wss@lists.oasis-open.org 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]