06:54:44 RRSAgent has joined #ws-arch 06:54:55 hugo has changed the topic to: WSAWG face-to-face meeting; IRC log at: http://www.w3.org/2002/06/14-ws-arch-irc 06:57:15 Roger has joined #ws-arch 06:58:21 soliton has joined #ws-arch 07:07:11 I put the complete IRC log for yesterday at: http://www.w3.org/2002/06/13-ws-arch-irc-complete.html 07:09:50 chris has joined #ws-arch 07:14:46 Zakim has joined #ws-arch 07:15:18 mikem has joined #ws-arch 07:16:43 zulah has joined #ws-arch 07:16:53 dboo-scri has joined #ws-arch 07:17:38 DaveO has joined #ws-arch 07:20:26 jeffm has joined #WS-Arch 07:20:48 MartinC has joined #ws-arch 07:21:21 GlenD has joined #ws-arch 07:21:58 this channel is temporarily hijacked by subgroup 1 for authentication work on 07:22:14 Ew, authentication! 07:22:17 I'm outta here... 07:22:28 GlenD has left #ws-arch 07:23:24 Other groups in #ws-arch2 and #ws-arch3; logs: http://www.w3.org/2002/06/14-ws-arch2-irc.html & http://www.w3.org/2002/06/14-ws-arch3-irc.html 07:23:28 omh has joined #ws-arch 07:24:03 shishir has joined #ws-arch 07:24:26 GlenD has joined #ws-arch 07:24:39 OK, I'm back, but only to ask for the URL of the use-case 07:24:45 Anyone? 07:25:20 hugo has changed the topic to: WSAWG F2F: work in subgroups on use case at hugo has changed the topic to: WSAWG F2F: work in subgroups on 07:25:43 JensM has joined #ws-arch 07:27:15 this group is auth/n, right? 07:28:08 Jens has joined #ws-arch 07:32:56 http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html 07:39:31 2 parties: 07:40:13 Daniel has joined #ws-arch 07:40:31 2 cases - either the 2 parties know (KNOWN) each other or not (UNKNOWN) 07:47:10 3 scenarios: first time (S-FIRST), another visit same tx (S-VISIT-CONT), another visit new tx (S-VISIT-NEW) 07:47:27 jdmunter has joined #ws-arch 07:47:42 Assume: Travel Agent is known, no delegation 07:54:29 Issue: Difference between authenicated identity and trust 07:55:31 auth-participant: a customer may or may not request credentials from TA 07:55:45 auth-participant: a customer may or may not validate credentials from TA 07:57:18 Issue: Can an entity that has been "authenticated" be spoofing? 07:58:23 auth-participant: a customer may or may not have pre-established governing policies 07:59:26 Assu 08:00:06 Assumption: Every entity has a set of policies (may be empty) 08:01:13 Assume: Customer will pay with credit card 08:01:36 Assume: Travel Agent doesn't care who the customer is 08:04:31 Assume: Customer is booking for themselves 08:05:36 auth-participant: TA may validate customer ID at a different time than customer validating TA ID 08:09:31 Issue: Entities may be able to act in various "roles" 08:14:23 S-FIRSTa: Customer asks TA for credentials, Cust decides to proceed with TA 08:15:28 S-FIRSTa: Cust browses for a flight 08:20:08 Issue: point to point vs. end to end 08:24:55 S-FIRSTa: Cust supplies TA with a flight query 08:25:40 S-FIRSTa: TA queries a set of airlines for flight info 08:28:54 S-FIRSTa: TA does not need to perform mutual authentication with airlines 08:30:49 S-FIRSTa: TA queries the other providers under same conditions (no more authenticataions occur) 08:32:01 S-FIRSTa: (note: above cust query was for an entire trip, not just flights) 08:33:08 S-FIRSTa: Cust makes their selection of travel arrangements 08:35:19 S-FIRSTa: TA asks Cust for info necessary to make a booking: e.g. name, address, credit card #, etc. 08:35:53 omh has joined #ws-arch 08:38:51 See http://www.w3.org/2002/06/14-ws-arch-irc#T08-35-53 08:41:56 omh has left #ws-arch 08:42:03 omh has joined #ws-arch 08:53:48 jdmunter has left #ws-arch 09:03:16 chris has joined #ws-arch 09:13:33 Martin: Use case is not nailed down enough in terms of the business details 09:14:09 We started with assumptions that define different paths through the use case and then some issues that we raised 09:14:20 First, do each of the parties need to know each others 09:14:38 are there business relations? 09:15:23 Assumed general public with no business relationship. Then there is the issue of how many times the travel agent had seen the customer (for a single transaction or multiple). 09:15:50 When you are new, there is no authentication until paying. Whereas when you return for a second visit, there is information on the system and you need to be authenticated. 09:16:02 We only did the first time scenario. 09:16:50 There is still this issue of locating a trusted travel agent. Once you have discovered a travel agent, you can ask them for credentials. 09:17:16 The sophistication of the challenge response depends on the lelve of trust, the amount of money in a transaction, etc. 09:17:28 soliton has joined #ws-arch 09:17:39 We assumed that no one cares who makes an initial query. Only autheicate during booking. 09:18:13 Assumptions: We assumed that the customer is not authenticated, we assume travel agent is known, assume that there is no delegation going on. 09:19:12 nick jeffm 09:19:22 Issues: Identity exchange is easy, trust is not. Once you have authenticated, can mascarading still happen (sorry about the spelling). 09:19:29 hugo has changed the topic to: WSAWG F2F: IRC log at http://www.w3.org/2002/06/14-ws-arch-irc 09:19:45 mitrepaul has joined #ws-arch 09:20:10 Issues: Role vs. personal authentication - do I need separate credentials for different roles. Point to point vs. end-to-end authentication. 09:20:31 TC has joined #ws-arch 09:20:47 Glen: We discussed data integrity. This is the idea that when I send you data, you can make sure that the data is what I sent you. 09:21:24 Issues: When you havea multinode set of parties you have node to node integrity and end-to-end. 09:22:24 The two different cases are because in one case someone not known to you are transfering bits and in the other someone known to me changes data after it is sent. 09:23:08 There may be business issue (not technical) such as miss scheduling. What technical assistance can we provide for business. 09:23:53 Reuse existing technical infrastructure. How do we describe and agree on policies and technologies to be used by endpoints discovery)? 09:24:40 Two solutions: involve a third mutually trusted party. a referree solution. The latter is a stop gap in the process that would not let anything occur until both sides of a transaction agree. 09:25:14 Other solution is to rely on 2 party solutions: ssl, xml dsig hashing 09:25:38 There may be cases where entire data stream needs integrity but also just parts of a document. 09:25:54 DaveO: 09:26:29 DaveO: User talks to travel service talks to hotel and we talked about confidentiality in this reduced setting. 09:26:54 Issues: Is the fact that the two parties are even talking supposed to be confidential. Privacy issues. Both level on table. 09:28:19 We elaborated on the use case. When the user talks to the travel service, this is a sync message. When the travel agent talks to the hotel, this is async. Then the hotel service talks directly back to the user to confirm reservation. 09:28:33 There are other scenario issues but we did not consider them. 09:29:51 What would be the standard way to architect the synch transport - we chose HTTPs. For Asynch we chose SMPT (just for an example) and we also assumed SOAP messages were being sent back and forth. 09:30:01 mitrepaul has left #ws-arch 09:30:42 So in the sync case, the HTTPs takes care of confidentiality. We use encryption for the SOAP message over SMPT. We explored the options of encrypting the entire message, the body, attachments, etc. 09:31:22 In the case of encrypting the body, the header contains infomration about the body encryption. How does the service discover how this is supposed to be sent (description issue). 09:32:12 So we did not explore how to describe the implied processing at the recipient. We talked about existing messages in a foriegn name space and message format. THis cannot be imbedded in SOAP and would be an attachment. 09:33:08 We finished with a discussion about the line between the web interface (connector) and the application portion of a web service. 09:33:19 Heather has joined #ws-arch 09:34:09 Summary: The scenario that we ended up doing was #62 in our useage scenario document so we made that connection. So we can now explicitly tie the usage scenario (62) to the travel use case. 09:34:30 Chris: We have alot of use case work to do and it would be probably wise to give assistance to DaveO in the use case area. 09:34:45 Roger: Should we also be figuring out ways that the use case can fail? 09:35:14 Chris: Think about whether or not you are willing to commit time in asisting with the editing of the use cases. 09:35:30 Send email to me or to the member list (okay the member list due to the email change ;). 09:36:56 Chris: Now that we have had a chance to think about this stuff, I would like to walk through an exercise where we try to gain some concensus around the "size" (scope) of the security WG. 09:36:59 q+ 09:37:51 Chris: reminds everyone that we have this notion about a phase approach to the WG, possibly aligning the phases along Joe's onion (starting at 1). We wanted a targeted scope. 09:38:18 Chris: We talked about the feedback that we got from TBL about process and flexibility with changing charter. 09:39:07 MikeM: Why in the charter don't we list everything and then recommend a priority as opposed to just putting a small amount of work in the initial charter. 09:39:43 Chris: Might leave to much flexibility. As we build this we have to sell this to the AC. They won't want to see a blank check. 09:40:10 David: Proposes ... 09:40:43 Mike: heather mentioned whether the new security was a mini arch group doing WS arch work or are we going to dictate the components and tell them to fill in the boxes with technologies. 09:41:10 Chris: We will recommend a framework. If they have feedback, they can channel it to us. We do not want to unleash another arch group. 09:41:20 i agree 09:41:33 omh has joined #ws-arch 09:42:06 Mike: so we would have boxes for confidentiality, integrity, etc. and some technologies (XML Dsig, encryption) and then the WG would begin. 09:43:07 David: When we talk about the software that implements a WS we can break it into three parts: that which is common to all WS (connector), that which is common to web services in an industry segment (e.g., business WS), ... 09:43:27 Glenn: Can you point out what problem that you are trying to solve because I am resitent to this direction. 09:43:53 Glen: A huge point of what we are doing is that we talk about the wire, not about your end platform. 09:44:25 David: I am trying to help us be clear about what we are talking about. Which is lots of cases of what we should and shouldn't include. So this is for clarity and the ability to draw the line. 09:44:47 David: My reason is that if we don't do this then we will spend an aweful amount of time arguing about whether my favorite thing is in or out. 09:45:02 Glenn: I think that there are better ways to deal with thes types of issues. 09:45:50 David: Getting back to the break up: the part that is common to all WS (connector), the part that is specific to an industry segment (scribe paraphrases heavily), and the part that is application specific. 09:46:39 David: Eg, there might bbe hotel industry specific portions of the WS. 09:47:00 OUr job is to specify the WS connector stuff. I pose this as a characterization for clarity. 09:47:57 JeffM: How do you know that the WS common stuff is not the empty set. 09:48:04 David: If it is then we haven't defined a spec. 09:48:11 JeffM: Disagree 09:48:30 Martin: are you trying to distinguish what is and what isn't a WS? 09:48:48 David: No. If we decide in our specification that a WS must do X, then X is in the connector stuff. 09:50:01 Glen: So what you are saying (and its disturbing me) is the words that you are using smack of software layer and this is not what we are talking about here. So, let's not talk about it in terms of the software at a node. What we are really talking abou tis that there are things that are common to WS that all nodes that implement WS will share .. and then there are application relm things and these are responsibilities, *not* software layers. 09:50:14 Chris: I am failing to understand how this helps us scope a WG to do security? 09:51:00 Mass confusion and kots of people talking at once. 09:51:22 David: There are a number of things in the use case that pertain to the WS paortion and some that pertain to the application part. 09:51:50 DaveO: The SOAP 1.2 spec points this out. But it did this not as software layers. 09:52:13 David: When we go thourhg use cases it is clear to recognize and identify the relm of the parts of the use case. 09:52:45 David: Our job is to decide what bucket items go in (e.g., reconcilliation) 09:53:02 joe has joined #WS-ARCH 09:53:04 David: Does reconciliation go in the WS bucket or in the app level. 09:53:21 Chris: We agreed that we would talk about level 1 securuty(as defined by Joe) 09:54:22 Martin: assuming that our services have interface (service types...), whatever that looks like we need to work that out. The contents of the parameters are in the app domain. The names of ops and things ... 09:54:29 q+ 09:54:51 Scribe, can you use the term "DavidB" for when David Booth is speaking? 09:55:11 Chris: Stops the discussion. Wants to return to security discussion. 09:55:51 Chris: If people could pull up the security requirements, this will help shape our discussion. 09:56:17 Chris: Lets try to determine which of the requirements apply to the WG (which we would put in a charter). 09:56:29 Martin: Please resummarize our agreement yesterday. 09:57:08 Chris: Focus on Joe's Level 1: Confidentialility, integrity, authentication 09:57:13 Phased approach 09:57:22 end-to-end 09:57:48 (steel thread) 09:57:54 what about authorization? 09:58:05 Authorization is level 2 09:58:09 Heather, auth is listed in phase #2 09:58:25 Phase = level 09:58:41 message level end to end 09:58:50 what else is level 2? 09:59:03 pick relevent subset of reqirements 09:59:04 that's it 09:59:19 use case driven 10:00:07 Chris: So this is basically where we left off. What I want to do now is given this, what is the phased approach, pick the relevant requirements, identify use cases to drill down onn (or are missing as the case may be) and make sure that we can actually write up what we want the WG to do. A roughdraft. 10:01:10 Roger: Are we trying to draft the structure of a WG? What are we doing. 10:01:17 Chris: Rough draft of scoping statement from charter. 10:01:35 Chris: What are the relevant requirements? 10:02:37 Roger: 6.2.1 Authentication user, 6.2.2 authentication for data, 6.4 confidentiality, 6.5 integrity. 10:02:58 martin: is there access control in any of this? 10:03:05 Chris: Level 2 its aiuthorization. 10:03:33 DaveO: Are you prposing as part of level 1 that we have to interchange policy statements? 10:03:42 Martin: Access control is fundamental 10:03:54 q+ 10:03:58 q+ 10:04:03 DaveO: Everyone will build acess control into their software. Its what they have to echange. 10:04:09 q- 10:04:38 Chris: are we changing our agreed on staarting point> 10:05:11 Glenn: is access control and authorization differnt? 10:05:20 q+ 10:05:32 Chris: Access control is a means of applying authorization. 10:05:47 ack scribe 10:06:19 Zulah: are we goin to include other requirements (other than security) eg. web freindly? 10:06:28 ack glen 10:06:30 Chris: No, we are not restricting the reqs to security 10:06:34 mikem has joined #ws-arch 10:06:45 Glen: Access control in this scope is part of authorization 10:06:46 ack joe 10:06:50 there is a base set of requirements that are common to all WGs we create and then there are security specific ones. We want the union of the two 10:07:00 ack daveo 10:07:27 Joe: Access control is a specific cas of authorization. the onion model, the purpose, is to allow people to do the scoping. Se we have a choice to do level 1 and level 2 at the same time. 10:07:38 Chris: What I understand is that we want to focus on level 1 10:08:01 q+ 10:08:41 q+ 10:08:51 ack 10:09:31 DaveO: I dont' consider my self a security expert (even though edited SAML spec), SAML talked about authorization in two aspects. When you sign on and you get a token indicating success (auth token or bearer token), and then security policies and access control. These are separate and I don't know what Authorization means in this case. Can we defer splitting these until later. 10:10:19 Roger: Lunch is at noon. We should go to lunch. 10:10:36 are you reconvening after lunch? 10:11:24 No decision yet 10:11:26 Heather: not sure...some ppl are leaving 10:11:42 Glenn: How about having a small group create an outline for a charter and then prpose it to the group. 10:12:06 JeffM: Authorization on or off the table. This is a fundamental question. 10:12:25 Chris: Straw poll, is authorization on or off the table for phase 1? 10:12:42 i'm ok w/ it off for now 10:12:55 (results: most peopl efelt that it didn't belong in phase 1) 10:13:36 Chris: What do people think about a group creating a proposal and then recommending it. 10:14:09 Chris: Are we done with the security specific requiremenst? 10:14:41 Hugo: waht's happening this afternnoon because if the answer is nothing then the people who return from lunch will do this work. 10:15:27 zulah, r u coming back to scribe? 10:15:34 DaveO suggestions for encryption: Shall support HTTPS, shall support encryption of SOAP messages, shall support encryption of attachments to messages 10:16:06 encryption of parts of messages 10:16:27 +1 to heathers 10:16:40 Heather, we are going to head to lunch. Then some of us will return and work firther on the security WG stuff. 10:17:03 Presumaly this will be at 1pm. Sorry for the spelling. tired hands. 10:17:08 zulah, are you coming back to scribe? 10:17:43 Yes I can do that for you. We may also want to go through AC 007 with Soliton. Do you have the message with the summary of comments on AAC007? 10:17:55 BTW. We should play that by ear. We can also do that early next week by phone con. 10:18:09 ok 10:18:25 love to scribe... love to scribe... I'll be here if you are going to return. 10:18:33 i will return 10:18:35 as well 10:18:51 So there is some issue on whether or not we can use the room this afternoon. If this fails, I will let you know. 10:19:02 thanks 10:23:45 TC has left #ws-arch 10:24:02 zulah has left #ws-arch 11:55:15 DaveO has joined #ws-arch 11:55:55 mikem has joined #ws-arch 11:56:34 zulah has joined #ws-arch 11:57:26 Chris: (Choosing requirements from the doc for the WG) We are on 003 - nothing applies 11:58:11 Mike: 004 is getting some re-work. programming models elaboration. And the top level goal for the second part is gone. I will propose new verbage about loose coupling of conponents 11:58:37 MartinC has joined #ws-arch 11:58:39 Chris: Does not preclude any programming model seems like a req that we would want to impose on the WG 11:59:30 Chris: 005 simplicity, 006 have we pulled everything that applies? 12:00:57 Glen: Would like to note the fact that despite the fact that security is an important aspect, my feeling is that the architecture work is higher level. Transactions, coorolation, conversations ... the architecture should be about the structure of how those pieces work and how they fit together and not about the pieces 12:01:10 DavidB: I agree but we are responsible for creating WGs 12:01:45 Glenn: If we pull back and look at the larger scale problem then we might be able to work quicker there. Then, the is this in, is this out can be determined based on the framework. 12:01:49 chris has joined #ws-arch 12:02:30 Martin: We don't even know what a ws is. We need to do this before we charter. We can't do anything until we have some fundamental criteria to determine what's in and what's out. 12:02:37 Martin: The charter seems premature. 12:02:50 Daniel: The group has a tendancy to move the cart way before the horse. 12:03:02 shishir has joined #ws-arch 12:03:08 q+ 12:03:39 Jeffm: So we have a description wg. They have some implicit notion of a ws. I'm not so sure that actually in some ways putting the cart efore the horse isn't a good idea. Since we may not have an agreement about the cart.. the horse..... (strange metaphor). 12:03:42 tomCarrol has joined #ws-arch 12:03:44 q+ 12:03:52 q+ 12:04:01 Daniel has joined #ws-arch 12:04:09 ack joe 12:04:15 JeffM: There is a alot of good understanding of security and we could spend alot of time creating an edifice on whcihc to put security.... but market realities... 12:04:31 Joe: Important to scope what we are doing so we can focus our effort... determine what is in and what is out 12:04:34 ack daveo 12:04:58 I don't agree with Jeff; I think doing the right things in the right order is important...I understand about iterating, but we need a basic agreed-upon foundation first 12:05:00 q+ 12:05:33 q+ 12:05:43 omh has joined #ws-arch 12:05:53 q+ Glen 12:06:00 ack mart 12:06:04 DaveO: Typical problem. How long do we spend doing the general vs. the specific work. It seems a good thing to get a charter in this fairly well understood area, and alteast get some progress while continuing the arch work. Company created arch analogy... We have groups in flight (SOAP, WSDL), we can make some concrete progress and show value to the world while working on the architecture. 12:06:22 Martin: I'm not saying that we do a perfect architecture but we don't really have a starting point... 12:06:55 Martin: There are fundamental questions going on in WSDL. How can we have new teams start without some alignment. We need to schetch some arch assumptions before starting on this. 12:07:28 Chris: Our objectives... end of july requirements... outline for arch doc... with cut by July... 12:07:29 joe has joined #WS-ARCH 12:07:43 DaveO: We have a first cut arch doc and we have had a discussion and we are going to re-work it. 12:07:46 ack tom 12:08:22 ack mark 12:08:27 TomC: Without definin the domain to some degree it complicates our activities. Whether we get a set of use cases that we can all agree on... refining the use cases and applying our use cases would provide more direction on laying out the architecture. 12:09:11 ack daniel 12:09:12 Mark: Thank martin for saying what he said (about issues in outher groups). Supportive of DaveO's efforts to get the WG going quickly. We need to resolve how web services arch relates to web arch. 12:09:49 Daniel: I worry about the approach that DaveO is advocating. Same method as developing software (no) standarrds last longer than software. No repeat versioning... 12:10:37 ack glen 12:10:46 DaveO: we develop standards more slowly than software. (6-9 months software). If we had a charter and a wg in nov it would take 2 years before something came out. Standards take longer than software and should be started as early as possible (paraphrasing from scribe) 12:10:50 q+ 12:12:38 Glenn: I am concerned about chartering a WG and they come out with a spec while we are doing arch work. And its not compatible with the arch. This may well not happen but they may be some considerations that the arch group would come up with that an individual group might not come up with. The groups may feel strange about being pushed in directions that they weren't expecting. We need to clearly message to groups that they are taking part in an archite 12:12:55 ack martin 12:13:09 q+ 12:13:13 Martin: Not proposing that we wait 6 months. It takes a while to get Charters going. Would like month to month+1/2 to answer some of these questions. 12:13:34 Chris: This realistically would put us in the oct time frame wto get something off to the AC. 12:13:51 ack daniel 12:13:57 Martin: I dont' understand the big emphasis on security. The security group has nothing to start from 12:14:43 q+ 12:14:48 Chris: Group will n ot get chartered until December. We will have answered some of these questions. Exactly what glenn has said is what (I believe) TBL is saying to us. (rephrase) 12:15:19 Glen: What happens when (for example) wsd is doing stuff and they come up with arch issues that need to be solved and will be solved by wsd. How does this happen. 12:15:29 Chris: There is a process. Submit and issue. 12:15:33 q+ 12:16:02 Daniel: I get some sense that we are date driven as opposed to determining how ling things will reasonably take. 12:16:06 q+ 12:16:22 Daniel: Should we go back and do some reasonable estimates. We could base our times and deliverables on this. Let's do it right. 12:16:23 ack daveo 12:17:24 DaveO: The tag ran into this problem. Chartered to both resolve issues and document the web architecture. Approach tag took is to split time between findings and architecture. TBL had a discussion about this and 12:18:19 decided to split the time. The TAG is even more focused on solving issues that on the document. 2/3 issues, 1/3 arch doc. COunter arguement is that web already exists. However interpretations of web arch not well defined. 12:19:14 ack hugo 12:19:19 The way that I would look at this is let's take some time on security, and in the mean time have work done on the arch document. We can work in parallel and partition our time between the strategic and the tactical. 12:20:02 q+ 12:20:15 Hugo: There is a scale of approaches here and we have to choose some middle ground. 12:21:44 WSDL may not exactly be compliant with the arch but it will do for now and we will tackle arch inconsistencies in the future. This depends on the time grame for both teams. Regarding what we should do, some things are easier to do without global arch view than others. Choreography vs. some security. Choose carefully what we want to do. 12:21:46 ack markb 12:22:37 q+ 12:22:49 q+ 12:23:08 ack sol 12:23:12 mark: We are working on charter with no arch constraints. message based, event based, what are the fundamental restrictions on component interactions. Asking a security WG to build a solution - they will ask "for what". We could get there fairly quickly but we need to resolve how our arch works with the web arch. 12:25:15 Soliton: Time to market is extremely important - there are products out there. Helps comapnies choose which tech to use. Second, although security is the # issue in WS, they are very security specific (as opposed to WS specific). We should look at the existing technologies and determine what we can use that already exists. Sone guidelines so that companies don't produce monsters during the period of time that we don't have a well defined arch (paraphras 12:25:16 ack chris 12:26:18 Chris: Several points. 1) with regard to knowing the architecture - I argue that we all genrally and itnernally know what we are doing (we need to write it down but this should not stop us from working). 2) 12:26:42 +1 to chris point 1) 12:26:54 Q+ dbooth 12:26:56 q+ 12:27:58 We could also look at this as solving a specific as oppsoed to a generic problem. Clearly people have been trying to determine how to attach a dig sig to a message (for integrety). Everyone is looking for one way to do this. 12:29:30 The longer that we put off the WG the longer we have problems and peole are clamoring for the WG. 12:30:08 q+ 12:30:25 ack martin 12:30:48 q+ 12:30:55 Martin: what you are saying is radically different than our current discussions (which are gneric rather than specific). IF we have something specific, fine. 12:31:35 Martin: We haven't said that a WS has a WSDL interface and SOAP. 12:31:36 ack db 12:31:41 DaveO: yes, we all know this. 12:31:50 q+ 12:31:58 Martin: Independnet of that, by novermeber we must have first scketch of arch. 12:32:38 Heather, you there? 12:32:47 heather, you there? 12:34:01 yes... 12:34:19 got sidetracked for a few minutes 12:34:27 q+ glen 12:34:29 Dbooth: (has put up ws slide that is back on the partitioning portions of a WS) charter include specifying what the conector is (common to all ws), second purpose is to propose WG for specific features. 12:34:36 just pinging to make sure you aren't sleeping 12:34:49 J/K 12:35:26 I believe that what we will find happening is this, each person will have a different view of the difivding line between features common to all ws and specific features for some ws. 12:35:38 ack markb 12:35:54 (and of course IBM doesn't agree that web services must have soap, but I thought I'd save it for another day) 12:36:08 lol 12:36:11 agree with Heather 12:36:40 but this sounds strange from IBM, since it started SOAP 12:36:56 actually, it was MS 12:37:09 Mark: Chris' comment based on the premise that everyone nows what the ws architecture is. However, this view is not compatible with web architecture. The recent decition TAG on using SOAP with HTTP and having to use get implies that any SOAP 1.1. service out there today has to make use of get in a web arch compatible way. Most today use get in a web arch incompatible way. 12:37:10 i think we are going to have to divide our time between specific issues and the architecture like the tag 12:37:43 i too feel the need to get some broad agreed architectural brush strokes before we start chartering work groups.... 12:37:52 Chris: How does the integrity issue make any differnce with the web architecture issue of using get or post? 12:38:08 Mark: Yes. it makes a difference. Your request is not digitally signed. 12:38:14 but, I also feel the pull of getting security solved by security gurus 12:38:26 Chris" I want to have a soap message that I can prove is the one that was sent to me (independent of request or response). 12:39:09 the actual implications on the existing runtimes remains to be seen 12:39:22 q+ DavidB 12:39:25 DaveO: We are trying to get to the point where we have a security group and we talk about very specific requirements. But we aren't at this point. 12:39:26 (in response to Marks comment) 12:39:37 Mark: I agree that the security group is one of the most arch independent groups. 12:39:43 so, Heather, why IBM prompts non-soap ws? 12:40:00 IBM defines web services to be defined by wsdl. 12:40:06 Chris: The reason we are standardizing is that we have several solutions out in the martket today. We need a standard so that we can get to interoperability 12:40:11 wsdl can define bindings that are non soap..... 12:40:13 Mark: There are other things that need to interop. 12:40:21 q? 12:40:36 non soap bindings will be very important for internal application integration and high performance 12:40:44 Chris: We are trying to scope this so that .... 12:40:53 q? 12:41:08 ack daniel 12:41:11 makes sense. 12:42:27 Daniel: Developers don't sit around and wait for architecture (as chris and DaveO point out). Also, as hugo points out we need to choose a middle ground. However, what I am hearing is that we haven't done the first ground work and once this is done we can parallelize and iterate. 12:42:29 ack daveo 12:44:28 DaveO: Personally and professionaly commited to furthering both security and the architecture. We have been doing both the arch document and progressing, and also to getting a security WG in place. let's agree on a process of splitting our work between creating working groups and architecture. 12:44:32 i'm not sure we need for the ground work to be DONE 12:44:36 ack jeffm 12:46:58 q+ 12:47:23 JeffM: We have an abstract defn of a ws. there are concrete instances of WS. Regardless of what beautiful abstractions we create, people build WS with SOAP over HTTP, they use WSDL and those people who are shipping product have a real need to secure their messages. Interoperability important... let's realize that there is a two part reality (arch and time to market). Advocates chartering WG now and then working on the arch. 12:48:20 q- glen, david 12:48:50 what did glen and david say? 12:49:04 heather, you're up in a moment 12:49:10 glen abdicated his spot 12:49:13 david is speaking and glen abdicated. 12:49:19 q+ 12:49:19 k, thanks 12:49:20 David: Likes prposal of dividing time between arch and charter for WGs. Phrases this in term of the partitioning proposal. 12:49:23 tag, you're it 12:49:28 type away 12:49:54 heather type 12:49:54 what if we compromise on this... can we make a concentrated double time effort (extra ccalls) 12:50:04 to get broad brushes to the architecture 12:50:08 that we agree on 12:50:12 the crowd moans...... 12:50:15 the crowd goes ooooooooh 12:50:17 general ooooo 12:50:17 and THEN define the security working group? 12:50:22 bad ooh? 12:50:29 middling oooo 12:50:32 not clear that this was a bad oooo 12:50:34 Just 2 weeks 12:50:39 big time deadline 12:50:41 no, that was a combination interesting, but... ooooooh 12:50:58 or else the security workgroup creation guys win and we make one w/o waiting for the arch guys 12:51:22 Chris: points out that DaveO and chris already do this and they are up for it. 12:51:30 q+ DavidB 12:51:30 this would motivate the arch guys to NOT argue about how many angels can dance on the head of a pin 12:51:52 q+ 12:52:03 hey, I'm working on Angels-on-pinhead ML 2.0 already 12:52:05 ack heather, martin, davidb 12:52:06 and its easier to dump a lot of time into something if you know its a short duration crush 12:52:16 Dbooth: nothing against the idea of doing double time but not realistic. Difficulty getting people to read documents and participate 12:52:19 ok... flame away 12:52:36 q- 12:52:43 q- heather, martin, davidb 12:52:44 q+ 12:52:50 ack dave0 12:52:54 ack daveo 12:53:16 DaveO: will try to interpret heathers proposal. For two weeks do double itme and whatever we get done is whatever we get done IF we haven't made good progress , too bad. this is how things work in a real company. 12:54:14 I agree with dbooth on the double time thing. For me double time does not really work. If there is heartburn over spl;itting time between general arch and security, I can live with speding the next 2-3 weeks on arch and then the next 3 week after that we can focus on security 12:54:20 ack hao 12:54:42 soliton: Maybe we can divide into task forcces as the groups are large. 12:55:17 Chris: (frustrated) all for double time but is it realistic to expect people to do the work. 12:55:34 Chris: Architects want to work on everything. 12:55:46 thats why i suggested single threading it 12:55:53 instead of parrallel... 12:56:09 a concentrated effort to get something down on paper 12:56:48 a few people would have to 'sign up' to work very hard 12:56:57 q+ dbooth 12:57:07 and the rest of the wg would have to agree to do short turn around reviw... 12:57:12 ack db 12:57:15 q- 12:57:17 q+ 12:57:18 scribe: Zulah: we have been successful in having small groups make proposals. We could have a few people work on aan architecture fundamentals and at the same time have a group do the security charter. Then bring it back so that we have something to discuss. 12:57:23 and chris i sympathize in that we have not been good at fast anything 12:57:32 Dbooth: Liked DaveO's proposal, what happened to it? 12:57:57 Glen: We almost got there and then the taskforce idea came up and I am infavor if the latter. 12:58:09 DaveO: at some point the task forces have to report back. 12:58:39 Dbooth: would these be taskforces for things that need charters and the architecture fundamentals? 12:59:44 Chris: So my problem as chair is the schedule. I am not a manager. I am not schedule driven usually but I am now. We have 5 weeks before we take a 1 month break. 13:00:20 other people can keep going during the break 13:00:27 So we have 5 calls. And if we have 4 task forces working on different things theen there is no time to have them all report back in time for the 18th (or so) of July (when we have to report). 13:00:39 q+ 13:00:46 q+ 13:01:05 ack tc 13:01:37 ack scribe 13:01:38 Tomc: I tend to like the idea of "taskforces". Someone ususally put up a strawman. THis is the most likely way to make progress. 13:02:06 omh has joined #ws-arch 13:02:12 what about bumping up the call schedules? 13:02:16 or making it longer? 13:02:34 Heather, there's been a fair bit of pushback on extra time... 13:02:42 Zulah: has managed and pontificated a bit 13:02:44 zulah: create a scheduel for 5 weeks and see what we can get done 13:04:11 DaveO: has put up a straw man. I would like to have two task forces. The security and the existing architecture (harvested from SOAP and WSDL). 13:04:47 zulah pontificates again, +1 13:04:50 ing DaveO 13:04:55 +1 on Dave0 13:04:58 zulah: conceptual architecture is important 13:05:06 Glen: do we want to volunteer people now, mailing list, plan? 13:06:35 How about: 1) Architecture document; 2) Security, including usage scenarios/use cases and requirements. 13:06:47 Chris: DaveO has proposed one taskforce for security WG charter, and another for architecture (where architecture is working with the editors to determine first cut of arch document). 13:06:57 q+ 13:07:09 q+ 13:07:09 Joe: inside the doc there is a securith section and this needs to be filled out. 13:07:13 q+ 13:08:12 ack daveo 13:08:12 q+ 13:09:05 DaveO: we formed this use case task force to try to make progress on a document. We agreed on terms but have not agreed on a single use case or scenario. So, we could agree to the "harvesting" task force (SOAP WSDL), and a second team is the security group and they are constrainted to the use case and usage scenarios that are specific to security. (So Dave has suggested that we slice things a different way as they relate to use cases). 13:09:25 Joe: Trying to understand more clearly how security and the arch document relate. 13:09:46 MikeM: How would this be more useful to the use case task force? 13:10:40 DaveO: The directed discussion abou tsecurity almost alowed us to articulate trequirements and to connect scenarions and use cases. So the security folks flesh out the scenarios. 13:10:53 q- 13:11:03 ack scribe 13:11:49 ack hao 13:13:03 Soliton: When people see documents they seem like they are pregiven. need process.... 13:13:28 Chris: What if the arch guys come back with a doc, what makes you thin kit would be received differently 13:14:12 Glen: There is another complementary idea that somethime when you have a concrete thing to look at it provides a framework for discussions. 13:14:25 can the scenarios work just focus on security issues right now? 13:14:48 q+ 13:14:50 Heather, that was my suggestion. 13:15:27 MartinC has left #ws-arch 13:15:49 glen, +1 13:16:01 omh has left #ws-arch 13:16:10 zulah: Need to continue with the use cases and we need to try to gather them from other organizations. So I agree with heather but I also think that we should not forget the importance of high level use case gathering. 13:16:17 Chris: Break 13:16:27 zulah, I agree with you on that. 13:16:36 i don't want to forget to gather other use cases, there are a few I'd like to add... 13:16:58 can we just concentrate on some immediate issues and then look up to the bigger picture in a few weeks? 13:17:23 omh has joined #ws-arch 13:17:27 if we take some brush strokes at the archicture... then we'll have something to tune as we work thru the use cases 13:18:14 Heather, break for 15 mins 13:18:15 did you guys break on me? 13:18:20 I suggested that too heather. 13:18:20 k... 13:18:27 omh has left #ws-arch 13:23:11 we just broke.... 13:30:54 we feel broke too 13:40:50 i'm here... ya'll back yet? 13:42:02 we're baaaack 13:42:29 i'm concerned if we have too many task forces (even 2) we won't get the concentrated work from people to comment and agree on the architecture 13:42:53 chris: Who is willing to contribute their effort to one or the other task force. 13:43:08 mikem has joined #ws-arch 13:43:10 Zulah: need clear statement of what each group will do 13:43:14 i shared the same concerns earlier 13:44:11 Security: Refine usage scenarios and requirements relating to security, particularly the 6? sections. 13:44:43 dbooth has joined #ws-arch 13:45:00 Harvesting: Look at the WSDL conceptual model and the XMLP MEP and bindings work and harvest architectural material. 13:45:06 Reliability: 13:45:07 Chris: Looking for people to join either task force. We have DaveO, Joe, Hao, Mike, Tom, Daniel, Hugo, markb, dbooth, glen, eric 13:45:27 MartinC also wanted to participate 13:45:35 Use Cases: Add use cases with individual owners: Zulah, Hugo, ? 13:45:42 if we serialize this.... i can do both 13:45:59 if we go parrallel we miss come companies's views on both groups... 13:46:55 i tthink the havesting work is VERY important!... so if i choose, I choose that one 13:48:42 Reliability Task Force: Responsible for re-working AG002. Timeframe? 13:49:11 2 weeks. 13:49:40 q+ 13:50:08 Actually, I will be in the US for the next two weeks, so we can talk a bit more 13:50:32 for the reliability work 13:50:52 q? 13:50:56 q+ 13:50:58 ack scribe 13:51:28 Daniel: DaveO pointed out that use case is ongoing. What does this mean. We have closed requirements. so what are the use cases good for after we close requirements. 13:51:47 Chris: We will iterate. 13:52:25 q+ 13:52:45 i agree with davido that usecase is on going in parrallel with architecture 13:53:13 Daniel: understand iteration, trying to understand you and Hugo's view point. We will publish the requirements document as a note. Does htis imply that we won't do this for a long time (as not to make changes to the note). 13:54:15 Chris: The way we handled this with SOAP is that we have had a frozen requirements doc that we have gone back and updated. So we don't publish a note until we are done with the doc. The doc is a wg document for the life of the wg, when our chrter expires, then we would publish the note 13:54:45 ok 13:54:46 Hugo: requirements docs we work on early and we may modify it. It is kept open through the WG and then frozen at the end. 13:55:09 Dbooth: 13:55:26 I see 5 things that chris has doen on the board. Not clear on the proposal. 13:55:42 Chris: there are four and yes this is the proposal. This proposal adds two task forces. 13:56:01 Dbooth: There was discussion about arch fundamentals effort? 13:56:13 Chris: This is the harvesting. 13:56:18 general disagreement 13:56:22 ack daniel 13:56:27 ack dbooth 13:56:39 Joe: is this the same as what mark has been evangelizing 13:56:44 Dbooth: similar 13:57:02 i thought harvesting was arch fundamentals too.... 13:57:05 DaveO: I was suggesting that we begin with material that already exists 13:57:56 ack scribe 13:58:24 so lets rename harvest to Architectural Fundamentals and assume that they will leverage existing work (like they have a choice) 13:58:33 q+ 13:58:34 Dbooth: a task force that will try to pin down... 13:58:42 naming something "architectural 13:58:57 anything will probably result in social issues in the group 13:59:28 q? 13:59:28 i'm not sure that nameing will prevent social issues :-) 13:59:31 q+ 13:59:31 Zulah: What you have up for use cases differs from what we've been discussing. I think the UC team should gather high level use cases and put them into acceptable form. I think the security team should focus on scenarios and how they relate to use cases over time. 14:00:15 q+ 14:01:28 Zulah: Also, My assumption was that we would take some tiny steps with the architecture. That is, that we would first determine what is already out there wrt architecture and then come back and refocus a taskforce to do some more of the fundamental work. This will alleviate the concern that a small group is going to go off and bake the core architecture. 14:02:21 Chris: Timing, harvesting 3 weeks, reliability 2 weeks, security 4 weeks, 14:02:28 Use cases on going 14:02:38 So we have: 14:02:55 Use cases: gather use cases, ongoing 14:02:58 ack db 14:03:14 Reliability: focus on rewording AGoo2 14:03:18 4 weeks 14:03:49 Harvesting: harvest from SOAP and WSDL, existing - 3 weeks 14:04:19 Security: scope requiremenst for charter, technologies to be used, usage scenario work 14:04:53 ack daveo 14:05:04 q+ 14:05:10 Dbooth: Architectural principles are not something that we can or should ignore. Also taskforces are efficient work. 14:05:41 DaveO: Keep harvesting taskforce andh scope them to only look at existing stuff. As opposed to a blank check to do architectural principles. 14:06:03 q+ 14:06:04 If they agree, let's then try to extract some architectural principles out of that. A starting point. 14:06:27 ack hao 14:06:35 If the harvesting taskforce becomes the arch fundamental task force then it is too broad (paraphrasing) 14:06:44 thanks scribe ;-) 14:06:46 the other groups do not address publication and discovery of services... an important aspect 14:06:52 we can't just igore that! 14:07:20 Soliton: In the reliability group, the management stuff didn't get enough comment. I woul dlike to see emphasis on management. 14:08:12 soliton == hao 14:08:16 Zulah: I also would like to see emphasis on WS mgmt. I know Heather has a paper on mgmt, and HP is interested. It's a big hunk to chew off, and there are so few people in the room with a direct commitment to it, that we need a firm statement before we can move forward. 14:08:24 won't the reliability group still be doing management???? 14:08:29 ack mike 14:09:01 Mikem: Wanted to +1 DaveO's comment on scoping the harvesting task force. The result of that work will feed into something that will lead to what others (dbooth) are looking for. 14:09:44 ack db 14:10:05 This would also lead to more of a boxes, interfaces, constriants view of architecture that I am used to. Also, we have not listed all of the functionality of the architecture (discovery registration) and these basic functions are missing. The arhitecture doc is starting to address this. 14:10:39 dbooth: I agree that the taskforce would be too broad. So, where do the arch principles get done? Where does a strawman proposal get baked (paraphrased). 14:11:09 The question is how do we arrive at the architectural principles. Do we do this by the entire group or do we assign a task force. 14:11:10 q+ 14:11:56 Chris: What I hear is that you want to focus on the architectural principles and I'm not sure that I am ready for this. 14:11:59 q+ 14:12:05 q+ 14:12:29 q+ 14:12:43 Dbooth: another way to think of it is that if we spin off several working groups that would define the requirements that would ensure ethat the results of the working group would work well together. Do we want a task force for a straw man proposal for arch fundamentals. 14:12:47 q+ 14:12:52 ack zulah 14:12:57 ack scribe 14:13:25 Zulah: My concern is that we need to stage the work to create an arch. The harvesting is important and needs to be done first. 14:13:39 ... To go away and do fundamentals before that would be a mistake. 14:13:49 ack mark 14:14:28 Mark: Wants to say what he thinks david booth is trying today. The fundamentals are like going to our glossary. What are the components, what do they look like, how do they interact. 14:14:30 ack tc 14:14:52 heather, you're up next 14:15:08 k 14:16:42 TomC: I tend to agree with Dbooth with regard to defining a minimal set of usage cases. Mark discussed the components how they relate, ... a minimal set of usage scenarios would allow you to determine what Mark is asking for. Then you can delegate off to the security task force to work from the basic use cases. That is, that they start from the use cases as a description of the minimal architecture. These would also specify the requirements (paraphrasin 14:17:00 ack heather 14:17:05 type away 14:17:06 i am very confused.... 14:17:30 are you typing more detail? 14:17:30 i thought that we were precisely at the point where we need to start creating components and interactions... 14:17:45 the start of this is in dave0's draft already 14:17:53 i must not understand what harvesting is.... 14:18:13 i THOUGHT it was factoring in the xmlp and desc groups work into that components and relationships layout 14:18:34 if we're NOT ready to do comopnents someone please tell me what we ARE ready to do... 14:18:41 that seems accurate heather 14:18:48 objects? 14:18:48 beer! 14:18:51 Heather, the issue with the arch doc as it exists is that many were confused about the conceptual model. So Glenn suggested a more explicit harvesting of wsdl and xmlp material. 14:18:52 and If i'm too confused to straighten out on irc... then someone please help me out next week on the phone 14:19:11 components are things like "sender" "receiver", "intermediary", etc.. 14:19:18 chunks of software 14:19:21 sorry daveo... your conceptual model confused me too... 14:19:22 heather, I don't think that you are confused 14:19:34 i think it needs work .. words to go with it and explanations 14:19:35 thats ok 14:19:38 q+ 14:19:58 yes... and we need a soa diagram with service provider, requester, registry, description all laid out 14:20:03 we all have this picture 14:20:13 Joe: What DBooth said about the importance of the conceptual model then just do one without waiting for the taask force. 14:20:15 don't think you're confused... problem is that there's a gestalt delivery problem... 14:20:19 cool, where? 14:20:31 Joe: I want to see more specifics to determine what I want to buy into 14:21:05 DaveO: are we going to have a fundamentals of WS taskforce over the next few weeks? 14:21:12 Chris: No, this is off the table. 14:21:13 Dave's diagram is ONE swag, not seen or agreed on before this meeting... take it for what it is and lets work on it 14:21:39 gestalt???? 14:22:07 chris: micromanagement (paraphrasing) 14:22:22 chris means "all at once" 14:22:49 Chris: realising when we bring something back to the group it takes a good deal of time to get something approves and to get people bought in. 14:23:10 6 weeks not being sufficient time to complete all the tasks....we can only boil the universe one drop at a time 14:23:19 yes, but thats why we have to design by strawman, not by committeee 14:23:31 (how many angels is that?) 14:23:49 q+ 14:23:59 chris: four taskforces seems excesive but this is probably our minimum. So process wise, I just don't see how we are going to work another task force. I don't think that there will be simple agreement on "every web service has one of these", then there are philosophical problems (WSDL -> WS, SOAP -> WS, others). 14:24:20 I don't sense a full appreciation for the fact that there is a core set of things. 14:24:24 14:24:28 Mark: There is a definition, all things have a URI. 14:24:50 q- 14:24:52 not-wellformedness error 14:25:33 Dbooth: I understand then that the fundamental principles will come out later from the working group. 14:25:40 Chris: Yes, I believe that they will come out later if they exist. 14:26:02 +10! chris! 14:26:22 if they don't exist, we're in a whole lot of trouble 8-) 14:27:04 these philosophical problems chris mentioned need to be argued and agreed on (even if grudgingly) before we can solve other problems 14:27:20 Chris: Right now for this next 6 months, I do not believe that the group is prepared to deal with another task force and I still don't quite Grok "what it is" that we wouldwant from this taskforce. 14:27:28 the architecture and security solutions will be VERY different if there is a guaranteed SOAP layer ... or no. 14:27:38 scribe: should be 6 weeks rather than months.. 14:27:42 q- 14:27:51 An architectural principle is a statement of constraint that does not change due to technological change 14:28:26 right on 14:28:43 whatever arch principles we have will fall out as we work iteratively w/ use cases and a draft arch. 14:28:50 Daniel: on the conceptual level, there is no way to make this happen in tis short of a timeframe. 14:28:56 i don't think we can state them up front 14:29:06 q+ 14:29:12 the timeframe is a problem... 14:29:14 I don't disagree heather, just wanted to offer a defn. 14:29:19 perhaps we should be fixing that one.. 14:29:33 (Thanks Daniel... I needed the definition, its a good one) 14:30:35 Chris: Its 4:30 (for some of us). Straw poll, how many people think that the four task forces (use cases, reliability, harvesting, security) are the ones that we should focus on for the next 6 weeks? 14:30:41 (result was a majority) 14:31:06 Chris: How many people think that we don't have the right set of work and that we need to work with the architectural principles? 14:31:32 Chris: So, these are the task forces and I will pick some participants and victims to be chairs. 14:33:05 use case - gather use cases (edi, travel, others) ** ongoing, but with 4 week freeze for pub 14:33:06 harvesting - outline, etc (clam digging in WSD, XMLP, elsewhere identify 14:33:06 conceptual model aspects like the SOAP process model and WSD extensibility) ** 3 weeks 14:33:06 reliability - focus on proposals for D-AG002 (keep on keeping on) ** 2 weeks 14:33:06 security 14:33:08 - scoped requirements for charter 14:33:09 - technologies to look at 14:33:14 - usage scenarios work focus on security (s61, s62, s63, s64, ...) ** 4 weeks 14:33:45 use cases TF responsible for "harvesting" uc and us from other orgs (OASIS, OTA, RosettaNet, etc.) 14:34:02 q? 14:34:20 ack mikem 14:35:14 Mike: I think that we are going round and round on the obvious. One mandatory view is to describe the components, their interfaces, and connections between them. Message exchange patterns are something that we see over ad over again. Usage scenarios help us get to this but as a spec writer I will be more interested in seeing the more concrete ... 14:35:16 ack db 14:35:32 Chris: its a wrap then... 14:35:46 that trout gets around.. 14:36:03 something smells fishy... 14:36:20 thanks, Dave0 14:36:26 q+ 14:36:58 Heather, we are done. Any confusion can be cleared up via phone calls next week. Have a great weekend! 14:37:05 k 14:37:11 yall have a good flight home 14:37:16 tc has left #ws-arch 14:37:23 Hao, you and me should do an early phone call next week to deal with 007 14:37:32 me too 14:37:44 l8r 14:37:53 sorry, that was to you heather ;) I'll talk to you both by email on monday. 14:38:09 k.. 14:38:10 by 14:38:14 adios 14:38:15 thanks all! 14:38:27 zulah has left #ws-arch 14:42:20 rrsagent, where am i 14:42:21 I'm logging. I don't understand 'where am i', chris. Try /msg RRSAgent help 14:42:35 rrsagent, where am i? 14:42:35 See http://www.w3.org/2002/06/14-ws-arch-irc#T14-42-35 14:43:04 rrsagent, please excuse us 14:43:04 I see no action items