[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Baltimore F2F "raw" minutes all text, with newlines
just fyi & convenience (I hacked this up for myself and am just sharing)... Baltimore F2F "raw" minutes all text, newlines inserted, and day2 Actions file (which isn't on the website) -- otherwise they are as-sent by SteveA. JeffH
Minutes for WSSTC F2F, Wednesday 3 December 2002 Dial in info: +1 865 524 4287 #248770. Minutes taken by Steve Anderson ====================================================================== Summary ====================================================================== Votes: [NONE - QUORUM NOT REACHED] New (General) Action Items: [none] Issues List Action Items & Status Updates: - 3 - Ron to write up token labeling proposal, with help from Tony, BillC, FredH, Don - 4 - change issue owner to PhillHB - Chris to write up proposal - move to pending - 5 - change issue owner to PhillHB - Chris to contact PhillHB (done during session) - PhillHB agrees to link to 5 - move to pending - 22 - new issue: Kelvin to have document searched for inconsistencies - Tony to update definition of claim to be originating from an "entity", rather than a "client" - move to close pending vote (CPV) - 25 - had previously been marked postponed - 26 - Ron to get with Tony - 30 - Chris to get with Tony to document XPath-like notation - move status to postponed to next milestone draft (after interop draft) - 31 - move status to postponed to next milestone draft (after interop draft) - 38 - move to closed - 42 - move to closed - 48 - Kelvin to send email to Zahid to review - 50 - link to issue 4 & 5 - 51 - Tony to take example out in section 7.1, lines 664-669 - move to CPV - 52 - Chris to provide more text explaining the preferred key referencing mechanism in STR section, and send to list - Profile document editors to define what key names & key identifiers are with respect to their tokens - 54 - move to CPV - 55 - Chris to work with Tony to clarify line 222 - FrederickH to work with Chris/Tony to clarify dynamic XML schema description - 56 - Tony to add appendix, and get with Rob to ensure types are documented - move to pending - 57 - closed, withdrawn by Rob - Chris to provide clarification of use of direct references vs. key identifiers - 58 - close, pending Rob's verification - 61 - FrederickH to get with Tony to integrate his text ====================================================================== Raw Notes ====================================================================== > > Agenda: > > 1. Roll call > - Attendance attached to bottom of these minutes - Quorum NOT achieved yet > > 2. Review minutes from previous meeting (12/03) > < http://lists.oasis-open.org/archives/wss/200212/msg00037.html > > - deferred until quorum reached - > > 3. Volunteers for minute takers > - Responders - Steve - MaryAnn - Frederick - Bill Cox > > 4. Actions/Issues list > - 3: Proposal to Label Tokens to Indicate Their Semantics - been open for some time - Tony: proposal on table now is to put label on a STR, rather than the tokens themselves - one token may be used for multiple purposes, so labeling it in a wrapper provides flexibility - Ron: agrees that use of token has to be labeled - question of using an attr vs an element to carry the labeling - also, question of putting multiple labels on a STR - in the case of a signature, there can be properties, which can carry labels - these are usually used in a signature to refer to a key - [extended discussion] - mention of SenderVouches from SAML as a use case - JerryS: describes use case of taking client cert from SSL channel and pass it on - but no signature with that cert is possible, because the intermediary that is passing the cert on doesn't have the private key - Hal: solution is to create binary token representation of that client cert, add it to the message, and add a STR to it with a label describing it - Ron: the labeling of the STR does solve a large portion of the problems, but data references would solve a different set of problems - doesn't appear to be possible without breaking DSig - John: so what do you want to do about trying to add label when ds:KeyInfo is used (rather than STR)? - can't label ds:KeyInfo because it's a closed schema - Chris: ds:KeyInfo has an open content model, but closed attr model - so to extend it, an element must be used (rather than an attr), in which case, you might as well use a STR - Kelvin: are we getting to a proposal? - Ron: if you have keyInfo, how do you add label? whatever solution can be constructed for that will also solve adding a label to a data reference - Chris: since an element would have to be used, might as well use STR - Ron: doesn't think that use of STR is consistent - John: looking for specific proposal - discussion difficult in this setting - Volunteers to work on a proposal: Ron, Tony, BillC, FredH, Don - [ACTION] Ron to write up token labeling proposal, with help from Tony, BillC, FredH, Don - Don: this is an important issue for implementors, to clarify semantic use of tokens - 4: Why is the token in the header, and not a child of KeyInfo? - PhilG: wasn't the owner - Ron: thinks it was PhillHB - [UPDATE] PhillHB as issue owner - Chris: background on this - XMLDsig is fairly closed schema - bigger driver was that outside of signature, you might want to use a token - therefore, need a generic wrapper - Ron: how do you reconcile case where ds:keyInfo is adequate - Tony: - Chris: another goal was to improve interop, but providing a simpler alternative to ds:keyInfo - this issue (4) is gating to issue (5) - Chris: proposes to move this to pending - [ACTION] Chris to write up proposal - [UPDATE] move to pending - 5: Within the KeyInfo, why not use a ds:RetrievalMethod? - [UPDATE] PhillHB as issue owner - dependent on issue (5) - [ACTION] Chris to contact PhillHB - Hal: not certain that there is a dependency between (4) & (5) - Hemma: originally, certain token formats were elevated, but current approach of using token profiles may make this issue moot - Ron: sees STR as a unification of keyName and retrievalMethod - unclear whether all cases that keyName covered by STR, and whether all cases that retrievalMethod covered by STR - remains open - 6: Will the authors of the roadmap submit it? - related to 9 - Kelvin: no news to report - still looking for a static URL to serve this up - 9: Approach authors to submit the App Note to the TC - related to 6 - no news - 10: Investigate interop fest at some later time - this is a placeholder for an interop event, which will be driven by getting out spec to interop draft status - 19: Core: Why is it necessary to special case a Username/Password POP token? - was pending, should be reflected in current doc - editors have not yet added - PhilG: aims for early next week, before next call - 22: Core: Should the spec preclude security tokens whose purpose is other than to convey or bind a key to an identity or entity? - was pending - Tony: proposal is to make this clarification - if we accept this, Tony can make this change - Ron: when he raised this question, intent was not to make this change, was just pointing this out - Ron: have made some changes to docs to fix this - discussion of "keys" to mean more than crypto keys, and to encompass attribute info (a la database keys) - Hal: so we're not precluding tokens that convey other than crypto keys, but we are precluding keys that convey other than attribute info - Ron: tokens are intended to represent claims, which can be lots of things - Ron: proposes we close this issue as to whether or not tokens are to be used for other than keys, since they are to be used for claims - Kelvin: proposes editors search - [ACTION] new issue: Kelvin to have document searched for inconsistencies - [UPDATE] close, pending vote - Ron: suggests that the "should" part of this issue be dropped - Hal: believes wording of claim being made by a client is incorrect - [ACTION] Tony to update definition of claim to be originating from an "entity", rather than a "client" - 25: Core: How can a Signature element occurring outside of the header be referenced? - Ron: was his issue - we postponed this - 26: Core: What does it mean to process a BinarySecurityToken? - Ron: hasn't completed this action - has circled many instances where this phrase is used in the spec - [ACTION] Ron to get with Tony - 28: SAML Binding: Include the use of the URI attribute (on SecurityTokenReference) from the SS TC submission - Ron: made this change 2 revs ago - needs Prateek or Don (whoever originally raised the issue) to review and approve - Prateek: has not reviewed, will do shortly - remains pending until Prateek reviews - [REVISIT] - 29: SAML Binding: Should there be a reference form that carries what amounts to a SAML assertion Query such that the sender does not need to have acquired the assertion (to be able to apply it to a request)? - Prateek sent mail to list describing usefulness of this - Kelvin: asks people to review while we're here - [REVISIT] - 30: How should XML be explained - Chris: hasn't seen strong push to change from what we currently have - Hal: would at least like a description at the beginning of what the notation is - John: proposes, at least for this rev, to not make big change, and in next draft, incorporate Hal's suggestion of documenting the notation - [UPDATE] move status to postponed to next milestone draft (after interop draft) - [ACTION] Chris to get with Tony to document notation - 31: Should use OASIS Namespace - use the XMLSOAP namespace for now, until OASIS comes to resolution - [UPDATE] move status to postponed to next milestone draft (after interop draft) - 36: In section 10.2.2, why not just specify that the <Created> element type be xsd:dateTime? - [REVISIT] - 38: line 238: Since this is a normative text, how "inappropriate claims" is defined here? - [UPDATE] closed, by virtue of Konstantin's review - 42: Line 1155: the meaning of "materially" is unclear - [UPDATE] closed, by virtue of Konstantin's review - 46: WSDL definitions - It seems to me that a stand-alone specification should just define the semantics of its elements. If an application wants those semantics, then the application WSDL should specify the header as being required. - John: proposes postponing this until after interop draft - BillC: concerned that we're pushing too many items out past interop draft - not opposing it for this item - [UPDATE] pending the QoP discussion - [REVISIT] - 47: - [REVISIT] - 48: - [REVISIT] - 49: - [REVISIT] - 50: - Ron: believes defining use cases of STRs would help - John: we already have an action to go do this - Ron: suggests leaving this open until those use cases are produced - FredH: are the STRs intended to be abstract (meaning, can't be instantiated, vs. concrete derivations of STRs) - no - Chris: should this be marked pending and linked to issue (4)? - Ron: prefers to keep this open until use cases are available - [UPDATE] link to issue 4 & 5 [JUMPING BACK] - 4: - assuming Chris does write up, this will be closed - 5: - Chris spoke with PhillHB, and he believes this is same as (4) - assuming Chris does write up, this will be closed as well - 51: - Chris: we could just take the example out - [ACTION] Tony to take example out in section 7.1, lines 664-669 - [UPDATE] move to closed (pending vote) - [REVISIT] - 52: - Chris: key identifier is some unique identifier for a token, which would be defined by the token profile - example of a hash of a X509 cert - least explicit reference of a key is key name - most explicit reference is via direct reference - key identifier falls somewhere in between - direct reference is much faster than processing key identifier - Ron: all for this, it just needs to be spelled out - Section 7.6 even describes a different type of ambiguity that can happen - [ACTION] Chris to provide more text explaining the preferred key referencing mechanism in STR section - [ACTION] Chris to send proposed text to list - [ACTION] Profile document editors to define what key names & key identifiers are with respect to their tokens - 53: - Ron: thought that PhilG's action to move username token text into its own profile doc obviated this issue - still open - 54: - multiple items in this issue - first 3 items were pending Don's review - Don: will review today - John: Don needs to go thru each item, and will open new issues for whatever still needs to be addressed - [UPDATE] move to closed (pending vote) - 55: - line 222 is point of contention around encryption - [ACTION] Chris to work with Tony to clarify line 222 - next sub item: dynamic XML Schema description - Chris explained intent of this in section 4.2 - FredH: last "may" on line 383 is still confusing - John: suggests FredH and Chris/Tony work out improved wording - [ACTION] FredH to work with Chris/Tony to clarify dynamic XML schema description - 56: - John: thought that W3C was working on an ID attribute, to be added in next ver of SOAP - so our ID may get replaced in the future - Hal: what is reason for having two schemas - Chris: things in utility schema are expected to be used outside this spec - Hal: if another group wants to use the utility schema, they won't want to go through our core doc to find descriptions (where they are scattered) - John: proposes putting documentation of utility items into an appendix, rather than in scattered chapters, with a forward reference at the beginning - Tony: counterproposal to maintain readability by keeping the documentation where it is, and to add an appendix describing these general utilities, referencing their locations back in the spec - Rob: there are some types in the utility schema not documented in spec, which should be added to appendix - [ACTION] Tony to add appendix, and get with Rob to ensure types are documented - [UPDATE] move to pending - 57: - [UPDATE] closed, withdrawn by Rob - new, related issue raised by Ron - related to use of direct references vs key identifiers - [ACTION] Chris to provide clarification of use of direct references vs. key identifiers - 58: - Rob will get with Tony to verify changes are satisfactory - [UPDATE] close, pending Rob's verification - [REVISIT] - 59: - Guillermo will call Thomas to see if he has verified changes - [REVISIT] - 60: - Guillermo will call Thomas to see if he has verified changes - [REVISIT] - 61: - [ACTION] FredH to get with Tony to integrate his text - [REVISIT] [JUMPING BACK] - 47: - still pending - 48: - Tony: done in latest draft - awaiting Zahid's review - [ACTION] Kelvin to send email to Zahid to review ----------------------------------------------------------------------- Attendance of Voting Members: Don Adams TIBCO Steve Anderson OpenNetwork Paul Cotton Microsoft William Cox BEA Martijn de Boer SAP Yassir Elley Sun Microsystems Don Flinn Quadrasis Peter Furniss Choreology Eric Gravengaard Reactivity Phil Griffin Griffin Consulting Frederick Hirsch Nokia Maryann Hondo IBM Chris Kaler Microsoft Yutaka Kudo Hitachi Guillermo Lao ContentGuard Kelvin Lawrence IBM Hal Lockhart Entegrity Solutions Monica Martin Drake Certivo, Inc. Prateek Mishra Netegrity Ronald Monzillo Sun Microsystems Tim Moses Entrust Anthony Nadalin IBM Andrew Nash RSA Security Toshihiro Nishimura Fujitsu Mark Nobles LMI Rob Philpott RSA Security Hemma Prafullchandra Verisign Rajesh Raman BEA Systems Jerry Schwarz Oracle Shawn Sharp Cyclone Commerce John Shewchuk Microsoft Frank Siebenlist Argonne National Lab Gene Thurston AmberPoint John Weiland Navy Attendance of Observers or Prospective Members: Lloyd Burch Novell Eric Cohen PwC Membership Status Changes: Joel Munter Intel - Withdrew 12/4/2002 Jeremy Epstein webMethods - Withdrew 12/8/2002 Hank Simon Lockheed Martin - Withdrew 12/9/2002 Takashi Kojo NEC - Withdrew 12/9/2002 Greg Carpenter Nokia - Withdrew 12/10/2002 Simon Godik Overxeer - Withdrew 12/11/2002
47 [still PENDING] 48 [ACTION Kelvin ….needs to be reviewed by Zahid before being closed] - schema was brought in line with document 49 [ACTION Kelvin ….needs to be reviewed by Zahid before being closed] - schema was brought in line with document 58- [PENDING] - Rob Philpot to review and let us know if they can be closed - Section related in 56 &57 Ron Monzilla When you use which reference when? Id References only have a role when the token is not present in the message Really need to define how the references are used. Chris…. Lets say SAML chose to make a token a type id The only way to do this would be to know the schema The purpose of id is to hardcode in the reference so you don’t need to process all The schema Key identifier points to an opaque value Key identifier has an encoding type Ron, Really unclear KL [action already taken….. tony and chris to write up the security token model] 58- [PENDING] Rob will verify against current edits 59,60 –[PENDING] Thomas not here, Guillermo to call Thomas and verifiy that changes made are acceptable 61 [PENDING] Frederick and tony to resolve the text and make proposal…. [ACTION-John] Request to start a new issues list Frederick and Phil Griffin will send new issues to list and these will be reflected post interop draft [ACTION- Tim] Review editorial explanations Tony has done Proposal to break for 20 minutes: John and Steve to sync up and update the issues list People who had actions to review ….should take the time to do that People who had actions to start discussions on new topics could do that now Resume after lunch Redoing the issues list CPV pending a vote 3- [ACTION to work on at F2F] Label of Tokens, Ron & Chris 4-5 CPV 6 Postponed to POST Interop draft 9 Postponed to POST Interop draft 19 Phil draft ---available after F2F 22 CPV 25 Postponed for this draft 26 [F2F ACTION] Ron and Tony 28 CLOSED …..changed to [F2F ACTION for Prateek, Rob, Don and Hal ] after discussion of SAML binding 29 CLOSED [prateek suggests closing (withdrawn) and opening a separate] 30 Postponed till POST interop draft 31 Postponed till POST interop draft 36 [ F2F ACTION for GROUP] change has been made GROUP to review 10.2.2 46 [F2F …post QOP discussion] 47 still open [F2F] 48 [ACTION Kelvin] schema updated 50 remain open 51 CPV 52 [ACTION Chris F2F] 53 remain open 54 [CLOSED….Ron to review and open new issues if there is anything else] 55 [ACTION F2F Frederick to work with Tony and Chris] 56 [ACTION f2f] Tony 57 [CLOSED] 58 [CLOSED] 59 Guillermo left a message for Thomas 60 remain open ….need Thomas input 61 [ACTION f2f] Frederick to work with Tony 62 [ACTION f2f] Tim ….to review with Tony Next agenda item: Review bindings SAML -04 review of Ron’s updates This document shows all the changes Changed some statements about IPR… pointer to the TC web page and the OASIS guidelines Philip provided an initial merging…..so some changes to intro… editorial change 3.1 Talks about semantic labeling…. how a relying party knows what to pay attention to …has to make some determination about signatures and processing .This was one of the sections in which changes were requested 3.2. this is one of the areas that brought up questions about references 3.3 Hal and Zahid need to review and comment on this 3.3.1 Don Flinn wanted to know if this is the way saml assertions will 3.3.2 Be included or whether or not they would be within another container element within the wsse: security element There are three ways to handle assertions. Within SAML the responder URL is not sufficient to get the element which is being referenced Jerry, even though saml is closed you could add an id by wrapping the element Question on whether there is something missing from SAML? Prateek, not an easy way to do this, part of the metadata for the query not part of the assertion itself We don’t have a good element/data reference for SAML (retrieval) Need a Reference form for saml for uniqueness and how to retrieve them…. The SAML identifier is a unique assertion….globally unique over time and space Identifies the contents…there seem to be different references when the assertion is in the header use and when you need to be able to retieve it Why doesn’t a security token reference carry a key identifier? [part of the ongoing discussion of labeling] Chris Kaler For saml define that the key identifier is the assertion id Advocate this model because its les ambiguous. Ron 3.3.2 This shows how to reference within the header using a uri as a fragment identifier The binding is broken Lots of discussion about url fragments, whether or not saml assetions can Be reflected by a fragment identifier…. Key thing is that this is a URI not a URL … Want to go back to the wrapper model…. There is some xml assertion and I want to create a reference to it. We have assertions ids on saml assertions But don’ t have a way to represent an access to the assertion in the document Ron I tried to do that ……. Tony suggested an XPATH or an XPOINTER Does it give us an opportunity to get to the resource? This is the remote case…. First there is an authority at a URI….. Do a wrapper and get a pointer to the authority…. Security Token Referenc is that wrapper…. Jerry You need an element that specifies all the information to get the saml assertion Ron, If I do that for saml I will need to do that for every security token type. Rob Philpot, In order to handle the SAML case, might want to look at the saml authority binding Proposal to take this discussion offline and have the SAML people caucus and come up with a solution. In most cases a key identifier is used to look up the referenece…. Chris, There are two cases: Potentially abstract URI And a local identifier Normatively it’s a URI Jerry, Want to implement STR ….there is no indication that it is a saml reference to know whether its document based or retrievel type to have to go to the SAML document to understand how to process the reference, it seems like the wrong model Chris Processing model is there and extensible Jerry, if its not handled at the base level, Proposal Should there be in the STR a way to retrieve a token or is that a token specific mechanism? In general a URI is self describing… Do we need to identify if it’s a document based reference model and another protocol reference model? -------------------------------------------------------------- Proof of Posession Confirmation mechanism was removed Assertions indicate whether you must confirm or not Comments requested but none received. In looking at this you could confirm this by other means…. Tim, Are you disqualifying the bearer approach? Ron, Sender vouches can be because I recognize them Or it is a bearer case Tim, Message and an assertion within assertion is an identity and the whole thing must be signed and the receipient can infer the identiy is associated with the message because it is signed. Prateek, We are now trying to figure out how to attach saml assertions to SOAP flows, First case sender is the subject Second case is the sender vouches. BREAK Ron Have not allowed for a bearer case Within the assertion, the authority says how you must confirm it there are two methods documented here (saml has others) …. The holder of key is different because the authority is indicating who should be allowed to make the assertions The document is prescriptive, maybe we need to loosen the language There is nothing in the saml core that says whether or not you need to sign. Hal Bearer was a kludge, let’s not perpetuate it. Prateek Agree Hal Assume in this environment people will do something better Prateek, Could we investigate weakening the language …might end up causing problems. Ron, The choices we’ve given you mean you always need to have assertions signed and is this a problem for SAML….should we support a case for sender vouches? Issue to have people validate that this doesn’t validate the core. Go back to Holder of Key….. one of the things enabled by SOAP and SAML with signatures….. Where is it that says that you must sign the assertions? the core when describing sending saml messages through an intermediary does say that …browser profile does have a requirement but that is not part of the core Don Flinn asked how does this relate to the canonicalization rqts of the core? Receiver [Section 3.4.1.2] Knows which assertions it needs to process …make it clear you should validate Assertions….nobody can make you do that….should this be a MUST? [Line 305 ] proposal “ Message receiver must validate signatures on the assertions and must not accept them if they fail validation” Hal Do you want to say that all conformant applications do this? Make it a MUST…. You can disable the feature or implement another profile. This example was intended to show holder of key….. Line 395 remove extra quotes. Chris Volunteers to make sure that the schema examples in the documents will be validated….all major drafts will have this done…. Gene [example 3.4.2.3] Core Document says As you add security tokens, you should prepend …this does not follow the processing rules….Should signature be prepended? Ron Where you have signature block ….there is a signature in the saml assertion and is it a signature over both the assertion and the body? Prateek Then you are subject with a substitution attack. Ron There is a case where if your’re self authorizing…. in holder of key you are not self authorizing…. Ron [ACTION]Change to the example, in the signed info include a reference to the message body [ACTION] In security considerations for an unsigned security token…..Tony might need to add some text for this risk. Tim, Do we have a single mechanism in the core to identify different tokens?…..it is implied that there is only one saml bindings/profile Profile is used to process a token type….. You can have one token which can be used in 3 profiles, You need to identify the profiles for versioning You may not need to support more than one profile [ISSUE] There are versioning issues for all of WS-Security [ISSUE] is there something in labeling which will help with the versioning? There are lots of critters here…..are we versioning profiles or tokens? Can a profile itself indicate what it supports? Is this a policy issue? [ACTION] open an issue we need someone to put together the text….Ron will volunteer to do this but not before the end of the meeting….. 3.4.2 line 435 change to MUST line 513 should not have the quotes lines 519, reference to body. Needs to be added to previous example bind the token and the binding together, 3 potential options SAML allow an id ( maybe for 1.1 ) 2 options for now that make sense for all tokens that don’t have an id in them XPATH Custom transform on the envelope Proposal to wrap all tokens with an id …. Make the reference a literal reference Or define an XML token [ACTION someone needs to write this up….Tony will draft for this F2F] Error codes Line 566 should be generalized Jerry, What if there’s more than one token and more than one error…. Fail when you hit the first error is the current processing model What error messages appear in the details in the soap fault? Ron, Are there security vulnerabilities in returning too much information? Then you could also have internationalization issues if this is text Rob, If you want that level of detail….you can create audit logs to keep that information on the server but you don’t send that information to the client. [ACTION for chris & Tony] 1) put text in the fault when you issue a fault you may include a security token reference 2) in security considerations do it carefully 3.6 Threat Model & Considerations Eavesdropping Is the idea that you could have multiple audiences? Yes and XML encryption allows you to take a symmetric key and distribute it to the recipients through an asysmetric method [ACTION for Ron, 621 sender signature, it should refer to this as integrity protection] we might want to chose a different emphasis mechanism [Rod……626-628, made consistent with ACTION above] Phil Put out an input document to allow XCBF to be used in ws security Defined an XML markup of two binary formats 1) bit map 2) biometric service provider x9.84 CMS pkcs 7 standards ASN 1 schema NIST has defined a framework for what biometric formats need to be These two fall under the framework Define a type which tells you whether it will be binary x64 armored Or an XML markup that is not tied to W3C schema but tied to the XCBF schema Describe how to translate between the XML and binary formats Propose to use this for authentication and distribution of biometric information Also add an optional biometric format to the id/password to supplement or replace the password in a multi factor authentication Request to support another binding document and phil has already volunteered to participate in the previous username profile document Phil has investigated and said there is no known IPR for the XCBF proposal What occurs in the header? It’s not used as a sole mechanism for authentication, but a second factor in an authentication Ron, This is similar to a claim but what is the proof of possession? Proposal to adopt this as another binding…. Will be tomorrow….. Monica will repost
WS-Security Minutes 12 Dec 02 9-11:30 ** Walkthrough led by Tony of new core document changes - posted last night --- Issue #3, label tokens Tony Nadaln: revision to document was that at line [676] added new optional Usage attribute to security token reference, taking a QName value. The default value is wsse:UsageBind. Jerry Schwartz/Ron Monzillo: does it mean anything? Chris Kaler: don't specify, if no attribute how would you describe the usage. Specifically stating default Ron always have this meaning for signatures Chris only doing a bind Hal Lockhart: what does within a signature mean Chris could be used not within a signature ACTION: change the wording from "assertion" to "claim" Hal - For originanating & intermediary tokens, how to label with usage, since it applies to both Chris; only means that it is default, can't combine with other label Ron: want other labels Chris: put out mechanism we have now, have team decide what we need to do Ron need affirmative value, not conflict Chris get rid of default, have team decide on QNames ACTION: Team will decide list of valid QNames, will leave mechanism in document. Hal: Clarification, can you have more than one Tony: yes Ron: this is how to label security token reference from signature. Bill Cox: Keep the table until the group puts something in. Chris: defining mechanism was core to issue, resolved. Subsequent issue is to define list of QNames Tony :why is table not acceptable Hemma Prafullchandra: keep it until we have improvements Hal: what does it mean with token with this label that isn't used for a signature, is it an error Or token with a signature, Tony this does not need to be the default, Ron what if token is by itself Tony remove defaultness, just one of many possibilities Rob make default - no usage implied Ron not saying more with UsageBind, doesn't add anything, Tony if parsing might want a default value ACTION: QNames to be defined later, TBD for new table entry STATUS: Closed pending vote, new issue on defining Qnames Chris post interop version issue Hal had original proposal ACTION - Add new issue to define QNames, Hal will start activity to define list --- Issue 26 process a BinarySecurityToken Ron wrote line numbers for edits, not given to Tony yet, view edit online, in 06 merged 8 Dec draft See lines 433, 511, 593,670 (also search for process | compliant) Frederick Hirsch can add general statement at beginning to state what processing means. Have put proposal on list, Rob Philpot ACTION: add issue for 434 all implementations must declare which profile they support ACTION: editors merge Frederick & Tim statement, place into document up front, add note in error section STATUS: Closed pending reviewed changes to be performed by Tony. Will have status Monday. Vote on tuesday, doc out sunday ---- Issue: 28 Prateek Mishra has written proposal for referencing SAML assertions from security header. Independent of id issue. Two parts: 1. use key identifier container defined in the token reference section as all SAML assertions have "key" ValueType saml:assertion containing Assertion IDReference. Impact on core - none Chris why using the element AssertionIDAssertion Prateek SAML encourcages this usage Chris moves to mixed content model. KeyIdentifier usually just has string under it, now can be string or complex type. Many tools break or are inconsistent with mixed content value Rob Philpot put ValueType saml:AssertionIdReferenence, removing AssertionIdReference element Chris default encding type is base64, need new encocding type xsi:string ACTION: editors add new encoding type for xsi:string to core document Prateek: Now extended form: Reference available from SAML authority Use saml:Binding: URI describing concrete protocol used by SAML authority saml:Location: attribute describes location of authority ACTION: SAML binding introduces use of the two attributes from SAML core - saml:Binding, saml:Location Jerry: sig outside header, must be able to process it there. Is this generic mechanism Prateek No security token references are limited to occur in security header. Chris can be used anywhere you want to reference a token use only defined for signatures but could be used anywhere. Signature SHOULD appear in security header. what is issue Jerry using library for sig, encryption with plugins for saml chris not appropriate to describe other usage models ACTION: editors add wording to document - unspecified what it means to use a security token reference outside of the security header Ron can this be used for a data reference, any cases when you don't need both binding and location Prateek - although only one binding is defined (http) need both [Ron presents use diagrams] Prateek core need id or XPath for signature References Chris SAML binding could define transform to get saml assertion for id Action Need to define a digital signature transform for dsig to enable remote saml token action Frederick: XML Sig SignedInfo Data reference to remote token, what does core define. Need to define transform to enable use chris vote at concall after folded into SAML assertion STATUS 28 pending, Ron sending out document by Monday morning, and vote ---- Issue #36 Created be dateTime? [1183] merged 8 Dec doc 10.2.1 creation. STATUS: Tony; Changed document to state that default is xsd:dateTime for ValueType. Rob any recommendation on format, SAML says must be UTC, should not rely on time resolution better than milliseconds Tony further up it says UTC, Rob What is compelling reason Prateek not meaningful to use too fine a resolution from SAML- all time values have XML Schema dateTime, MUST be UTC, not rely on time resolution greater than milliseconds, must not leap seconds. Frederick: MUST on UTC or recommended (note that SAML is MUST)? chris recommended since some legacy systems can't do UTC STATUS: pending edit, and vote ---- Issue # 19 tony - why is it a special case Phil G has proposal. chris - postpone username issue into next version, any objections ron - yes, would like to see it in draft chris propose keep what is in current draft and keep issue is open ron password based signing profile is critical to us chris - want to keep us moving, interop on X.509, issue has taken a long time monica, gene separate XCBF from username issue ron RFC shows algorithm for HMAC, one important use case Shawn generation of key from password chris - sounds like a profile put infrastructure in the core doc profile to define algorithms for defining algorithms Martijn Boer - take out password completely for interop draft write password doc chris need to be able to support new algorithms, without revving doc Ron can identify algorithms only Chris no, need additional data for some, need to profile to add this additional data Phil G - don't want to remove things that are part of real use cases before "interop draft", need to be there early on, if really important. Want to make sure get done to level needed to make specs meaningful chris - initial interop will be difficult, try to keep first simple, have additional interops as profiles added Phil G - sends negative message not to spec important aspects by saying we will interop everything in spec, might not interop everything in spec so have everything in spec, lesson from ebXML john shewchuk keep username password token in, get concrete proposals, consider changes. Need concrete proposal from Ron. chris - don't do username/password on first interop, focus on x.509 ron is it correct to call this an interoperabilty draft? -break- -----
Start time of these minutes: 11:30 AM Thursday December 12, 2002 meeting already in progress. Issue 47: Examples (Zahid Ahmed was not present) State PENDING Issue 52: Security token references. State PENDING Tony: two updates in Appendix B and in Security Token Reference where we outlined what will be in the non-normative summary of SecurityTokenReference in App B. Chris sent a sep doc that is now app B on how to process STRs. (lines around 694 in diffmarked) Ron wanted a description of the processing model. Ron - Chris pointed to the processing model. Ron - looked like alternative choices for references, wanted that. Chris - mark PENDING so Ron can review before Tuesday. ACTION on Ron Review issue 52 before next meeting. Kelvin - anyone here who can't be on the call on Tuesday? Brief discussion about quorum, still short 2. Issue 55: Line 395ff. Leave PENDING as Frederick is out of the room. Issue 56: Issue was consolidating to an appendix the wsu information, per Wednesday minutes. Robert Philpott - faults aren't in the appendix. receive type. Chris -- faults. PENDING, Tony will get edit in. A.3 covers type definition. Someone asked about Delay. ACTION on TC review response to Issue 56 for further edit. Issue 59: Guillermo: Need more time; Phillip sent new version to Chris. PENDING. Issue 60: Guillermo -- leave OPEN - need more time. Issue 61: Frederick has worked on clarification, Ron - need to talk with Frederick. Lines 808ff. Jerry - element that we don't have; should be SecurityTokenReference? ACTION on Tony to fix typos, Ron and Frederick re-review. Continues PENDING. Jerry Schwarz - XML security token wrapper - we agreed to do it, Tony had agreed to do it/take proposal. Tony would work with Jerry. Follow-on discussion of Issue 61, leading to a... NEW ISSUE on this, ACTION on editors, Jerry. Ron - several issues, including labeling? Chris - signing of SAML Token. We should think about whether we need it. No scenario in XRML doc that needs it. Jerry - There were other reasons, will reconstruct. NEW ISSUE Grammar to express elements - l167 - ACTION on TC to Review. Status PENDING. Clarification that fragments are illustrative (Tim Moses). Only normative is referenced XSD. NEW ISSUE Security considerations added by Tony: what should be signed (Ron - it wasnt covered in current doc). See line 1500. Ron to review. Took text from SAML binding, uses assertion - Tony will correct before issue of next draft. NEXT ITEM ON AGENDA: "Interop Draft" Kelvin - Issue has been open for a while. People want to do an interop event. There was mail to the list 2 months ago on interop draft. Kelvin would like to do this in first 3 months of next year. We will need more than one such event. Will propose a strict set of scenarios to interoperate on. Discussion on the term "interoperability draft." Chris - We need to create a script, and select a version of the spec that will be the [first] one to freeze for coding. When we talk about an interoperability draft that's what we mean. Kelvin - next F2F should be focused on interop and test of spec. (viz. addendum where a lot of things got fixed) - sanity check point, get a jump start as we come out of this process to become a formal spec. Martijn: generally a good idea, when we specify scenarios define a set of test vectors, which elements to protect, so people can test them. Robert P. - We should write a detailed interop scenario or scenarios. Lloyd Burch - This would need to be an open meeting, NOT a press event. Kelvin - Minutes would be taken. Purpose is to generate feedback on the spec. I will not call pcweek, etc. This is not an embarrassment deal - it's to determine where there are issues and holes in the spec. It will give us a chance to focus on the spec really well. Lloyd - We would not taking notes on pass/fail? Kelvin - the TC will have to establish rules. We will record actions for the editors to fix things that made interoperable implementations easier [meant "harder"] to implement. Tony - will we get feedback from the use case group in the afternoon session? Kelvin - is there anyone on the group? Eric was the driver, not here. Several people - nothing has happened on that list. Don Flinn - Don't stand on formality, post to the list! Kelvin - We'll have to come up with scripts for the event as a TC. Jerry - There's the suggestion of some special status to this draft we're about to issue at the end of this meeting. But the important doc is this scenario document, defining the bits that have to be done. Why the special status? Bill - from interop work, the scenario is what's important, in effect profiling the base spec. Kelvin - We need to do it this way because OASIS doesn't have a "candidate recommendation" designation. We want something frozen. Robert P - The key doc is the scenario doc, it can say use version core-xx. Jerry - Yes, can say in the scenario what draft is used. Kelvin - We want to say that this is the version to work against. Maryann - This draft should be a checkpoint, something concrete. Robert - say which. Doc editing - interoperability draft is designated. Jerry - what can I leave out? Chris - The scenario doc doesn't reiterate the spec. Kelvin - There's no special secret meaning. Robert P - Some didn't know, based on the agenda. Kelvin - that's what mail said. Ron - I agree that the script alluded to with use cases needs to be produced before we can lock down a draft. The drafts we have haven't been validated against (say) using X.509 certificates. Paul C - "No one" is a bold statement. Robert - not all use cases. Ron - need to validate before locking down scenarios. Gene Thurston - agrees. Kelvin - We can't wait for the use case group. Ron - There's a problem with the way that the use case group was kicked off, without participation of the chairs. The TC agreed back at the first meeting that there wouldn't be a use case document, so they've had nothing specific to do. Chris - We expected non-normative use cases, not for formal spec, use cases that we could possibly donate to WS-I. Ron - There was no sense that we needed use cases. Robert - [The chairs?] asserted at 1st F2F that there was no need for use cases. Ron - if the TC agrees that there's an important need for use cases, shouldn't saw the use case group off at the knees. Chris - general use cases [were discussed?], but also a specific proposal for the interoperability. Kelvin - want to kick off. Chris - I will take ACTION to put together a draft straw man of a potential interop script, mail to the general TC list. Date: in 2 weeks. ACTION Kelvin - will ping Eric on use cases. Ron - Now define and give them some weight. We want to show them interop over important use cases. Paul C - Remember that "them" is us. We should disband the interop subgroup and do it as committee of the whole. Chris - [We need a ] precise course through the core spec, where if you don't do it you're dead. Ron - that's a use case. Paul C - may need other use cases. Chris - This will revitalize the people who want to do use cases. Kelvin - At a future meeting we should set date for [the first] interoperability event. I'd like to take a Straw poll on who is interested in coming to such a meeting? And for what purpose? [roughly 2/3 of group present raised their hands.] Comments from group on why people would come - to watch, to attempt to interoperate. Chris - what kind of network infrastructure do we need to plan on? Should combine with a F2F: Spend the morning getting the code to work, the afternoon discussing. Robert - The SAML dry runs were similar. There were two, one on each coast. Focus was on the script and figuring out how to make it work. It was just a meeting, and it worked well (the marketing people not informed). Chris - interrupting - don't want to do that. Robert - (continuing) More of a working meeting. Chris - So let's have a TC meeting with a "code focus," perhaps in February. Discussion - Late March better. Won't have scenario/script until mid January. Paul C - We should have two days of interop and then have the f2f meeting. Tony - is there a motion on the floor to have this? [Some comment on "websphere interoperability"] Chris - Some companies have huge issues about unreleased code on the internet. QUORUM AND PROCEDURAL DISCUSSIONS Kelvin - We might have quorum, long discussion on what "attendance" means. Asked who would object to counting attendees that were not in the room as attending for quorum purposes. Objection from Bill regarding quorum calculation. Discussion on attendance for retaining membership, attendance for quorum. Counting of members who had attended at any time during the two day meeting was proposed, which would have reached quorum. Chairs declined to rule that LUNCH Afternoon: 1pm restart. Planned revised agenda: Naming committee - 5 minutes Liaison activity - 5 minutes QoP Discussion list - 25 minutes Adjourn Naming Committee Rob Philpot - naming summary. Based on responses, not checking whether only voting members voted: main choices on core were "Core" or "SOAP Message Security" or "...Protection". 17/25 votes Profile docs - move to "Profile documents" not "Binding Documents." Chris - on Tuesday call, take a vote and put to rest. ACTION on chairs - add vote to affirm straw poll selected names to agenda for Tuesday call. Discussion on whether this was a vote. Email call for vote claimed, but some said we haven't ever done that. Rob - summary of the leading choice: secondary docs: "web services security: tokenType Token Profile" primary doc: "web services security: SOAP Message Security." Liaison: Input from discussions in other groups. No requirement for big discussion. Tim Moses - XCML familiarity? around half of those present raised a hand. Auth and access control in mind - policy. Submitting as OASIS standard in the near future. Should be considered a jumping off point. Quite a satisfying activity - broad range of participants. Hal is co-chair of that group. At the 11th hour there was a disruptive declaration by ContentGuard that they had IP that applied; In Tim's opinion this was mischievous, with unknown motives. WS-I LIAISON Jerry Schwarz - WS-I has created working group on security with the expectation that future profiles will have some security use cases. The first meeting (teleconference) is next Tuesday. Kelvin - I've talked with Eve Mahler (??), the Chair - several people on this TC are on that meeting, so next Tuesday WSS will start on time and finish in 90 minutes (half hour early). We've agreed (?) that the WS-I meeting will not stay in that timeslot. SAML LIAISON Prateek - SAML liaison. SAML has completed 1.0 standard. Co-winner of PCWorld Award. Now entering into the 1.1 process, which we expect to terminate first half 2003. Rob is also co-chair with Prateek (?). Focus is on collecting input from implementation, of which there is a fair bit, and errata updates. SAML metadata and browser profiles, extensions for [something]. SAML 1.1 won't complete in time for WSS 1.0. Prateek is SAML schema-izing your information? yes, in 1.1. GRID LIAISON (OGSA, Global Grid Forum) Frank Siebenlist - OGSA [open grid services architecture, which has web services and other fluff around it) and Global Grid Forum (meets 3 times per year). Introduced WSS in the OGSA security architecture. They have a prelude release that implemented WSS (?!) 6 months ago. One of these GRID groups has also created and licensed a development toolkit, using a BSD style license. Many of the vendors here have ported to their own platforms. There have been early questions on the licensing model; no answers to date, but promises and suggestions that we shouldn't worry about it. Hope that it will resolve appropriately. I have a few questions that I was asked by the [two GRID groups] with my proposed answers... (1) what kind of licensing will apply to the OGSA security toolkit? - I don't know. (2) When will you know? I don't know. (3) How can we standardize without knowing the licensing? - I can't vote for the standard. (4) Are there more members that have issues on this lack? - maybe a few. (5) Could there be a substantial number that won't ratify with a bad IPR statement? - may well be. (6) Isn't this a bad situation to be in? - I couldn't agree more. (7) Are there any reasons this is not addressed? - submitters don't have their act together... (8) Are there some Machiavellian things going on? - I vouch for the integrity of the submitting companies, they wouldn't be capable of doing anything like that. (9) Isn't it hard to expect us to participate and contribute without knowing answers to these questions? - same answer, vouch for the integrity... (10) Are we heading for a confrontation? - possibly, and that is bad. (11) Did you manage to bring this to the attention of everyone? - I'm trying. Lots of colleagues and coworkers are following the mailing list. My request to put this on the agenda was refused - not even acknowledged. (12) Isn't that rude? - It was a mix-up, I vouch for the impartiality of the chairs. The TC should be very careful to ack others requests for agenda status, not very polite. Tony: Verisign put out an open source version of WSS; why can't you do the same to do that? Frank - go back to your own company and ask about our request. Tony - has been done. But IBM, MS, and Verisign worked together on the original spec. Prateek - is there a URL where you can find out how to license this? (no direct answer) Frank - You guys are working for the submitters of this spec, and you don't have this together. Chris - Kelvin offered to get the lawyers together (comments from the house - "and then do what?") Kelvin - You're concerned about the TC, or the IPR statement that isn't part of the TC? Frank - I don't know the licensing conditions. I never had any info except for IPR statement. Chris - are you asking how to get the Terms & Conditions? Go to our URL for the original spec, it will point you to the T&Cs for the April spec. Robert - The Intellectual Property is relevant to each member of this TC. Kelvin - no one has submitted any further declarations. The way I read your mail, I thought you had specific questions about the terms and conditions. Your company's lawyers should talk to ours. Robert - There's a letter of intent to the TC to contact RSA to receive licensing terms. long discussion, re: timing of disclosures. Hal - disclosure "at the earliest possible time." but no enforcement is in OASIS IPR statement. Frank - more Chris - ACTION on IBM, Microsoft, and Verisign: we will try to get what we can on licensing on the WSS TC web site. Chris - From my perspective, I've only known about this issue for 3 weeks, and this request is beyond what's required. If you did the due diligence to go to the MS web site you would have seen. ACTION on group requested by Robert for all TC members to disclose IPR issues. Ron [could have been Robert]- this may come up in many contexts. Someone wants to profile WSS; are there unencumbered profiles of WSS without having licensed the core licenses? IP others submit, e.g. the SAML SOAP binding might implicitly be subjected to this license! What are the linkages of these profiles to the licenses? Hal - could be two versions of a profile, one of which infringes on another. Chris - I can't answer that [Ron's question]; legal issues are beyond the scope of the TC. General comments suggesting that that is the case. WSRP LIAISON Bill - WSRP has issues with respect to roles; communication has started happening, I believe. W3C LIAISON Hal - Liaison from W3C Web Services Architecture. There was a note on 11/11 on WSAWG asking this group to provide WSDL references in the initial issue. (from Dave Orchard) Chris - have an action on this, but it's not clear whether this is appropriate - we're discussing it, but don't understand what is expected of us because it is not representable in its current form. Not clear whether this was from Dave O or from the TAG or from the WSAG? Hal - from the WSAG. QoP READOUT - DON'T HAVE SLIDES Tim Moses - QoP readout. SLIDES AVAILABLE? At the WSS F2F #1 - a need was identified. Objections raised were schedule impact, absence of interested parties. Solution taken - create a discussion group, liaison statement. On schedule impact: Chris - The schedule impact comment is a false claim; this is a hypothesis that majority of TC hasn't followed or discussed, hence no impact. Interested parties should have gone through OASIS procedures; experts should know that the activity is taking place. Only one additional person took part. Tony - what is the scope of a discussion group? Tim - determined by its charter. Tony - open environment, no rules associated with it? Tim - follows OASIS group procedures. Tim - There were people present that found this an important, and possibly urgent, activity. The group is reporting back to the TC on its work. Summarized (from slides): WSS describes how to apply a chosen security policy to a SOAP message. This leaves open: How can the parties exchange their security policies? [SEE SLIDES] Security Policy and QoP document have a normative flavor, but are not intended to conform to full OASIS requirements. Issues: Confidentiality, integrity, origin authentication. Which Parts to protect. Authorization. Privacy. Full report is 25 pages; see (http://lists.oasis-open.org/archives/wss/200211/msg00179.html and link therein to http://www.entrust.com/resources/pdf/wssqopv09.pdf .) How does the consumer find about providers policies, and the provider find out about consumers capabilities? SOAP for the consumer, WSDL for the provider. (???) Tony - any reason the consumer is not also WSDL? Tim - responder may not define the schema for its response via WSDL, it may not have any WSDL. Tony - can policies be combined? Tim - if any intermediaries have policies, the document addresses combining them. John S - could you use the SOAP-based mechanism for that? John S - do you envision this applying to broader policy, e.g. transactions or policy ports? Tim - addressed general-purpose policy language (e.g. for authorization privacy); possible to extend as you described. We focused on security policies. John S - customer requirements - if doing reliable message exchange you would do one kind of security, if not, do something else. if in completely separate domains, couldn't say anything about the cross product. Ron - Need to express security policy associated with a context. So you could define a union context. John - I don't know what you mean by context. If I had a policy (trans, reliable messages) so have a security, transaction, and reliable message contexts? Are these separate from security contexts? Ron - generalize and re-factor at one level. May want to re-factor transaction policies in the same way. John S - context vs policy? I think I'd have policy as distinct from context. Ron - This is in effect a tree that could exist in multiple contexts. John - should be able to define a policy that can apply to different contexts. E.g. transacted ops on Amazon are secure, non-transacted are not. Higher-level framework in which to describe that and those policy descriptions. I see context as separate from policy. Ron - context is the thing that allows you to express all policies (of the client?) Describe the aspects of a security policy that you want to deploy. Could be your active event, express all of its properties. One large area is its security policy. Could be more than one security policy in a context. Martijn - describe security attributes by getting some data, get list of books, and buy one of them. Not interested in security for all of this. John S - important point. Many things out there need policies (choice of algorithms, etc) Prateek - specs, even in life there are many policies. John S - take this and express a general policy language. Prateek - I'd be excited as a professional, but what does it have to do with OASIS? Tim - how do we explain which security mechanisms need to be applied between the parties? More broadly, this is an issue of policy and its expression. But what do we do with this particular proposal? John S - I'd like to see the industry come up with a general policy framework, and have ;the security policy be a specific set of nouns and verbs within. I'd hate a one off that would be replaced by that broader mechanism. Jerry - People implementing web services and intending to use this standard want a mechanism to exchange the required information for things that are out of band. If we don't do it here, they'll have to do case-by-case in a non-standard way. The question is whether someone provides an interoperable standard way of doing it. Tim - wrap this phase of the discussion, turn to what we do about this topic. Ron - Let's say that [my understanding of John's point] is that there should be a way of expressing a unification framework for policies. My question is "would you expect that to be built from common building blocks that are being reused? are you forcing this from the bottom up? would you end up with the same elements? John - I want the group to think about the broader context, and that this isn't the end of the line. Determine that the mechanisms we define here have applicability beyond security. Martijn - Say in mid 2003 WSS is standardized. Then we're told we can produce toolkits for adding things, but no WS client can really make use of WSS because it's a manual process defining what to sign, and error messages. End up with WSS... John S - We must solve this problem. Martijn - delays a general framework until 2004 probably. We need way to express security policies pretty fast. Tim - The Liaison Statement on mailing list [see earlier links] contains link to work we've done. Referencing sec policy from SOAP and WSDL. Tim will propose a Motion - That the WSS TC resolves to form a subcommittee and instructs its members to advance the work of the QoP discussion group to OASIS Standard by Summer 2003. John S - We've said from first meeting of the TC that there's a need for a general policy framework - there are people at MS and other companies that have expertise, and we could bring them together. Frank - I stress that for the OSGA framework, we are using the WSS elements already for 6 months. We have a version of WS Trust, WS Policy, whatever these boxes[in Tim's slides] are. Not giving any dates is very frustrating when we want to move on. Tony - This brings up issues of OSGA also creating a general policy framework, inventing the same thing. John S - Wouldn't it be great if we had a group put together to do something about policy in the broader sense. Robert P - More general sooner? get some consensus around this description to get some interop going. When you go to a service, accept it or not. Monica - some people who would be actively interested. Already discussions on this in WSRP and WSIA. John S - Think of policy broadly. A while back, when we originally talked of WSS, we said that we should have a roadmap of specs and a general policy language. I've heard from a lot of partners and customers. I'd hate to see people investing in a point solution when I know there are people out there thinking about the broader solution. We should devote our energies to solving the broader solution, then the specific. Jerry - If we had a motion, then you'd be opposed? John S - I'd make a friendly amendment to determine interest in a broader solution before doing a point solution. Frank - could we do this so minimal profiles can be defined to do this in the near future? John S - that would be great. Ron - This is a semantic model transformed into XML? Tim has captured a concrete representation of a semantic model. When someone comes up with a grand unification model, could reuse. Tony - Don't want to formalize the 10-20 ways that service could be formalized. John is advocating a more general framework. Then some group could do this. Ron - There is a semantic model for policy that could be formalized and prepared for entry into WSDL. What you're suggesting allows for both things to go on at the same time. Grand semantic model, and at the same time have the specific profiles that we need. Martijn - Define what are the tokens we need to describe (types, parameters), and way to exchange these policies. Probably not inside this group - dedicate to some other group. Also, look at language for describing the semantics. Add semantics to the tokens. John S - Exactly what I'm looking for. People inside and outside this room could bring expertise. Chris - could bring in relevant MS people from various policies. To have the right intellectual horsepower on it, we might create an unbalanced and unpleasant experience. Frank - we need it for this WSS stuff, need negotiation. Chris - we've achieved a refinement of work. Published XML Signature; doing a good job on WSS. There are more steps that are needed. Frank - if you throw this off the wall, everyone will invent their own. Chris - but there will be a standards group that will address this. This is a point on a continuum. Tim - Summary: some are naturally bottom-up, some top-down, and that will be illustrated when this is voted. Don Flinn - Grand unification can take multiple years. We want baby solutions along the way. This is more than a process question. Ron - Who's going to work on this problem? We're here to work on WSS so it's something we all could use. Tim got people that are interested in policy together. Tony - I agree we're trying to solve security problem. But even if I want to negotiate, what language and what level of expression to negotiate in? Ron - Your reps could come to this forum and steer it. John S - Your point is we have a bunch of "security people" but others have transaction, reliable messaging experts, and other kinds of experts, metadata experts. They would like to participate in this, but don't have experience with what we have in security. Let's talk about a detailed timeline? Martijn - I want a sub-TC to express security policy with a link back to this TC. Jerry - If this other group that you're hypothesizing actually existed, we'd probably want to form a liaison (or subcommittee) to work with this other group you're hypothesizing. Form this subgroup as liaison to the grand unification committee when that committee actually exists. John S - Scope the subcommittee to define the whole thing, or the pieces of policy that are relevant to security in the broader environment. Martijn - define our expectations with respect to policy exchange infrastructure, and (if we have these features available) what they are and how they would work. Kelvin - There will be a charter issue whatever way we want to go. Bear in mind how we want to go. Depending on how much additional work is proposed, this will get into a charter discussion. ACTION on TC to consider impact of policy/QoP work. Tim - There was not a great deal of support for WSDL liaison - editors didn't respond. Discussion group ends this coming Sunday. Frank - Should we extend this discussion group and its time period? Kelvin - We need a concrete action at the end of this discussion list's life. Peter Furniss - Assume it fits in with whatever John's group does. Short term, need something about what level of WSS things are required by this TC. Need at least a requirements document. This is not a permanent building with full architecture - an interim policy description, not committed to OASIS spec. John S - Sounds very rational. Tony - Was there a requirements doc? Tim - One doc. No use cases. Jerry - Concrete task for this possible subcommittee - Chris will come up with a scenario/script with a lot of the info/docs we expect to exchange [for interoperability work]. That could be a useful input. Chris - people go off and come back with a requirements document. ACTION ON CHAIRS? - Create a subgroup to come up with requirements. Monica - There's an issue about the identity and propagation of roles brought up in the Security Joint Committee; there's a recommendation coming to take definitions from existing sources, compile them, and provide as input doc to the TAB. (Board had feedback - don't do deliverables, don't do recommendations.) This will be input to the TAB as to how they recommend the formation of a TC to talk about the terms, relevance across the affected communities. No decision or advisement in the SJC. Meeting closed at approximately 2:45pm. ACTION ON TC - Phone next Tuesday, December 17. Members who attended this F2F should make every effort to attend.
ACTION on Ron Review issue 52 before next meeting. Mark issue 52 PENDING REVIEW. ACTION on TC review response to Issue 56 for further edit. Issue 59: Guillermo: Need more time; Phillip sent new version to Chris. PENDING. Issue 60: Guillermo -- leave OPEN - need more time. ACTION on Tony to fix typos in Issue 61, Ron and Frederick re-review before next meeting. Issue 61 continues PENDING. NEW ISSUE on XML Security Token Wrapper. ACTION on editors, Jerry. Ron - several issues, including labeling? Chris - signing of SAML Token. We should think about whether we need it. No scenario in XRML doc that needs it. Jerry - There were other reasons, will reconstruct. NEW ISSUE Grammar to express elements - l167 - ACTION on TC to Review. Status PENDING. Clarification that fragments are illustrative (Tim Moses). Only normative is referenced XSD. NEW ISSUE Security considerations added by Tony: what should be signed (Ron - it wasnt covered in current doc). See line 1500. Ron to review this new issue. Took text from SAML binding, uses assertion - Tony will correct before issue of next draft. ACTION Chris - put together a draft straw man of a potential interop script, mail to the general TC list. Date: in 2 weeks = December 28, 2002. ACTION Kelvin - will ping Eric on use cases. ACTION on chairs - add vote to affirm straw poll selected names to agenda for Tuesday call. secondary docs: "web services security: tokenType Token Profile" primary doc: "web services security: SOAP Message Security." ACTION on IBM, Microsoft, and Verisign: we will try to get what we can on licensing on the WSS TC web site. ACTION on group for all TC members to disclose IPR issues. ACTIONS arising from Liaison reports? ACTION on TC to consider impact of policy/QoP work. ACTION ON CHAIRS - Create a subgroup to come up with requirements. ACTION ON TC - Phone next Tuesday, December 17. Members who attended this F2F should make every effort to attend.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC