[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes, April 15,2003 Teleconference
Attached are the minutes from the April 15, 2003 teleconference. New action items from the minutes: ACTION: Jahan - analyze meta data issue, including Liberty 1.2 draft, write up and publish to list. Plan for discussion on call in 2 weeks. ACTION Chairs to publish proposed timeline to list. ACTION Eve - pose question to SAML Dev regarding proposed assertion id change ACTION - Scott and Frederick to revise signature note text. ACTION - Scott - post question on list regarding protocol/assertion issue ACTION - Eve - section on versioning needs update ACTION - Rob will send message to Phill and SAML Dev to ask if RespondWith used and if so how. Can it be deprecated in 1.1 and removed in 2.0 would you care? ACTION - Scott to improve language around AuthorityKind Votes from the minutes: Motion accepted (unanimous): The SSTC accepts the submission from HP, SUN, RSA and Nokia, of the Liberty Alliance Version 1.1 specification (and forthcoming errata documents), as described in http://lists.oasis-open.org/archives/security-services/200304/msg00072.html for incorporation as appropriate into the SSTC's on-going and future work. Motion accepted (unanimous): Vote to accept text to change versioning text in core http://lists.oasis-open.org/archives/security-services/200304/msg00000.html regards, Frederick Frederick Hirsch Nokia Mobile Phones
Minutes April 15, 2003 SAML Teleconference 1. Role Call --------------------------------------------------------------------------- Quorum achieved. 2. Minutes accepted from last call. ( April 8, 2003 ) http://lists.oasis-open.org/archives/security-services/200304/msg00055.html --------------------------------------------------------------------------- 3. Discussion and Voting: (a) Letter of submission of LA 1.1 specifications to SSTC --------------------------------------------------------------------------- http://lists.oasis-open.org/archives/security-services/200304/msg00072.html Proposed motion: The SSTC accepts the submission from HP, SUN, RSA and Nokia, of the Liberty Alliance Version 1.1 specification (and forthcoming errata documents), as described in.. http://lists.oasis-open.org/archives/security-services/200304/msg00072.html ..for incorporation as appropriate into the SSTC's on-going and future work. --------------------------------------------------------------------------- Jeff - please let us know if any question, letter should cover all of Oasis requirements for submissions. Jahan - does this mean Liberty will stop specifying further and hand it over Jeff - Want to drive convergence between this portion of Liberty (1.1) and SAML. Yes, on this portion of Liberty. V1.2 will be announced, intent is also to contribute those formally. Drafts are available today on Liberty site. People who participate in both venues (Liberty and SSTC) should ensure proper coordination occurs. Prateek - we should acknowledge submission in this motion, received as requested, plan to do something with it. Jahan - motion Irving - seconded. Hal - not required to accept submission, just like any other submission. Change from what was policy in November. Motion passed with unanomous consent. (b) Impact on SAML 1.1 --------------------------------------------------------------------------- http://lists.oasis-open.org/archives/security-services/200304/msg00085.html Prateek - 1.1 has been cleanup, as well as missing pieces, including based on last years interop Particularly, Browser site first flows, meta data proposal. What should SAML 1.1 be? Narrow to cleanup and clarifications? What should we do with extensions? Hal - Two proposals in question - champions should look at germaine Liberty portions and make a recommendation if it looks like Liberty adoption solves problem, if so adopt the Liberty solution, otherwise defer to 2.0 Scott - cannot adopt liberty in SAML 1.1 timeframe because of differences. Signifant value of putting proposals on table for SAML 1.1. Will there be divergences when we reconcile with Liberty. What is proposed should be consistent Jahan - metadata should go in 1.1, very concise Scott - metadata changed considerably between liberty 1.1 and liberty 1.2 - placeholder in 1.1 Rob - Is metadata for entire liberty functionality or federation framework? Scott - integrated, federated required Prateek - main concern at messaging, product level - consistency of SAML 1.1 and 2.0. Certain flows from use case document have been implemented already - example of risks Hal - should be ok to extend SAML, designed for that. Two principles: where SAML and Liberty do same thing, should converge. Shouldn't do new things now we should undo. Can do part and add more later, e.g. data structure that can be extended. Rob with respect to metadata Hal - not an opinion, needs to be evaluated Scott - Significant difference between Liberty 1.1 and 1.2 Hal - is Liberty going to submit 1.2. Should we wait for 1.2? Jeff 1.2 specs are available on the web, so we can work with them. They are very stable drafts, Liberty is soliciting feedback, but they should not change much. Rob - how long? Hal - 2 weeks for members, then 2-4 weeks public review. Liberty versioning is confusing. Jahan - we have nothing for metadata now, should have something sooner. Jeff - work I did and Prateek took leverages Liberty 1.1 metadata work. Needs revision and further work. Rob - will depend on schedule. Need dates to finalize 1.1 work. ACTION: Jahan - analyize meta data issue, including Liberty 1.2 draft, write up and publish to list. Plan for discussion on call in 2 weeks. defer decision on what to do with SAML 1.1 until the analysis done. Scott - proposal in SAML context, GET profile differences from Liberty, not opposed to defer until SAML 2.0 Jeff - SSTC need to finish 1.1 as soon as possible, submit for Oasis wide approval (monthly calendar, not quarterly, 1st of month),... Prateek - April end goal to converge on committee spec Scott - work on 2.0 can begin quickly Rob - probably cannot get metadata into 1.1 by end of April Jahan - will do what I can in week Jeff - need to have last call in committee - June 1 submission either way. Scott need public review Jeff - working group last call was 2wks last time - need to examine Oasis process. need detailed schedule on last call, need to allow time to revise the specifciation. Should look at the older mail messages and compare to current process. ACTION Chairs to publish proposed timeline to list. Hal Submission is 15th of month, public review prior, committee spec, IPR etc all before. Jeff - need to get through reviews and specifications ready to submit. At that point most of committee can focus on 2.0 as chairs continue the process. Eve - remember publicity, dee shure Hal - need to allow time to revise specification, have vote. Need 3-5 days interval. Rob - public review period must be 30 days discussion of what public review means. Jeff - can have concurrent last call and public review. (c) Text for DSIG core change proposal Scott Cantor --------------------------------------------------------------------------- http://lists.oasis-open.org/archives/security-services/200304/msg00075.html Proposed motion: vote to accept text Scott - Frederick comments mostly on original 1.0 text, most seem reasonable. Substantive comments need to be discussed. 1) other signing techniques beyond XML Signature, e.g. S/MIME. Should it be removed? 2) Canonicalization escape cause, allowing profiles override rules, probably not necessary to make it simpler - may make it harder. Eve - Explicitly say "Unless profile says otherwise..." Eve - need to discuss ID attributes Prateek - voted on inclusion of id attributes Scott - not on wording Eve - do not want to rely on fonts, merging is a good idea. Irving - look at SAML dev Prateek - asked on list Irving - did not ask about assertion id change. (Using UUID not valid XML id) ACTION Eve - pose question to SAML Dev regarding proposed assertion id change Prateek - some more work to do, delay vote... Frederick - should we discuss alternate signature techniques, make a decision? Issue is context of signature that must be maintained... ACTION - Scott and Frederick to revise signature note text. (d) Text for change to versioning text in Core Scott Cantor --------------------------------------------------------------------------- http://lists.oasis-open.org/archives/security-services/200304/msg00000.html Proposed motion: vote to accept text Scott - another revision incorporating suggestions from Eve. Ready to vote. Highlights: kept language about rules for evaluating version differences defined specification set version - reflected in non-normative schema version attribute, (can distinguish schemas apart from namespace) - asssertion and protocol versions in messages (major,minor versions), processing rules similar to before disconnect this version from the namespace version - continue to include version indicator in URI for namespaces, include major,minor version of specification when namespace introduced goals to maintain namespace stablitity and compatability. As Eve mentioned, two versions: specification and namespace Irving - Yet another way for things to break? Scott - things could break before, now clearer when and how things can break. Changes to existing namespace, schema document referencing same target namespace Irving - need to be able to examine schema, issue of revising namespace in this case. Scott - major decision to change schema in incompatible manner Irving - reasonable to expect v 1.1 request/response to return version 1.0 assertion in response? We discussed, no decision made. Scott - no significant processing rules to make this possible, as long as namespaces don't change. Irving - old assertion fit with new assertion Scott - unless change to id attribute, breaking backward compatability. Eve - importing assertion schema into protocol schema Irving - question of whether to introduce constraint to have assertions and protocol be same version of spec Scott - possibly long lived assertions Irving - example, equifax report... Irving - implementers have to figure out what to do, Scott - 1.1 code can process 1.0 assertion Irving - longer term issue, e.g. major versions Prateek - Is a change needed? Scott - does saying "don't do that" violate use cases? Saying you can do it, doesn't mean you can. Irving = either add normative text saying must match or processing rules if they don't, especially how to send an error. version mismatch. Advice, evidence are cases where issue arises Scott - this is additional language so we could vote on this and have a separate issue with subtleties ACTION - Scott - post question on list regarding protocol/assertion issue Scott =motion Frederick - second Motion passed. ACTION - Eve - section on versioning needs update Jeff - Thank you for nice work that required much thought. 3. Action Item Review: --------------------------------------------------------------------------- #0018: Describe degenerate RespondWith cases Rob Philpott Stays OPEN. #0013: Request use of WS-Trust for CC proposal Maryann Hondo Rob - Submitted email to authors asking to arrange concall, after RSA conference. Still OPEN. #0009: Propose text for PE-9 Rob Philpott Text Sent to List: http://lists.oasis-open.org/archives/security-services/200304/msg00084.html Eve: Either QName for element or QName for type, hence problem. New text may be backward incompatable. Scott - will it schema validate without xsi:type Eve - must be substitution group Scott - should be possible to pass element name in message Jeff - Liberty is not using it. v1.1 had RespondWith removed. Eve - Deprecate in 1.1, remove in 2.0 replaced with three query types. Jeff - ask Phill Hallam-Baker if there are use cases that use RespondWith, if so, how. Rob Mail should go to SAML Dev as well ACTION - Rob will send message to Phill and SAML Dev to ask if RespondWith used and if so how. Can it be deprecated in 1.1 and removed in 2.0 would you care? Still OPEN. also AuthorityKind issue. Scott - just says how it is characterized, but no processing rules, can get back different statement type... Rob - value of AuthorityKind MUST be of same type ACTION - Scott to improve language around AuthorityKind #0008: Provide text for PE-4 Prateek Mishra OPEN, Will provide text this week. #0004 Propose WSDL for Meta-data Prateek Mishra OPEN #0002 Attribute Authority Use-Case Rob Philpott OPEN #0020 Text for DSIG core change proposal Scott Cantor http://lists.oasis-open.org/archives/security-services/200304/msg00075.html Published, CLOSED #0021 Text to clarify use of base64 in FORM post profile Scott Cantor OPEN #022 Motion for inclusion of destination-site first flows in SAML 1.1 Prateek Mishra http://lists.oasis-open.org/archives/security-services/200304/msg00074.html Submitted text, CLOSED #023 Editorial Review of Glossary and Bindings Eve Maler OPEN 4. Other business Eve: any other changes to errata document - none obvious Rob: Sent mail to the list regarding patent license and process today. Meeting Adjourned. ---------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]