Minutes of June 12-14, 2002 WSAWG F2F

Scribes: David Booth, Allen Brown, Zulah Eckert, Tom Carroll

Agenda, Resolutions, Attendance

Wednesday, Thursday, Friday

Agenda

Wednesday 12 June 2002

[hugo]
hugo has changed the topic to: WSAWG face-to-face meeting
[Roger]
Heather?
Heather - we are about to start up again.
[chris]
agenda: http://www.w3.org/2002/ws/arch/2/06/wsawg-f2f-jun2002
[Roger]
Heather, are you there?
[Heather]
I'm here
[AllenBr]
Review of this afternoon
1. work on ag004 and all csfs
primary focus security and security
2 last week proposals
no pushback on list
if time then review glossry
all above remarks from chris
Chris: minutes of last telecon
Chris: Minutes approved given lack of objection
[chris]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html

Review of Requirements document

[AllenBr]
Chris: Start with AG004
Chris: have already agreed on a log of this.
Joe: Can we go to AC006 -- remove text in parentheses
[chris]
resolved: remove parentheticals on AC006.3 and AC006.4
[AllenBr]
Chris: Joe to act as champion for ar006.1
Joe: this point is in the interest of completeness. Technology avaiable to address some aspects
Roger Cutler: Not clear what text means
chris: most believe this to be out of scope
DavidO: fair amount of time spent on this topic on email, little for us to actually do, therefore eliminate it.
???-1: says in scope change must to should
Chris: focus on shoulds
???-5: Again, what does this mean
Roger: just remove
Roger: get rid or make clear
Chris: straw poll majority against, is it lie down in the road
[Heather]
Get rid of it
[hugo]
[ more discussions about rewording ]
[AllenBr]
The security framewok should/must provide mechanisms to counter the threat of DOS attacks
15 agains, 3 for in straw poll above
[Heather]
DOS is out of our scope, if there is a security wg they could chose to take up the issue
Allen? Are you still scribing?
[AllenBr]
Proposed AC006.1 The WS SHOULD consider the threat of Accessibility attacks ([D]DOS,DNS spoofing, etc.) in the security framework.
[chris]
resolved: AR006.1 The WG SHOULD consider the threat of Accessibility attacks ([D]DOS, DNS spoofing, etc.) in the security framework.
[AllenBr]
???-1 = Alex
ar006.2 change include to enable
Chris: objections to change include to enable
no objections
[chris]
resolved: 6.2.1-6.6 change "include" to "enable"
[AllenBr]
Chris: Security framewok must include Authentication for the identities of communicating parties
joe: difference between 6.2 and 6.5 authenticate data coming from you vs guaranteeing data from you hasn't been corrupted.
[dougb]
I suggest s/D-AR0062.2/D-AR006.2.2/
[AllenBr]
Chris: distinguish between my sending the data and that the data is my data.
authorship distinct from sender
authentication of authorship the right term?
[dougb]
is this authentication persistent beyond the lifetime of the "pipe"?
[AllenBr]
Difference between securing by channel, or message or by role
The security framework must enable persistent authentication of authorship of data
???+6: distinguish once again between authentication of source and authentication of authorship
[Heather]
So its 'this is from Joes' vs 'I guarantee the stuff from Joe is intact'
[AllenBr]
Right!
[chris]
no, it means, this data was created by joe no matter what
[AllenBr]
Joe: SSL does guarantee authenticity of authorship
Agreed that enable does no mean enforce.
[Heather]
Isn't 'Here is a message from Joe' different from 'the message from Joe is origional'?
[chris]
resolved: AR006.2.2 The security framework MUST enable persistent and transient authentication of authorship of data.
[Heather]
ok
[AllenBr]
AR006.2.2 The security framework MUS enable persistent and [Chris got this]
Daniel: remove parentheses around data
Chris: distinguish non-repudiation of origin from non-repudiation of receipt.
[Heather]
which one are we reviewing now?
[chris]
ar006.6
d-ar006.6
[Heather]
I liked the wording we came up with in our emails
[AllenBr]
Is non-repudiation of origin the same as authentication of authorship
Joe: no.
Chris: Chris proposed removing NR/Joe said keep
Joe: no objection to new words
[Heather]
I thought non-repudiation (logging) occurred by both partners and that was termed as of 'sending' and 'receipt'
[AllenBr]
Roger: we all said great idea let's proceed
Chris: read new words
The security framework SHOULD enable non-repudiation of origin and redceipt between trnsacting parties
Joe: SHOULD instead of MUST because can't be guaranteed.
[Heather]
I can live with this
[AllenBr]
Azula: would like to see MUST.
[Heather]
I would object to MUST
[AllenBr]
Joe: observed how to guarantee legally
DavidO: what does this say about priorties (MUST v. SHOULD)
Chris: sort is phase1 v. phase2
[chris]
resolved: AR006.6 The security framework MUST enable non-repudiation of origin and receipt between transacting parties
heather, if you have any vehement objections to any resolutions, please note in IRC
[Heather]
I object still, it should be SHOULD.
[chris]
is this a lie down in road for you?
[Heather]
I have been advised by our security Gurus that non-repudiation is easy to say and VERY hard to do, often verging on boiling the ocean if taken very seriously
[chris]
daveo had same issue, we put this in req'ts and when we scope proposed wg, it may or may not be in scope as we determine for prioritization (that was reference above in minutes to sort by phase 1 or phase 2)
[Dave]
I have strong sympathy with your position heather
[Heather]
I am concerned that we are signing up for MORE than is technically feasible with the current common state of art and business need
[chris]
does this change anything for you
[AllenBr]
Alex: what's difference between MUST and SHOULD for implementor. MUST increases barrier for entry
[Heather]
I agree to TRY VERY HARD
but I don't want to declare failure if its not possible to achieve
[Roger]
Heather - my take is that these are GOALS. If the final result doesn't make it on all of them, well that's the way it goes.
[chris]
i don't think this has to do with implementation, it has to do with whether the framework described enables an implementation...
[AllenBr]
Chris ar006.7
[Roger]
The way the discussion has been going here it seems like the "shoulds" are going to drop out pretty quickly. I myself would be EXTREMELY unhappy to see NR drop out entirely.
[AllenBr]
Alex: remove note under 6.6
[chris]
resolved: remove Note under ar006.6
[Heather]
I agree that NR should not drop out...
[Roger]
I think the sense is that "TRY VERY HARD" is pretty much what we are saying.
[Heather]
but MUST implies that the problem MUST be solved
[Roger]
No, it implies that there MUST be an attempt. SOMETHING MUST be done. Just how successful that something is ... well ...
[Heather]
Certainly NR is a different degree from Authentication
Authen. MUST be enabled... and if its not, we've failed
[AllenBr]
Many participants consider 6.7 out of scope.
[Roger]
We are not disagreeing, nor are you disagreeing with anyone else in the room here.
[Heather]
if we can't enable NR, then I don't thing we've failed
[Roger]
Hey, I can deal with a certain amount of failure.
[Heather]
:-)
[Roger]
You have 30 goals, you're going to get some, sort of get others, and some, well ...
[Heather]
too bad we can't capture the strength of the 'MUST' somehow...
perhaps I split hairs
[dougb]
we're on 6.7 now, that's about key management
[Roger]
Not really -- I think just about everyone has the same worries about NR.
[Heather]
I will revisit w/ our sec people and send email if we feel strongly it should be revisited...
is it 'enable Key Management'?
[chris]
okay, thanks
[AllenBr]
DavidO: what's the nature of things falling through the cracks?
[chris]
yes
(enable), but we're considering dropping 6.7 altogether
[Heather]
I'm ok to drop
[AllenBr]
David O: ill advised to propose things that we're not actually going to do.
[Heather]
I'm confused on the falling thru cracks statement
[AllenBr]
Hugo: JoeR's comment was that he didn't know what KDC is.
Joe: KDC is something like Kerberos.
Roger: thinks we should drop, has nothing to do with web services
???-5: must our architecture include this
DavidO: if built into infrastructure you get it for free
Roger: WS independent of key stuff.
[Dave]
Heather, I was saying that if we don't include something in our works (ie arch document), that doesn't mean the world suddenly forgot about the problem. For example, if we don't say anything about DDOS, that doesn't mean that the world suddenly "forgot" about the problem. I'm trying to argue that we don't have to be the keeper of the litany of the world's ills.
[mchampion]
+1 to "not being keeper of world's ills"
[Heather]
I would agree with you
[AllenBr]
Joe: leave to implementors because everyone does key establishment
[Heather]
We must be carefull not to list so many goals that we force ourselves to boil the ocean
[AllenBr]
David O: should go because we're not going to deal with it in any WG we generate.
[mchampion]
An alternative would be to PRIORITIZE the order in which we will address the world's ills
[AllenBr]
Hugo: charter says we relationship with PKI people so we should consult with them before ditching requirement.
[Heather]
if there is a security wg, couldn't they resurrect this if they think it should be addressed?
[Dave]
Heather, I think we are going to have a comprehensive security framework document. Then we will have a smaller scope for v1 of security wg. I don't agree with comprehensive lists/mentioning of issues, but the WG seems to disagree with that pov.
[AllenBr]
Hugo: proposes adomption of Protocol editorial device indicating requirements on the to be deleted list.
[chris]
resolved:D-AR006.7 The security framework SHOULD enable key management and key distribution
[EDNOTE: we are considering dropping this requirement, feedback ?]
[AllenBr]
Chris: go with new wording for discussion with security WG.
[Heather]
grudging ok
[chris]
resolved: wordsmith the ednote to explain why we might drop it and solicit feedback for those opposed to dropping it.
[Dave]
sorry, I should have said the charter for security wg will consist of comprehensive security framework + set of scoped items for v1 of security specification. But the framework and wg specification are separate items.
[AllenBr]
Roger: get rid of 6.8
[Heather]
Dave: is the wsawg doing the framework and then charter the wg?
[MChapman]
Dave, when I scope a project I list all the must haves. when I plan a project I proiritise the features. We are not prioritising yet (IMHO)
[Heather]
or are we chartering the wg to do the framework
[Dave]
Heather, I misspoke again. the wg will do the framework
[Heather]
understood
[AllenBr]
Chris: this really under the rubric of security considerations.
[Heather]
is 6.8 gone?
(I'd support deletion)
[Dave]
almost gone..
[AllenBr]
Gone.
[chris]
resolved: drop d-ar006.8
[AllenBr]
6.9
[chris]
resolved: drop d-ar006.9
[Heather]
not meaning to regress... but has D-AR006.11 been discussed yet?
[Dave]
not yet, we're noodling on 6.10
[dougb]
getting at the specific meaning of this (new language, possibly not tied to WSDL)
[Heather]
It should be possible to augment WSDL with security policies
Is there a reason we need a 'new' language?
[AllenBr]
break 6.10 into security policy description and binding of such description to endpoints
[Dave]
+1 to allen's suggestion.
[Heather]
binding to endpoints would be part of wsdl i assume
and the sec policy description my be a new document type?
[dougb]
I think that's the general consensus, though said consensus may not be complete.
[Dave]
I would assume that the security wg would do whatever "it" is.
[Heather]
I agree with the POSSIBILITY that security policy may be expressed independently of WSDL... but I'm not convinced
Can we allow for the freedom without requiring the distinction?
[Dave]
Heather, I tend to disagree with you on separation from wsdl. <xhtml> is a very fine document format, imo.
[chris]
resolved: ar006.10.1 WS security framework MUST provide a means of expressing security policy.
[Heather]
Dave, to clarify, you think that security policy requires a new language?
[chris]
resolved: ar006.10.2 WS security framework MUST provide a means to access a web service's security policy
resolved: replaces ar006.10
[Heather]
does 10.2 mean a means to bind the policy to an implementation (endpoint)
[dougb]
I think so but we're moving along to 6.11 - Joe may be about to be voted down...
[Heather]
IBM thinks 6.11 is Out of Scope
[Dave]
I think so, in that I assume security wg may provide how to annotate wsdl or namespace name doc or uddi or .... with security policies
[chris]
resolved: d-ar006.11 is dropped
[dougb]
... 6.12, four arguments at once
[AllenBr]
Martin: common syntax for policy related assertions--a general language of oughts.
add autiting to the glossary
[chris]
resolved: add "auditing" to glossary so that people understand what they are agreeing to
[Heather]
I don't see a 6.12...
[chris]
resolved: add ednote to D-AR006.12 that glossary definition pending
[dougb]
Heather, more recent draft http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html
[Heather]
auditing of what?
[AllenBr]
Many questions about what 6.13 means
David O: drop since management is covered elsehere.
[dougb]
Heather, one hopes context will be part of auditing def'n
[chris]
resolved: ask darran to simplify and explain by next con-call d-ar006.13
[dougb]
also ask darran to explain need for this seperate from 18?
[Heather]
I'm not sure security management is part of general management
and probably should stay with security
and i agree it needs more discussion
[Dave]
hmm, a consistent meme to David O suggestions. Perhaps I could come up with a shorthand ;-)
[dougb]
Heather, we're off for a 20m break
[Heather]
whew! i NEED one too.
thanks for trying to keep me involved guys, I really appreciate it
[chris]
glad to have you lurking... too bad the telcon didn't work out
I see mike is also lurking?
[mchampion]
Yup, thanks for putting so much into IRC!
[chris]
okay, we're starting back up
[Heather]
k
[AllenBr]
Chris D-AC020 proposal at teleconference two weeks ago with wholesale replacement.
[dougb]
here we are considering recent proposal for D-AC020...
[AllenBr]
Chris: Can we adopt as is?
Roger: privacy concerns often irrelevant, the verbs are the problem
[Heather]
we aren't really enabling protection are we?
aren't we really enabling the expression and access to privacy policy?
[chris]
yes
[Heather]
and 20.1A should be 'SHOULD be able to make'
[mikem]
s/SHOULD/MUST enable/ is being suggested as a pattern to continue following
[Heather]
20.3A suggested wording change: 'must enable access to a Web Service's advertised P3P policy statement'
[AllenBr]
Daniel: Want privacy policies to be expressed in p3p if they exist.
[Heather]
I concur with Daniel on the 'if they exist' part
[AllenBr]
Daniel: reason for wording about domains is to assure that services not involving people actually exercised privacy policies.
RC020x should be AR020x! This is an action item.
[shishir]
Does it make sense to extend the notion of privacy policy to 'identity propagation', across multiple domains ...
[Heather]
Somehow I'd like to express that privacy policy support is not required to be compliant with our architecture... but if they chose to support it we should define how for them
[dougb]
Discussion about whether "If advertised privacy policy" phrase is necessary.
Proposal on table for 20.2 Web Service privacy policies MUST be expressed in P3P.
[Heather]
why remove advertised?
the only ones we care about are the advertised ones
[dougb]
latest from group: Advertised Web Service privacy policies MUST be expressed in P3P??
[Heather]
I like that
[dougb]
Passed, on to 20.3
[Heather]
I suggested adding 'advertised' in front of P3P
[AllenBr]
Hugo: Looking for flights from Paris to SJ. Web service has privacy policy. Give service email address. Service contacts other serivces using email address.
Other services SPAM using email address.
[chris]
resolved: AC020.1 The Web Services Architecture MUST enable privacy policy statements to be expressed about Web Services.
resolved: AC020.2 Advertised Web Service privacy policies MUST be expressed in P3P.
resolved: AC020.3 The WSA MUST enable a consumer to access a Web Service's advertised privacy policy statement.
[Heather]
+1
[AllenBr]
Daniel: why shoul instead of Must. David O: because not testable.
[Heather]
Architecture must enable seems ok... doesn't mean anybody MUST use it...
[chris]
right
[Heather]
are we arguing on 20.4 ?
[MChapman]
discussing not arguing
:-)
[Heather]
:-)
[chris]
yes, do you think it out of scope?
[Heather]
We need to say that if privacy is declared to be supported then the access cannot exceed policies
else we can't enforce this w/ architecture
[MChapman]
how can you test/detect that yiou have exceeded? thats what we are debating
[Heather]
esp if everyone expressed policies, but the infrastructure they are on don't enforce them
oooh, well, thats a toughie
[AllenBr]
Roger: Hugo's proposal is about propagating p3p info from one domain to another.
[Heather]
is there any guidance from the p3p community on that
[Dave]
oh no, we're arguing ;-)
[MChapman]
we are now
[AllenBr]
Daniel: privacy policy first presented to the user will not change during the transaction.
[Heather]
isn't the issue private data use instead of private data acquisition?
[hugo]
I'd say that acquisition is also use of it
[chris]
proposal: D-AC020.4 WSA MUST enable delegation and propagation of privacy policy
[mchampion]
Sorry if the discussion has moved on ... but all the WSA can do is define a "box" for privacy policy, determine if an existing spec defines it, and say "please respect it."
[dougb]
Heather, please note that we've deemed 20.4 out of scope and the above is a replacement, hitting on a slightly different aspect.
[Heather]
i'm not sure how we even enable delegation and propogation!
i concur the old 20.4 is out of scope
[Roger]
I think we're leaving that for a WG of the future.
[Heather]
ok
[Dave]
Heather, I'm with you on this one (again)
[Heather]
just can't resist last 2 cents onthis... we can enable expression and access to policies from client and service. Thats it
[chris]
resolved: d-ac020.4 out of scope
[Heather]
cool
[chris]
resolved: add D-AC020.5 WSA MUST enable delegation and propagation of privacy policy as draft
[Heather]
'as draft'????? whats that mean?
never mind...
[hugo]
that means that privacy experts will review it
[AllenBr]
Chris: distinguish policy enforcement from policy propagation
[hugo]
it is different from D-AC020.4
[AllenBr]
Chris: Move to AR004
[MChapman]
draft here meaning we havent agreed to it yet but also havent agreed to drop it
[Heather]
ok
[AllenBr]
That which was proposed didn't get into draft.
[Heather]
i can live with the fact that we need to talk about it more and its a separate topic
[hugo]
chris, can you drop the URL into IRC?
[Heather]
so there's no 20.5?
[hugo]
there is no 20.4
[AllenBr]
confusion of programming model/platform independence/device independence
[hugo]
Proposal: http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0031.html
[AllenBr]
Mike: generally wants to unify the notions of "independence"
Daniel: Three components obliged by charter, but not normative [in terms of the spec]
Chris; proposes to defer
004 tabled for now
Chris: exmine proposal or 10.1
[chris]
http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0000.html
[AllenBr]
Mike Champion, we are now doing 10.1!!
[mchampion]
thanks
[Heather]
k
[AllenBr]
Dave O: What kind of document can be gotten my dereferencing a namespace URI.
[Heather]
wasn't there an objection that RDF was not a syntactic schema language
[mchampion]
My position is that this wording should be rich enough to include XSD, RDF schema, some future ISO schema, etc.
[chris]
yes, I've expressed your concerns here
[Heather]
but who does the normative definition in the future stuff? us?
[dougb]
Dave O expressing an attempt to exclude HTML from this CSF, others worried "syntactic" also excludes RDF schema.
[Heather]
you're not arguing are you?
:-)
Can we declare XML Schema today and other representations may be normatively defined in the future?
[dougb]
Dave O: Thou shalt use XML schema when expressing syntax of messages for interaction with a web service (today)?
Hugo: RDF schema can solve all of the problems of the world.
[Heather]
I don't think DavidO's suggestion is so bad
[hugo]
dougb, I didn't say this :)
[dougb]
No, others still requested that it be minuted :-)
[hugo]
I said: if I had a technology solving all of the problems of the world and it were expressed with an RDF Schema and couldn't be expressed as an XML Schema, then we couldn't use it with this requirement
[mchampion]
Why do we need AC010.1 at all? The real requirement is captured by AC010, no?
[soliton]
architectual artifacts may be more easily expressed in UML.
[chris]
resolved: AC021
conforms to the internationalized character model defined in
"Character Model for the World Wide Web
Recommendation
we've tabled ac010.1 for now...
ac021 s/h/b ac022
[dougb]
... suggestion to forward "easy kill" suggestions to Chris (via email) for consideration before third cup of coffee tomorrow.
Chris: it's after 17:00, we're done.
[Heather]
when do you start in the morning?
[dougb]
9:00 our time
[Heather]
ok... see you at 3am.... yawn
good thing theres no video conferencing :-)
[soliton]
Heather, you are amazing.
I gave up after two days last time
[Heather]
we'll see how I do tomorrow :-)
[soliton]
it was really pain to get up at 2 am in morning.
[Heather]
I appreciate everyone trying to keep me up to date so I can participate
[soliton]
should we have a relibility meeting?
[AllenBr]
Chris: separate into to groups tomorrow morning to kill of easy outstanding items, while in parallel working on the scoping of the security WG.
[Heather]
solition: we can... when?
[hugo]
IRC log: http://www.w3.org/2002/06/12-ws-arch-irc
[soliton]
don't know yet, who else from the group are here?
[hugo]
ADJOURNED
[chris]
thanks guys for sticking it out on IRC!
[Heather]
Soliton... is Zula there?
and igor?
[soliton]
did not see igor
but zula seems to be here
hi, Heather,
let's try tomorrow, after 5:00 (here time)
[Heather]
k... ttyl then
have a fun dinner! I am so envious of the great french dining!
[soliton]
ok, have a good sleep
[Heather]
a nap is definitely in order!
[soliton]
they are really really good
you really should be here

Thursday 13 June 2002

[hugo]
hugo has changed the topic to: WSAWG face-to-face meeting; IRC log at: http://www.w3.org/2002/06/13-ws-arch-irc
[Heather]
good morning
[hugo]
good morning Heather
[dbooth]
Yowzer, you're up earlier Heather! (Or late!)
[Heather]
early.... yawn
how was dinner???
[dbooth]
I actually skipped the group dinner, cuz i had more work to do on my slides for today. But I had a nice quiet dinner at a cafe in front of my laptop.
[Heather]
you are too dedicated :-)
[soliton]
morning, Heather
Did you get the message yesterday?
[Heather]
about a requirements meeting after the meeting today?
[soliton]
we try to have a reliability meeting after 5:00 pm
so, just stay tuned
[Heather]
ok
[Roger]
Hi Heather. Is it 3 AM there?
[TomCarrol]
It feels like 3 am here
[Heather]
yes... its 3am
I haven't seen 3am since my last child was born!
[chris]
http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0435.html
scribe: tomc
[Heather]
Tom...must have been a good dinner :-)
[TomCarrol]
Comments on the rewording of D-AC002.3.1
[Heather]
i don't see an ac002.3.1....
[TomCarrol]
dougs email is listed above
[Heather]
I'm not sure I understand the wording still....
[Daniel]
which wording? old or new?
[Heather]
and what happened to the superset concept?
new
[Daniel]
I don't understand the new either, I support the old wording
we are trying to get at modularization
[TomCarrol]
D-AC002.3.1 tabled for further thought
[Heather]
subsets of what??? the architecture? the end user interface? Is this like a wsi profile?
[Daniel]
technologies developed for the arch.
ws-i profile is very similar idea
[TomCarrol]
Suggestion to drop "intended audience" from D-AC005
[Heather]
seems ok...
[dougb]
what was KIS^5 (simple, scalable, ...)?
[TomCarrol]
Roger: moves to accept it as is
D-AC005 accepted.
Comments on D-AC005.1
[Heather]
what is the gist of the comments?
[Daniel]
basically, ppl are arguing over the words, not the meaning
it needs some wordsmithing
[Heather]
ok
[Daniel]
we are going to explicitly modify the statements with the "should" qualifier
[TomCarrol]
JeffM: proposed to drop.
[Heather]
why?
[Daniel]
Jeff sez: it isn't enforceable
David O advocates specialized jargon
[TomCarrol]
DaveO: its all jargon and we will use jargon to describe web services
Those who care will resolve independantly.
those who care: Daniel and Alan
Comments on D-AC005.10
Accepted
[chris]
resolved: d-ac005.10 accepted
[Heather]
what happened to 5.5-5.8?
[TomCarrol]
Comments on D-AC005.13
[Heather]
what are exotic constructions?
[dbooth]
Can someone give me the requirements doc URL again?
[Heather]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html#AC002
[chris]
resolved: remove d-ac005.13
[dbooth]
Thanks heather!
[Heather]
np
[TomCarrol]
Comments on D-AC005.14
[Heather]
i think this one has no relationship to simpleness or completeness of the architecture
[Daniel]
*wonders how to tell if 5.14 makes any sense at all*
[Heather]
i propose to drop (if someone hasn't beaten me to it)
[Daniel]
we could specify the maximum cyclomatic complexity I guess
*not*
[Heather]
:-)
[TomCarrol]
DaveO: the goal as stated sounds good but there is no clear definition of what large amounts of code.
[Heather]
even a simple arch can require large amounts of code depending on how the vendor choses to implement it
[TomCarrol]
Roger: thinks it is important
[Daniel]
I just don't care how much code it uses...more != bad code
the amount of code is not a measure of its quality
[Heather]
i don't want us to NOT add valid components because they require large amounts of code
[Daniel]
right
[Heather]
i.e. security - there is NO way that bugger is NOT going to require HUGE amounts of code (by anyones definition)
[Daniel]
security = ugh
[Heather]
(I agree Daniel)
[TomCarrol]
JeffM: the union of all participants causes the size to increase
Roger: Its important that simple things must be able to be done in simple ways avoiding unessary complexity and size.
[Heather]
I agree with a csf of 'avoid unnecessary complexity and size'
[TomCarrol]
Roger: Cut it
[jeffm]
More precisely: the process of getting everyone to remove their "lie down in the road objections" often causes lots of extra complexity
[chris]
resolved: d-ac005.13 removed
s/13/14/
[Heather]
13? or 14?
[soliton]
Artifacts in the reference architecture should be defined in UML where applicable.
[TomCarrol]
Comments on D-AC005.15
[Daniel]
dear soliton: no bloody way
[TomCarrol]
Daniel: Drop it
[Heather]
having a goal to allow simple invocation styles may be something we don't want to lose
[Daniel]
Uml bears the same relation to architecture that theology bears to religion, that is, none at all
[soliton]
why? UML is well estabilished.
[TomCarrol]
Glenn: this refers to clean modularity
[soliton]
most programmers now are used to UML
[MChapman]
and is excellent to defnng architectures
[soliton]
it helps the spec to be adopted.
[Daniel]
I love UML, I teach UML, I don't abuse UML by attempting to do something with it that it is not good at i.e. architecture
[Heather]
what would you use instead Daniel?
[MChapman]
define architecture
[TomCarrol]
Gle to reword D-AC005.15
[MChapman]
blobs that interconnect
[TomCarrol]
Glen to Reword D-AC005.15
[jeffm]
From my perspective: UML is simply a language
[soliton]
soliton is puzzled by Daniel.
[Heather]
Glen to reword to capture what gist?
[Daniel]
I like SDML personally
[soliton]
how many of us know SDML?
[Heather]
i never even heard of it....
[Daniel]
UML is okay, for software applications
[soliton]
let alone average programmers
[jeffm]
What's SDML - Structured Data Manipulation Language ???
[Daniel]
but which of the 10 class 1 UML diagrams is good for architecture?
[jeffm]
#'s 3 and 7
[soliton]
component diagram
use cases
and so on ..
[Daniel]
hmmm...Jeff sez, collaboration and component...nowhere do I get to specify the messaging
[TomCarrol]
Glen: the rewording will worded along the lines of "every one can play".
[Daniel]
I am willing to give gound on this one, up to the point where we *require* UML to be used
[TomCarrol]
Chris: anyother low hanging fruit????????
[soliton]
where, in most cases you can specify the messaging
[MChapman]
wots messaging to do with architcture
[soliton]
note that I said "where applicable"
[TomCarrol]
Zula: did we dicuss 21??????
[Daniel]
architecture us *all* about messaging
us = is sorry
[soliton]
I don't quite agree on that one.
problem partitoning and use cases are also large part
[jeffm]
Daniel: will you allow UML to be used if someone wants to use it in a spec?
[Daniel]
sure
so long as it is not *required*
[MChapman]
it ceratinly should mean anything w.r.t conformance
should not i mean
[soliton]
did the word "should" qualify as your not *required* ?
[jeffm]
I think you're trying to stand up in front of tidal wave, but that's your choice
[MChapman]
yes sorry fingers to fast
[Daniel]
I'll go for "may"
[soliton]
I guess we can have a vote on the choice here.
[TomCarrol]
DaveO: He and Hugo discussed the XML schema (10.1) issue and found the usage of "should' would be acceptable.
[Daniel]
as Jon Bosak would say (about UML) "I want my data back"
[soliton]
how come 10.1 is not in the editor's copy?
[Daniel]
the business comics are not data, pictures are not data
[dougb]
because it's underneath 011
[MChapman]
pictures say a 1000 words:)
[soliton]
thanks, dougb
totally agree with MChapman
[jeffm]
I've seen these fights about requiring UML in other forums. What I've observed is that eventually everything starts showing up as UML, and pretty soon it becomes established in the culture. To the point where discussions of whether to make it mandatory or not becomes irrelvant.
[Daniel]
yeah but you can't get your 1K words back
actually Jeff, I'm pushing it hard in my org.
for the software devs
[GlenD]
Proposed rewording of D-AC005.15:
It shall follow the principles of well-modularized design to allow both extremely simple and more complex participants in Web Service interactions.
[omh]
that appears to work ok...
[jeffm]
Sure, like all new shiny "cool" toys (...err I mean tools ;-) people start trying to use it for everything. Eventually they settle down, and stop using the pliers to bang in nails (except when they've lost their hammer.)
[Heather]
where are the 'principles of well-modularized design found'?
[Daniel]
rephrase of Geln's proposal: "It will follow the principles of modularized design in order to allow interactions at different levels of complexity among Web Services"
You can read them here Heather: http://www.w3.org/TR/xhtml-m12n-schema/
[TomCarrol]
Resolution AC0010.1 accepted
[Daniel]
Jeff: I agree
[chris]
resolved: glen resolved: AC010.1 Each new architectural area that has a representation SHOULD be normatively defined using XMLSchema
[Heather]
the interactions are simple->complex... not the participants, right?
[soliton]
I like Daniel's rewording.
[Daniel]
right
[Heather]
how about 'in order to allow both simple and complex interactions with Web Services'
[GlenD]
+1 to Daniel's rewording.
Heather: I don't think that's general enough
[Heather]
but the participants are not always web services... so among web services doesn't seem right...
[soliton]
the complexity is about interactions, bot participants
[GlenD]
By "participants" I was trying to get at the idea that you can build simple or complex programs to do simple or complex interactions...
[TomCarrol]
Comments on D-AR011.1
[GlenD]
i.e. both design and runtime have a smooth spectrum of complexity if we do this right
[Heather]
so... complexity is about participants?????
[soliton]
so i'd stick with Danel's wording.
[Daniel]
we could change "among" -> "with"
[GlenD]
Or we can be more explicit
[Heather]
daniel's applies to complex interactions... not participants
[TomCarrol]
DaveO: The process takes care of this requirement.
[GlenD]
"It will follow the principles of modularized design in order to allow programs and web service interactions to smoothly scale in complexity."
[Heather]
i can live with this as daniel has it with 'among'->'with'
[soliton]
not as good as the previous one
[TomCarrol]
Resolved D-AR011.1 removed
[Heather]
not a lie down in the road
[chris]
resolved: d-ac011.1 removed
[Daniel]
whoohoo break time!
[soliton]
word such as smoothly will only cause confusing
[Daniel]
*participants retreat to their corners, breathing hard*
[Heather]
:-)
[soliton]
round 2 will start in 15 mintures
[Heather]
i'm just going to close my eyes for one minute....
[TomCarrol]
After the break the draft out line of the Arch. Doc
[omh]
see you in 4 hours then heather :)
[Heather]
:-)
[Daniel]
lol
[chris]
20 minute break
[GlenD]
"It will follow the principles of modularized design in order to allow interactions with Web Services at different levels of complexity"
That's my final offer. :)
[joe]
Hello wsa world!

Review of outline of Architecture doc

[David]
I've finally got the editors draft of the arch document on the site. It's at http://www.w3.org/2002/ws/arch/2/wd-wsawg-arch-06132002.html
the "wd" is actually incorrect, it's an editors draft
ok, reload the doc if you have already loaded as I updated the conceptualmodel.jpg based upon eric's updates.
[Daniel]
did Heather go off to sheep-land?
[chris]
okay, we're baaaack
[Heather]
i'm back
barely
[Daniel]
you're a trooper anyway
[soliton]
where is the jpg?
[David]
soliton, it's referenced in the arch document
[soliton]
oh, i see.
what is the url for the arch doc?
[Heather]
we always saw QOS as a vertical like management and security
[soliton]
agree with heather
[Daniel]
hey Heather - you are from IBM, aren't you supposed to say "seperation of concerns"?
[hugo]
Document discussed: http://www.w3.org/2002/ws/arch/2/wd-wsawg-arch-06132002.html
[David]
lol
[Heather]
i may just be sleepy... but having qos as a verticle does allow us to do something appropriate (and perhaps orthogonal) at each layer of the stack...
[David]
Heather, I've got RAS still imprinted on my forehead...
[Heather]
:-)
[David]
Heather, we're not *quite* talking about the diag yet...
[Daniel]
Roger: you can get the xmlspec.xsl at: http://dev.w3.org/cvsweb/spec-prod/html/xmlspec.xsl
[Heather]
ok... I'll wait my turn
[chris]
we're on the conceptual model diag now
[Heather]
can someone capture the gist of the conversation for me???
[chris]
now we're on system diag
david is describing intent of these diags
conceptual model is to basically identify the related concepts
[TomCarrol]
We are now on the the stack diagram
[chris]
sect 1.3 overview (stack diag for starters)
[Heather]
I don't understand the caching block in this context...
[TomCarrol]
We are now on 2.3 Security
[Heather]
the bottom blocks are specs?
[TomCarrol]
Zula: What process are we going to use in completing this document????
[Heather]
pionted to by the concepts?
[TomCarrol]
Chris: the process will be; the editors will propose and then request input and revision from the group, in increasing levels of detail.
Chris: there should be frequent snap shots.
[Heather]
Can group members propose things to the editors?
[dougb]
Heather, we're not ignoring your comments. We are however discussing things at a significantly higher level at the moment. I'm sure we'll come back to the details / diagrams soon.
[TomCarrol]
Zula: What role do the CSF play within the arch doc?
Zula: particulary the models (ie security model)
DaveO: Security is every where that is why the security Bar is represented as it is in the conceptual model(1.1)
[jdmunter]
wrt to process, I propose that we are all contributors. Along with commenting on content already there, I should be able to send my initial suggestions to the editors for inclusion also.
[Daniel]
I agree Joel
[TomCarrol]
We are now refering to the outline and how various topics breakout.
[Heather]
me too
[TomCarrol]
Joe: Conceptual diagram how would you like feedback the list???
Chris: in general no the more specific issues should go to the list.
[chris]
joe: security should extend to transport
[TomCarrol]
Joe: would like to see security extend into the transport.
DaveO: What do you think of the Doc???
[Heather]
which part are we reviewing specifically right now
[David]
Heather, reviewing the outline and structure...
[TomCarrol]
Chris: Specifics go to the list, the goal now is to get agreement on the generalities.
[Heather]
in ibm we broke the wire stack into 3 'generic' topics: transport, packaging, extensions....
then we discuss soap in packaging
and headers in extensions
would this sort of organization help here?
[TomCarrol]
JeffM: where is the web service?
JeffM: How do these relate to the web Service?
JeffM: How do the thing in the document relate to the web service?
DaveO: Lets drill down on jeffMs point.
JeffM: how much work is this group going to verses say security wg???
Zula: Where the life cycle and conceptual model about services?
[soliton]
can I be on the queue?
queue+
[TomCarrol]
AllenBr: Security reachs through the depths as does reliability.
[Heather]
see my earlier remarks on organizing around generic concepts in the wire stack
[TomCarrol]
AllenBr: anything that has end to end could be vertical
[Heather]
transport/packaging/extensions...
[dbooth]
heather, would you mind putting your comments directly into this IRC channel?
[Heather]
I am, aren't I?
[dbooth]
oh, sorry, I see it was earlier.
[chris]
tomc relayed your previously posted comments
[TomCarrol]
Soliton: The doc should have the high level concerns and there relationships
Daniel: the "ilities" are all vertical and are broke out by domain and there are a number of them
[soliton]
hi, Daniel, can you also put my top level concerns on the flip chart?
[TomCarrol]
DaveB: the doc is a good start but the diagram does not work for me.
[dbooth]
s/does not work/does not have any meaning/
[soliton]
agree with DaveB
[TomCarrol]
chris: What are the characteristics of a web service?
Daniel: What is the meta model??
Mike: XMl/semantic web is the whole box (conceptual model)/?
Mike: We might want to group the ilities together?
Daniel: why does the doc talk about the semantic web?
[Daniel]
Daniel notes in passing that the diagram needs to have 'semantic web' removed. this is road-recumbent issue
[TomCarrol]
Chris: that question can be discussed when the author is present.
DaveO: what are the features that support the creation of a web service?
[soliton]
top level concerns: Interoperability,Reliability, Management, Web-friendly, Security
Scalability and Extensibility
[Daniel]
+extensibility
+scalability
LOL Zakim is an electronic moron
[soliton]
from the TLCs, we can see the merge of two important components: Management and security
[TomCarrol]
davidB: What is the universe? what is this thing? where does this thing fit in the universe?
[GlenD]
Just in time for the easy questions, Paul!
[soliton]
the universe starts from the big bang.
[Heather]
now we are boiling the universe... thats even worse than the ocean
[Daniel]
ROFL Heather
[soliton]
what is LOL?
[Heather]
laugh out loud
[dougb]
laughing out loud
[TomCarrol]
Glen: Are we trying to answer the distributed computing question?
[dbooth]
Soliton, see: http://searchwebmanagement.techtarget.com/sDefinition/0,,sid27_gci211776,00.html
[TomCarrol]
Daniel: Web services are a sub set of Dist. Computing.
[Heather]
we must certainly answer a lot of questions related to distributed computing at any rate....
[soliton]
THX, DB
[jdmunter]
I add a "+1" to heather's latest comment
[Heather]
tom.. whats going on...
[TomCarrol]
The discussion is revolving around the relationship between the web and web services
specificly the scope the web services context
Glen is taking about node interacting using infosets
Heather: Does that help?
[Heather]
yes (watching a silent irc is hard at 6am :-) )
[TomCarrol]
Sorry, unskilled scribe
[Daniel]
Martin says we should levelrage Corba-like ideas for WS as well as web ideas
[Heather]
what is the gist of glen's point? that web services are nodes interacting using infosets? or that the web is?
[Daniel]
leverage even
[Heather]
i agree w/ martin...
[Daniel]
so do I...seems everyone does
[TomCarrol]
Daniel: Web services is a layer on the web stack
[Heather]
we should allow for the chance that web services will modify/expand existing layers of the web stack
[dougb]
Heather, the web versus web services discussion continues. Possibilities such as 'web services are a subset of the web', 'bringing COM/CORBA to the web', 'adding useful concepts from COM/CORBA to the web',...
[Heather]
we are adding new functionality to the web... it is possible that it won't cleanly layer
[TomCarrol]
JeffM: the problem space faced by Main frame application domain 20 years ago is similar to the one we face now.
[Daniel]
heather, that is just what I said :)
[Heather]
dougb... add web services are a superset of the web t the mix
[dougb]
another idea suggested in the room: looking at mistakes / problems from earlier attempts to solve distributed computing and attempting to avoid same
[Daniel]
dit's clear that COM's problem was/is that it is proprietary
CORBA's problem was that it added too much complexity
and still didn't work right
we need to avoid either overengineering the environment or making it so complex it is overexpensive
[Heather]
those could be the morals of the distributed computing fables.... but I'm sure there are MANY other lessons learned from our collective experience with distribted systems
[Daniel]
true heather...but I only have a single line interface to describe them! :)
*the margins of IRC are too small to contain my solutions!*
[omh]
Hmm - CORBA was not really complex - major issues were the connected nature of the interactions and the requirement for client libraries...
[soliton]
loose coupling, loose coupling and loose coupling
[Heather]
avoiding overengineering is a noble goal
[soliton]
perfer messaging over RPC
[Heather]
catching the 80% first with simple approaches
[jeffm]
messaging and RPC are equivalent
[dougb]
we've got a sheet containing a few other lessons: general issue described is 'end to end stuff addressed up front' with security, versioning and reliability as subtopics.
[jeffm]
the difference is in the failure modes and when failure occurs
[Daniel]
Jeff: no, RPC is just one kind of messaging, a subset
[dougb]
solitron's point about loose (versus tight) coupling also appears
[David]
DaveO Comment: architecture groups often fail because of not solving immediate problems...
[Daniel]
not equivalent
[TomCarrol]
DaveO: Past problem.. Trying to consider everything up front.
[soliton]
agree with Daniel
[Daniel]
DaveO is talking about the "Big Design Up Front" problem
[Zakim]
hugo, if you meant to query the queue, please say 'q?'; if you meant to replace the queue, please say 'queue= ...'
[Daniel]
iteration addresses this
[soliton]
ok, iterational design
[jeffm]
I can sort of agree. Except I *think* I can describe/implement everything a "messaging system" via an RPC system. And vice versa.
[Daniel]
in an unknown problem domain, BDUF will not work
[soliton]
that is true jeffm, you can alwasy do anything with 0 and 1
[jeffm]
ok, ok - turing machines rule!
[TomCarrol]
Martin: the real problem is ensuring all the security hooks are in each level
[soliton]
but the point here is that an extensible messaging is better than strict RPC
[MChapman]
do all of us on here pass the turing test:-)
[dougb]
does Zakim?
[Daniel]
not me, everyone thinks I am a col-dblooded architectural machine! :)
[Heather]
but there are some messaging patterns that are hard for rpc to deal with...
[soliton]
from other people's point of view, we all sound like machines
[Heather]
mutliple output response messages...
[dbooth]
zakim, do you pass the turing test?
[Zakim]
I don't understand your question, dbooth.
[TomCarrol]
DaveO: Are we going to run the group a by taking the union of the group or by taking the intersection of the group will all for more meaningfull work
[soliton]
hi, zakim, do you have feeling?
apperantly, zakim fails the test.
[jeffm]
With "extensible messaging" (isn't all messaging "extensible") there are really only 2 operations (aka RPCs) get(bag of bytes) and send(bag of bytes)
[Heather]
apparently it does, you have insulted it and its not talking to you
[dougb]
zakim, do you have feeling?
[Zakim]
I don't understand your question, dougb.
[jeffm]
The system is designed so that essentially get and send never fail.
[TomCarrol]
DaveO: Are we going to run the group a by taking the union of the group or by taking the intersection of the group will allow for more meaningfull work
[Daniel]
lunchtime...saved by the bell
[jeffm]
Instead the failure occurs when you try to interpret a bag of bytes that you've never seen before and have no idea what to do with it
[hugo]
Meeting resumed
[Roger]
dbooth, take a look at http://www.opencyc.org
[dbooth]
Roger, here is the TAP site, the project at Stanford that has the demo of a semantic search: http://search.alpiri.com/wsi-bin/flek.wsp/tap?term=boston&method=search&locate=1&btnG=Search

Review of Glossary draft

[TomCarrol]
Review of the Glossary
[Heather]
ok I'm ready
anyone else out there remote from the F2F?
[zulah]
Tom, I can't take notes due to poor connection over here. Will fix and then take over
[Eric]
I'm remote
[mchampion]
I'm remote
[Eric]
I've dialed into the concall number but it says I'm the only one on it
[quit]
tom, I can take over with notes. WOuld you like this?
[Heather]
the phone in the room does not work
as far as i know there isn't any phone support... just IRC
[TomCarrol]
AllenBr: The glossary only contains the lexicon and as the document goes foward what structure should the glossary have? where do we draw the boundries of the document? ihow are the ilities incorporated into the glossary?
[Heather]
so we are at their mercy for details...
[Dave]
zakim, Dave is DaveO
[Zakim]
sorry, Dave, I do not recognize a party named 'Dave'
[Dave]
zakim, Dave is known as DaveO
[Zakim]
I don't understand 'Dave is known as DaveO', Dave. Try /msg Zakim help
[Dave]
zakim help
[TomCarrol]
Daniel: are we going to share this glosary with the rest of the web services activity?
[Dave]
sigh
[dbooth]
zakim, help
[Zakim]
Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help.
Some of the commands I know are:
xxx is yyy - establish yyy as the name of unknown party xxx
if yyy is 'me' or 'I', your nick is substituted
xxx may be yyy - establish yyy as possibly the name of unknown party xxx
I am xxx - establish your nick as the name of unknown party xxx
xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
xxx also holds yyy - add yyy to the list of participants in group xxx
who's here? - lists the participants on the phone
who's muted? - lists the participants who are muted
mute xxx - mutes party xxx (such that 60# will not work)
unmute xxx - reverses the effect of "mute" and of 61#
is xxx here? - reports whether a party named like xxx is present
list conferences - reports the active conferences
this is xxx - associates this channel with conference xxx
excuse us - disconnects from the irc channel
I last learned something new on $Date: 2002/06/26 15:33:51 $
[Dave]
zakim, I am DaveO
[Zakim]
sorry, Dave, I do not see a party named 'DaveO'
[hugo]
Dave, try /nick DaveO
[TomCarrol]
Chris: there is no cononical way to organize the glossary?
[mchampion]
Open the pod bay door, Zakim ... I can't do that Dave, you're planning to unplug me :-)
[DaveO]
wahoo
[hugo]
Zakim, only knows about people connected to the phone bridge
[Zakim]
I don't understand 'only knows about people connected to the phone bridge', hugo. Try /msg Zakim help
[DaveO]
*double sigh*
[scribe]
Chris: how self contained is this document (what is the scope of the glossary).
[zulah]
Tom, would you like me to take over scribing now? I seem to have my connect problems fixed.
[scribe]
What do we do with terms that have multiple definitions?
Allen: Each definition must be able to reference the author.
Joe: Once the term is in the glossary. the term would then be reserved.
[Heather]
words in dictionaries have multiple meanings in differnet context's, wouldn't that be true for glossarys as well?
[scribe]
Joel: The glossary should have as much detail to clearly identify the definition of the term given its context.
Chris: a singular glossary provides single reference point for the associated working groups.
Roger: is the keeping one glossary feasible? given the differences between the working groups.
[Heather]
i would think it would be feasible and NECESSARY within the web services activity
[scribe]
DavidB: Multiple definitions are possible and may be necesary. It the nmultiple def. case the context must be defined.
[Heather]
agreed
[chris]
source, context, owner/authorship, multiple definitions allowed, but not preferred
[Roger]
Heather - look at "Service" in the existing glossary.
[dbooth]
Another term for "context" is "field of use"
[Heather]
i'm looking at Service...
it says 'collection of endpoints'
[Roger]
There are two.
[scribe]
Chris: comments on the glossary should go to the list along with additions.
[Heather]
it would help if this were in alphabetical order
[scribe]
AllenBr: Please provide sources with your additions.
[Roger]
Stylesheets are envisaged yielding different organizations.
[dbooth]
Heather, Allen said he can generate aphabetical in the next pass.
[Heather]
so there are 3 definitions for service... 2 in that one and 1 on the first page
thankyou allen
[Roger]
I just thought that they were amazingly different.
[scribe]
We are now talking about WS security working group
[Heather]
how are we reviewing the glossary? Term by term?
[scribe]
chris: How big is the WS security WG? what do we need to see in the group?
Joe: Lets start with the requirements that we already have.
Glen: We should be framing the security problem.
[zulah]
I am scribe
zakim, I am scribe
[Zakim]
sorry, zulah, I do not see a party named 'scribe'

Brainstorm of security WG scoping

[scribe]
Chris: the question is, do we see a ws working group as the working group that solves world hunger for mankind or a specific targeted focused WG?
Chris: somewhere between the two extremes?
DaveO: I made a pitch in email about what a rough starting set of requirements would be.
DaveO: Let's have a security group talk about a framework, details of a trust model, task it with specific technological soluntions to authentication, integrity
DaveO: encryption
DaveO: knowing that there are others (e.g., Authorization, non repudiation),
DaveO: This is a starting point pitch
Daniel: Just in terms of the scope the ideas are good. We should confine the cope to not include world hunger. Confine it to security problems specific to WS architecture.
Daniel: Confine the scope as much as we can. Take advantage of others work
Chris: Just as a baseline, the WS activity is not charter to go beyond the bounds of WS
Chris: So you are saying not world hunger even for web services?
Daniel: yes
JeffM: We have requirements, we should pick a subset of generally useful requirements (relevant subset)
JeffM: pick pieces and fill in terra incognito. Whatever set of requirements that we choose it must address and end to end case.
JeffM: it doesn't have to be all cases but one in depth
Roger: question? is there another axis? On one extremem you make up new languages and syntaxes, on the other there are existing solns. with recommednations on how to put them together.
Roger: Which is our job?
Chris: In making our recommendation we have the option to propose putting pieces together or additions, changes
Roger: No, will this group in the process of creating the architecture specify which pieces to make security work (specifically).
Chris: we cannot dictate soln. We can provide baseline.
Roger: No, will there be components of security solutions in the architecture?
Roger: DaveO: Say we decide that we should have auser name/password for authentication then we will say this in architecture and charter.
DaveO: If a WG tells us that we a re wrong, we will fix it in the document.
Roger: If I am trying to implement WS and I use the arch document, will there be any answers in there for how I implement security?
Joe: General guidelines but more specific will come from security group.
Glen: In other words, not really just like we don't say specific things about implementing transactions.
Chris: But we can provide starting points (e.g., XML digital signatures exists, use it).
DaveO: What I think is being asked is what is the authority of the arch group in binding things? So if we say use Dig sign. is this authorotative.
Chris: At best we can influence.
[Daniel]
Heather you're up
[Heather]
k
[hugo]
I think that it depends on how our recommendations are phrased
[Heather]
I'm a little nervous about giving a new security wg carte blanche to develop a new security framework
it smacks of architecture groups having baby architecture groups
should we provide a 'broad framework' as part of our work
leaving them to figure out how to implement those components w/ existing specs and new specs?
[scribe]
Joe: Would like to help move the process along by returning to the six items from the requirements doc. 1) authentication, integrity, encryption, 2) authorization, 3) NR, 4) accessibility (DOS), 5) rest of the stuff in CSF and requirements. He suggests that this is the prioritization.
[Heather]
ok.. thats it
[scribe]
DaveO: I agree
[tomCarrol]
+1 on the framework
[Roger]
Heather, what did you mean by
[jeffm]
heather, you're stuff is up on the board
[scribe]
DaveO: I think that heather is getting at the fact that the framework has to have some detail to provide constraints. We are not writing a blank check.
[Roger]
"OK, that's it".
[jeffm]
s/you're/your
[Heather]
by 'ok thats it' i meant </Heather>
[scribe]
Joe: We need to supply detail? Yes because this lends credibility>
[Heather]
or end of tirade
[Roger]
Thanx.
[scribe]
TomC: I was wondering if when we send a WG off to work, are we also going to privide a well defined process for making changes back into the architecture
[tomCarrol]
Mchapman your up
[scribe]
Summary: We own framework, set context, but offer a process for feedback into changing the architecture.
Martin: Question is, when we charter the security group, do we pre-phase them or only charter them for a specific phase?
Daniel: this is how SOAP works today.
Summary: One working group with phasing (or re-chartering for each phase).
Martin: So what we should be debating is phase 1
[Heather]
+1 for rechartering for phases
[scribe]
OIsio: Point of process, needs to be some life after wreck process so that there is some formal manner to make changes.
DaveO: How convenient. I asked TBL how ammenable the director is to us rechartering in mid flight. HE said go for it, no blank check but time to market is important. I interpret this as a broad endorsment to get this stuff out there.
DaveO:No change to the process document. Its the willingness of the AC.
DaveO: Process does not mean that we have to do things slowly
AllanB: There is another kind of structuering that comes from the overall architecture. YOu can imagine doing security at the messaging level. You can imagine role security at the orchestration level. These offer a basis for constraining what kinds of things are considered in each phase.
AllenB: So phase 1 could be messaging security.
Joe: Good point. For his priorities, these can be done in multiple ways: messaging, etc.
[Heather]
define messaging security for me...
[GlenD]
security on a per-message basis
[scribe]
AllenB: So there is more than one dimension to this and we can look at the matrix and determine what we want to fill in.
[GlenD]
as opposed to securing a channel (ssl)
[Heather]
could also match phase.... define their phase one in corresspondence with our phase one
[GlenD]
phase-locked groups
[scribe]
Daniel: following martins earlier suggestion that we iterate on phases. We should pick the highest priority probelms and ask the security group to address them in the first pass (and so on). Dave has identified the high priority items. We should phase as probelm in priority (as opposed to as solutnions).
[DaveO]
I think Allen proposed that there is another aspect of security, that there are the styles of security: message, connection, role based (e.g. for orchestration)
[scribe]
DougB: Have the security WG recognize the boxes that we provide them mapped to existing standards. Is that our job or some WGs job?
DaveO: Great.
DougB: Does the security group recognize existing standards and fill them intoboxes or does the arch team do this (clarifiation)
DaveO: this came up on the tag. They felt that it was disirable for the arch group to provide details in fleshing out the scope of the box.
Chris: Again, all we can do is hope to influence.
Joe: Are we going to do the threat model in WSA or by the new WG?
[dougb]
higher level question Joe and I are getting at: Are we writing the security portions of our architecture document (referencing existing standards and the threat model) or is the Security WG doing that?
[scribe]
Chris: The order of the requirements document did not imply that we had prioritized.
[Heather]
if we are going to lay out the high level framework and boxes, we may have do some level of threat model
[scribe]
JeffM: As part of this discussion, will we consider the end to end case. Pick a couple of scenarios as examples and do the analysys so that we scope this by end-to-end for specific technologies as opposed to just stating messaging security.
Chris: Did you mean use cases?
JeffM: yes, the high level ones.
[DaveO]
lol
[Daniel]
Dave loved that :)O
[Heather]
:-)
[scribe]
martin: even though we work at the same company ;) I want to really support this. Working solutions are importnat...
Chris: in our current scenarios we describe stack type stuff. Are you going vertical or horizontal?
[Daniel]
Dave and I used to be friends! that was back in XML-CORE days tho
LOL
[scribe]
Martin: All the way down and then back up again.
Jeffm: When some people think end-to-end they think multiple hops, routing, etc. and that's not what I mean. What I mean is that whatever use case we pick, we do it end-to-end.
Chris: Do we care about multiple hops or is this phase 2?
Martin: What is multiple hopS?
[DaveO]
It was the large trout aspect, not so much the recipient ;-). I do prefer salmon, but I'm from the west coast of Canada...
[scribe]
Martin: My point is that I want to see a full working solution between client and server as opposed to chunks of security that don't fit together.
[Heather]
security info propogation is going to be an immediate problem...
+1 to martin
[scribe]
DaveO: suggestion to deal with this is to do a use case and soe usage scenarios that treat particular aspects of the end-to-end.
[dougb]
+1 to DaveO, subject seems to depend upon use case chosen to frame security WG / also appreciate Martin's extreme programming (extreme architecture?), continuously working process.
[maa-in]
+ extreme UML :-)
[Daniel]
it's nothing to do with extreme anything, it's basic UP iteration
[scribe]
Chris: Here's what I hear: Not boiling the ocean. Targeted. We have suggestions for different approaches or synergisitc approaches for how we might determine prioritization. I sense a stronglevel of rough agreement as to end-to-end solutions. We have a notion of phases. that we start something off and it evolves. We may need overlap of working groups due to market forces.
[tomCarrol]
To be complete would we not need a complete set of use case that describe a web service and use those for the context of the security WG??
[scribe]
chris: break at 3:30. Afternoon for use cases. Right now, could we given this ... pick a prioritized subset of joes and allens suggestions for a phase 1 charter? Can we do that now?
DaveO: We have atleast one use case already - Hugo wrote it. Why don't we look at it and work the process?
martin: Let's narrow the use case for securiyt aspects.
Chris: We have Joe's onion, let's focus on the core of the onion. and thinking about phase 1 only.
[tomCarrol]
Would we want to narrow the use case or would that be delegated to the security WG
[scribe]
Chris: How do we want to break up?
Daniel: want to tackle high priority stuff.
Roger: You could also (in parallel?) tackle the EDI use case
Chris: Of #1 (auth, integrity, confidentiality), what would go into a phase 2?
Joe: It is useless to do integrity and confidentiality alone.
Chris: So is #1 too broad, do we want to further narrow it?
Daniel: Maybe there is some low hanging fruit here because a great deal of work has been done on some of this (e.g., auth and authorization).
DaveO: The solutions and how they deal with XML and the web have not been around. We are just starting to see first proposals on some of these.
Joe: More critical problem for XML encryption is key districution. All we have talked about is message level security but channel level security has been around and that's low hanging fruit.
Daniel: I would rather talk about problems that solutions.
DaveO: but solutions introduce problems. So which of the new problems do we wish to tackle.
DaveO: the process model one is really interesting. This has come up with XML. Can or should an author be able to indicate the steps a recipient should do with a particular message...
DaveO: default processing model, explicit one... clearly in WS we have the same issue. How does a reciever specify the processing model that it will publish to the world.
[Daniel]
do we think we want to adopt/s[pecify a particular processing model?
[scribe]
DaveO: e.g., i will do integrity checks after confidentiality. So sender mus invert this. Security clearly introduces a processing model. We should stay away from tackling this right up front ("there be dragons").
Joe: true for message based but channel based already solved.
DaveO: Missed point, the order that you do things is either the canonical order or you have to publish processing orer.
Chris: Okay, how are we going to divide up this work?
DaveO: suggest taking hugo's use case and then breaking it up around 3 scenarios (auth, integrity, and confidentiality.
Chris: Hugo, do you want to walk us through the use case?
[hugo]
Travel agent use case: http://www.w3.org/2002/06/ws-example.html
[scribe]
Chris: 15- 20 break...
[Heather]
whew!

Review of Travel Use Case

[scribe]
Hugo: Will present travel agent use case.
Hugo: There is a customer that wants to use travel agents service to book vacation package. Travel agent service will use hotel and irline, credit card co. web services.
Hugo: I divided the use case into 4 usage scenarios. which are basically the steps that the whole thing will go through to book the vacation package.
Hugo: Of course I made simplifications - security is not considered at all.
Hugo: If you want to go step by step, its complicated.
Roger: Wants to quibble. In talking to people who wanted to use web services. When dealing with credit card service, you are dealing with something that is already firmly in place and is not going to change.
Martin: So there are definitely actors, either people or external systems.
Roger: My point is that it is unlikely that these will operate as ws in the new future.
DaveO: Point is what things would look like using ws technology.
Roger: make this point because if you are prioritizing, some legs of a use case are unlikely to change in the near future so they are low priority.
Hugo: Even though parts of the use case won't be used for a very long time, they are still illustrative.
Hugo: User requests travel for some travel dates. Hugo has a complex diagram for this in his document. The customer provide the travel agent some travel dates and the service discovers airlines and then gets descriptions of how to interact with those. So the ontology thing means that the descriptions made sense to everyone (magic).
Hugo: So queries are made, results are returned, merged and sent to the customer. The ustomer chooses and the travel agent service books the flight.
Hugo: Then moves to the hotel reservation (which works much like the airline situation).
Hugo: From here, (purple stuff), when consumer boks hotel, the trravel service gives the cutsomer payment options. The travel agent service interfaces with the credit company to get a guarantee of payment.
Hugo: At this point (Next diagram), the travel company has confirmation and then books the hotel with the credit information. Travel agent company creates vacation package and bill.
Hugo: Security wise, there is confidentiality, credit card company stuff (certificates and guarantee) - identity, encryption for credit card number.
Joe: Integrity cwould come into play since you don't want someone to change your data (london to paris) in transit. Authorization as well.
Roger: We havea system in our company that works exactly like this today. If we want to make this realistic, we could determine exactly how these work. There are sll sorts of elaboration that happen in reality. For example people doing travel on behalf of another person.
DaveO: this is a great start. There are issues of communication, QOS, Orchestration, etc. I love the travel service kind of use case.
[jeffm]
+1
[scribe]
Joe: You can build this up. So you could add NR, etc.
[jeffm]
jeffm: +1
[scribe]
Martin: So, what's the end-toend minimal thing that we need to do to make this secure. The customer looks up something and books, how do we make this minimally secure.
JeffM: Instead of taking the whole thing as and end-toend we could take "little t" transactions and deal with each.
Jeffm: security group might be chartered for little enchilada as apposed to the whoole thing (presumably staging).
Roger: The odering has to do with what gets done first and what is needed first. There are portions of this that are cast in stone (the real world). Some of the example doesn't need to be dealt with in the near future.
TomC: I tend to agree with the Oracle crowd. At a certain level of abstraction, in order to identify the meaningfl parts for a security WG we have to get to lower level parts of the use case.
Jeffm: explicitly not trying to determine which things have to be done first.
[jeffm]
To clarify: I'm suggesting that what is done first is the end-to-end security for the entire steel thread(s).
[scribe]
Chris: So if I want to pull this apart: How do we know that its hugo, integrity, confidentiality,
Thanks Jeff ;)
[jeffm]
Clarify(cont): The prioritzation task is picking the "right set" of steel threads to scope the first phase.
[scribe]
Tom: familiar with the eprocirement scenario. You have to look at the small use cases one at a time. That is you don't get to pull the security areas out one at a time (integrity, authorization,etc.). Must find pertinent use cases in order to define a domain.
martin: You didn't mention authorization or permissions.
Chris: They are all there.
Chris: Key point is getting to the point that roger was making, we could do all of the security things (1-5) or...
CHris: we could do them all, we can parallelize based on specific aspects. In terms of encryption where you have only a credit card number, did you really need XML encryption?
Joe: You could do this two ways (SSL is option).
Chris: Integrity is fundamental (due to multiple), authentication is fundamental, and confidentiality. can we focus on just these three.
Martin: The scenario has to touch on all of them otherwise you will miss something. The steel thread must address all points.
Joe: This is what he was refering earlyier to the minimal set.
Roger: Does not like the use case because he doesn't see the business driver.
Roger: sees apples and oranges of existing systems of different types. He really wants to show the EDI use case because it is different and the business drivers are clearly displayed.
DaveO: In terms of the break up, another way to tease out requirements is to look at what is going on in terms of the channel (e.g., email). So this type of variability might be another way to go in terms of structuring this.
Martin: This use case represents 80% of what the web is used for.
TomC: On rogers point, views the use case as an abstraction (that is that you can abstract out the business portion - the travel agent). The trust model varies based on what side of the travel agent service I belong to. I have trust with suppliers that is completely different that with the general public. So security may be completely different and require completely different technical implementations.
Hugo: Martin said that we should have a look at everything rather than limiting to the 3. If we have a look at everything, everything will be large (e.g., privacy).
Joe: Responds to Roger's use case comment. Can cover all of the security aspects with buying a book from Amazon.com. The EID use case could be different because it is intranet.
Roger: Not intranet, its an internet example!
Glend: two tiny comments. Regardless of whether the use case is connected to reality, it is still a useful scenario. Can we ask Roger to do a short description of his use case.
[chris]
q close

Review of EDI Use Case

[scribe]
Roger:EDI like interacteraction betweek big and small company to to purchase widgets it is interesting because small company has different capabilityies and security aspects and guts happens when things go wrong.
Mike: How does this use case differ from the travel agent?
[chris]
ignore q
[scribe]
Roger: Assumption here is that you have trusted partners.
[Martin]
q martin
[chris]
zakim, ignore q
[Zakim]
I don't understand 'ignore q', chris. Try /msg Zakim help
[chris]
zakim, ignore queue
[Zakim]
ok, chris, I will ignore the speaker queue
[scribe]
DaveO: I have built SOAP systems doing exactly this. If you take how vendors talk about ws. IBM developer site is example. They use travel, others use this example. This is a connonical exmple for doing WS.
[jeffm]
jeffm wonders where chris is
[scribe]
chris: we don't have time to do the break outs. Suggests that we let Roger present his use case for 5-10 minutes.
Roger: I talked to our EDI people about what they actually do and how they would be interested in useing web services and here's the scenario. You havea big company trying to buy widgets from a small mom and pop co with a big technology difference. We actually want to do this.
Roger: Actors: Engineer, business analyst, lots of people. mom and pop and uncle on weekends.
Roger: Request for purchase, purchase order, request for invoice, purchase, payment.
[hugo]
EDI use case: http://lists.w3.org/Archives/Public/www-ws-arch/2002May/att-0323/02-WS-EDI_Use_Case.htm
[scribe]
Roger: Focus is technical infrastrcutre not the buisiness process. Payments are explicitly out of scope. Because banks have their own processes.
Roger: This is how process works when it works. This is less intereesting than when it doesn't. He has a list of requirements, check the use case for details. It is required that messages are ordered and identified with unique ID but not sequenced.
Roger: Security problem: NR, accessibility, authentication. NR is a lower level than NR but higher than auditing because it is a trusted business parter. No one is going to court over a failure. You just need somewhay to determine what happened.
Roger: So you need to reconciliate. So, the problems in the process are the real meat. This is where people spend their time. Transactio n log mismatch. At the end of each moth the big co will send a list of messages received to small co. The response is checked against the back office to see if there is message agreement.
Roger: Second scenario is that small co thinks that they weren't payed. (incorrectly). They didn't get a payment advise(?). So they got paid bu they don't know it.
Roger: Big purchasing department ... big co sends copies of purchase information to little co, and then little co matches and determines that they were payed.
Roger: Finally, example where small co gets payed and this is similar to former.
[chris]
zakim, track queue
[Zakim]
ok, chris, I will track the speaker queue
[scribe]
Roger: Real important thing is to be able to determine what happened in the past.
Martin: This type of scenario is invaluable. Some things are not in the scope of web services. Alot of the use case is human use case.
Roger: I disagree. Ddifferentiates (human from machine) based on log information needed vs. actual reconcilliation.
Martin: What extra do we need to do to be able to prove that a payment was made (for example).
Roger: It is important that there is an agreed upon method for identifying messages (in time).
Roger: A standards query for getting digest of messages would be great.
TomC: Looks at the abstraction. The activity being performed is ... missed it
[dbooth]
Hmm, it sounds like he's talking about "unambiguously identifying things". Sounds a lot like URIs to me!
[scribe]
JeffM: If the requirement is to have a logging service, and the service has to support a DB query service then that is all that you need to say - that's a solution to the problem.
JeffM: doesn't see how the use case adds more to security.
Roger: I think that it is significant that the financial transactions are out of scope.
[Heather]
why are the financial transactions out of scope?
[dboo-scri]
GlenD: There are lots of scenarios. I suggest we do something to move forward. We've chosen to drill through a use case. We'll do (1) vote for one of these use cases; or (2) tonight you guys can combine them.
Roger: Or we could split and do both.
Heather: why are the financial transactions out of scope?
Roger: Because EDI people told me they were'nt interested in it.
s/EDI/my EDI/
[Heather]
why?
is there no interest from the financial industry to move to web services?
[dboo-scri]
Roger: Because it's done through the banks and the banks worry about it.
[chris]
because it gets handled by banks with lots of magical incantations
[jeffm]
roger says because his EDI people told him they didn't need to worry about it
[dboo-scri]
Tom: I think EDI has a lot of implementation issues. Reconciliation is tied to one side or the other -- not the technology.
Roger: There's a fine line btwn business side and tech side.
JeffM: We have two proposals for scenarios. Do we need to choose? Talk more?
Roger: If we have to choose, I prefer Hugo's, because it covers more of the arch.
Doug: Hugo's use case is a superset of Rogers. At some point the main WS will order something from the hotel.
[chris]
zakim, ignore queue
[Zakim]
ok, chris, I will ignore the speaker queue
[dboo-scri]
Tom: We're making assumptions about Hugo's scenario. Until you refine those smaller use cases, you'll never know.
... There are a lot of assumptions about what's going on.
Joe: I agree.
Chris: Straw poll: Should we tackle both use cases or only one?
(Result of poll was roughly equal)
[Heather]
just travel
[chris]
what are you doing in rahliegh?
cant spell
[Heather]
are you gong to break out?
[zulah]
Not today we aren't
[dboo-scri]
Tom: If we decide to split up based on various aspects of security, then we'll get more benefit out of looking at only one case.
[soliton]
hi, Zula and Heather,
are we still do the reliability meeting?
[dboo-scri]
GlenD: You'll never get all the way to the bottom.
[zulah]
Are we? I'm tired and would like to be out of here at 5:30-6ish.
[Heather]
soliton, sure
[Daniel]
no luck, it's use cases all the way down
[Heather]
but, i admit to being tired as well
[dboo-scri]
DBooth: Could they be adequately combined?
[zulah]
Okay, then, can we make it short and depending on whether or not this completes?
[dboo-scri]
Roger: I don't think so.
Chris: Straw poll: Who votes for Hugos versus Rogers?
(Result: Unanimous for Hugo's)
[Heather]
heather votes for hugo's too
[soliton]
ok, if this meeting does not drag too long.
[dboo-scri]
Chris: So I'd like to break up and look end-to-end at these various security aspects by breaking into groups.
... People should look at Hugo's use case and scenarios, such as HTTP.
GlenD: What will be the end result?
Chris: Do we have the right usage scenarios? Do they articulate the security constraints? Do they identify where we need to fill in the gaps? I'd like to see that.
... So we can use that for the end of tomorrow morning, for prioritization.
Roger: I suggest we make one of the hotels' be a small B&B.
Others: good idea.
GlenD: We should leave the choice of particular implementations up to the groups doing them.
... The MEP matters if you do channel level security, but for authorization it doesn't.
... Any implementation detail should be left to the group doing it.
Chris: But I want enough info out of this for valid usage scenarios to charter new WGs.
GlenD: But depending on the implementation decisions, the security issues can change very much. Therefore I want to leave it to the groups doing it.
Joe: As long as we cover all of the security aspects I'll know if the solution is ok.
Glend: There may be times that you'd need to posit "now we're using HTTP".
Chris: So tomorrow, Martin will lead one group, GlenD another, DaveO another.
Chris: Martin does Authentication, GlenD does Integrity, DaveO does Confidentiality.
MarkB: Is there somethign for a third party trust relationship?
Chris: We're focusing on a phased approach for chartering WGs. Objective is to ID the scope of the 1st phase WGs.
MarkB: At what point would that be addressed?
Chris: We have until mid July.
.. We should come up with 6 bullet items that you might see in a charter.
MarkB: I think we need to address the a priori interface for the 3rd party case.
DaveO: There are at least 3 scenarios: #63, 64, 61, 62.
[chris]
s63 authn, s64 integrity, s61& s62 confidentiality
[dboo-scri]
... Those point to solutnios, but they identify the things.
... But this would be the place to plunk our results.
MarkB: I can bring up my case in that context.
[Daniel]
take care all
[dboo-scri]
[Meeting ajourned]
[soliton]
ok, zula and Heather, we have a quick one on reliability
anyone else ?
[zulah]
Break quickly and then I suggest we take up AC007.
[soliton]
agree
5 minutes.
[Heather]
ok
[soliton]
anyone else from the Reliability task force?
[Heather]
im here
[MChapman]
just about to begin again
[hugo]
TAP demo: http://tap.stanford.edu/cgi-bin/w3csearch.pl?q=eric+miller&sitesearch=w3.org
Meeting resumed
[Roger]
dbooth, take a look at http://www.opencyc.org
[dbooth]
Roger, here is the TAP site, the project at Stanford that has the demo of a semantic search: http://search.alpiri.com/wsi-bin/flek.wsp/tap?term=boston&method=search&locate=1&btnG=Search

Review of Glossary draft

[TomCarrol]
Review of the Glossary
[Heather]
ok I'm ready
anyone else out there remote from the F2F?
[zulah]
Tom, I can't take notes due to poor connection over here. Will fix and then take over
[Eric]
I'm remote
[mchampion]
I'm remote
[Eric]
I've dialed into the concall number but it says I'm the only one on it
[quit]
tom, I can take over with notes. WOuld you like this?
[Heather]
the phone in the room does not work
as far as i know there isn't any phone support... just IRC
[TomCarrol]
AllenBr: The glossary only contains the lexicon and as the document goes foward what structure should the glossary have? where do we draw the boundries of the document? ihow are the ilities incorporated into the glossary?
[Heather]
so we are at their mercy for details...
[Dave]
zakim, Dave is DaveO
[Zakim]
sorry, Dave, I do not recognize a party named 'Dave'
[Dave]
zakim, Dave is known as DaveO
[Zakim]
I don't understand 'Dave is known as DaveO', Dave. Try /msg Zakim help
[Dave]
zakim help
[TomCarrol]
Daniel: are we going to share this glosary with the rest of the web services activity?
[Dave]
sigh
[dbooth]
zakim, help
[Zakim]
Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help.
Some of the commands I know are:
xxx is yyy - establish yyy as the name of unknown party xxx
if yyy is 'me' or 'I', your nick is substituted
xxx may be yyy - establish yyy as possibly the name of unknown party xxx
I am xxx - establish your nick as the name of unknown party xxx
xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
xxx also holds yyy - add yyy to the list of participants in group xxx
who's here? - lists the participants on the phone
who's muted? - lists the participants who are muted
mute xxx - mutes party xxx (such that 60# will not work)
unmute xxx - reverses the effect of "mute" and of 61#
is xxx here? - reports whether a party named like xxx is present
list conferences - reports the active conferences
this is xxx - associates this channel with conference xxx
excuse us - disconnects from the irc channel
I last learned something new on $Date: 2002/06/26 15:33:51 $
[Dave]
zakim, I am DaveO
[Zakim]
sorry, Dave, I do not see a party named 'DaveO'
[hugo]
Dave, try /nick DaveO
[TomCarrol]
Chris: there is no cononical way to organize the glossary?
[mchampion]
Open the pod bay door, Zakim ... I can't do that Dave, you're planning to unplug me :-)
[DaveO]
wahoo
[hugo]
Zakim, only knows about people connected to the phone bridge
[Zakim]
I don't understand 'only knows about people connected to the phone bridge', hugo. Try /msg Zakim help
[DaveO]
*double sigh*
[scribe]
Chris: how self contained is this document (what is the scope of the glossary).
[zulah]
Tom, would you like me to take over scribing now? I seem to have my connect problems fixed.
[scribe]
What do we do with terms that have multiple definitions?
Allen: Each definition must be able to reference the author.
Joe: Once the term is in the glossary. the term would then be reserved.
[Heather]
words in dictionaries have multiple meanings in differnet context's, wouldn't that be true for glossarys as well?
[scribe]
Joel: The glossary should have as much detail to clearly identify the definition of the term given its context.
Chris: a singular glossary provides single reference point for the associated working groups.
Roger: is the keeping one glossary feasible? given the differences between the working groups.
[Heather]
i would think it would be feasible and NECESSARY within the web services activity
[scribe]
DavidB: Multiple definitions are possible and may be necesary. It the nmultiple def. case the context must be defined.
[Heather]
agreed
[chris]
source, context, owner/authorship, multiple definitions allowed, but not preferred
[Roger]
Heather - look at "Service" in the existing glossary.
[dbooth]
Another term for "context" is "field of use"
[Heather]
i'm looking at Service...
it says 'collection of endpoints'
[Roger]
There are two.
[scribe]
Chris: comments on the glossary should go to the list along with additions.
[Heather]
it would help if this were in alphabetical order
[scribe]
AllenBr: Please provide sources with your additions.
[Roger]
Stylesheets are envisaged yielding different organizations.
[dbooth]
Heather, Allen said he can generate aphabetical in the next pass.
[Heather]
so there are 3 definitions for service... 2 in that one and 1 on the first page
thankyou allen
[Roger]
I just thought that they were amazingly different.
[scribe]
We are now talking about WS security working group
[Heather]
how are we reviewing the glossary? Term by term?
[scribe]
chris: How big is the WS security WG? what do we need to see in the group?
Joe: Lets start with the requirements that we already have.
Glen: We should be framing the security problem.
[zulah]
I am scribe
zakim, I am scribe
[Zakim]
sorry, zulah, I do not see a party named 'scribe'
[scribe]
Chris: the question is, do we see a ws working group as the working group that solves world hunger for mankind or a specific targeted focused WG?
Chris: somewhere between the two extremes?
DaveO: I made a pitch in email about what a rough starting set of requirements would be.
DaveO: Let's have a security group talk about a framework, details of a trust model, task it with specific technological soluntions to authentication, integrity
DaveO: encryption
DaveO: knowing that there are others (e.g., Authorization, non repudiation),
DaveO: This is a starting point pitch
Daniel: Just in terms of the scope the ideas are good. We should confine the cope to not include world hunger. Confine it to security problems specific to WS architecture.
Daniel: Confine the scope as much as we can. Take advantage of others work
Chris: Just as a baseline, the WS activity is not charter to go beyond the bounds of WS
Chris: So you are saying not world hunger even for web services?
Daniel: yes
JeffM: We have requirements, we should pick a subset of generally useful requirements (relevant subset)
JeffM: pick pieces and fill in terra incognito. Whatever set of requirements that we choose it must address and end to end case.
JeffM: it doesn't have to be all cases but one in depth
Roger: question? is there another axis? On one extremem you make up new languages and syntaxes, on the other there are existing solns. with recommednations on how to put them together.
Roger: Which is our job?
Chris: In making our recommendation we have the option to propose putting pieces together or additions, changes
Roger: No, will this group in the process of creating the architecture specify which pieces to make security work (specifically).
Chris: we cannot dictate soln. We can provide baseline.
Roger: No, will there be components of security solutions in the architecture?
Roger: DaveO: Say we decide that we should have auser name/password for authentication then we will say this in architecture and charter.
DaveO: If a WG tells us that we a re wrong, we will fix it in the document.
Roger: If I am trying to implement WS and I use the arch document, will there be any answers in there for how I implement security?
Joe: General guidelines but more specific will come from security group.
Glen: In other words, not really just like we don't say specific things about implementing transactions.
Chris: But we can provide starting points (e.g., XML digital signatures exists, use it).
DaveO: What I think is being asked is what is the authority of the arch group in binding things? So if we say use Dig sign. is this authorotative.
Chris: At best we can influence.
[Daniel]
Heather you're up
[Heather]
k
[hugo]
I think that it depends on how our recommendations are phrased
[Heather]
I'm a little nervous about giving a new security wg carte blanche to develop a new security framework
it smacks of architecture groups having baby architecture groups
should we provide a 'broad framework' as part of our work
leaving them to figure out how to implement those components w/ existing specs and new specs?
[scribe]
Joe: Would like to help move the process along by returning to the six items from the requirements doc. 1) authentication, integrity, encryption, 2) authorization, 3) NR, 4) accessibility (DOS), 5) rest of the stuff in CSF and requirements. He suggests that this is the prioritization.
[Heather]
ok.. thats it
[scribe]
DaveO: I agree
[tomCarrol]
+1 on the framework
[Roger]
Heather, what did you mean by
[jeffm]
heather, you're stuff is up on the board
[scribe]
DaveO: I think that heather is getting at the fact that the framework has to have some detail to provide constraints. We are not writing a blank check.
[Roger]
"OK, that's it".
[jeffm]
s/you're/your
[Heather]
by 'ok thats it' i meant </Heather>
[scribe]
Joe: We need to supply detail? Yes because this lends credibility>
[Heather]
or end of tirade
[Roger]
Thanx.
[scribe]
TomC: I was wondering if when we send a WG off to work, are we also going to privide a well defined process for making changes back into the architecture
[tomCarrol]
Mchapman your up
[scribe]
Summary: We own framework, set context, but offer a process for feedback into changing the architecture.
Martin: Question is, when we charter the security group, do we pre-phase them or only charter them for a specific phase?
Daniel: this is how SOAP works today.
Summary: One working group with phasing (or re-chartering for each phase).
Martin: So what we should be debating is phase 1
[Heather]
+1 for rechartering for phases
[scribe]
OIsio: Point of process, needs to be some life after wreck process so that there is some formal manner to make changes.
DaveO: How convenient. I asked TBL how ammenable the director is to us rechartering in mid flight. HE said go for it, no blank check but time to market is important. I interpret this as a broad endorsment to get this stuff out there.
DaveO:No change to the process document. Its the willingness of the AC.
DaveO: Process does not mean that we have to do things slowly
AllanB: There is another kind of structuering that comes from the overall architecture. YOu can imagine doing security at the messaging level. You can imagine role security at the orchestration level. These offer a basis for constraining what kinds of things are considered in each phase.
AllenB: So phase 1 could be messaging security.
Joe: Good point. For his priorities, these can be done in multiple ways: messaging, etc.
[Heather]
define messaging security for me...
[GlenD]
security on a per-message basis
[scribe]
AllenB: So there is more than one dimension to this and we can look at the matrix and determine what we want to fill in.
[GlenD]
as opposed to securing a channel (ssl)
[Heather]
could also match phase.... define their phase one in corresspondence with our phase one
[GlenD]
phase-locked groups
[scribe]
Daniel: following martins earlier suggestion that we iterate on phases. We should pick the highest priority probelms and ask the security group to address them in the first pass (and so on). Dave has identified the high priority items. We should phase as probelm in priority (as opposed to as solutnions).
[DaveO]
I think Allen proposed that there is another aspect of security, that there are the styles of security: message, connection, role based (e.g. for orchestration)
[scribe]
DougB: Have the security WG recognize the boxes that we provide them mapped to existing standards. Is that our job or some WGs job?
DaveO: Great.
DougB: Does the security group recognize existing standards and fill them intoboxes or does the arch team do this (clarifiation)
DaveO: this came up on the tag. They felt that it was disirable for the arch group to provide details in fleshing out the scope of the box.
Chris: Again, all we can do is hope to influence.
Joe: Are we going to do the threat model in WSA or by the new WG?
[dougb]
higher level question Joe and I are getting at: Are we writing the security portions of our architecture document (referencing existing standards and the threat model) or is the Security WG doing that?
[scribe]
Chris: The order of the requirements document did not imply that we had prioritized.
[Heather]
if we are going to lay out the high level framework and boxes, we may have do some level of threat model
[scribe]
JeffM: As part of this discussion, will we consider the end to end case. Pick a couple of scenarios as examples and do the analysys so that we scope this by end-to-end for specific technologies as opposed to just stating messaging security.
Chris: Did you mean use cases?
JeffM: yes, the high level ones.
[DaveO]
lol
[Daniel]
Dave loved that :)O
[Heather]
:-)
[scribe]
martin: even though we work at the same company ;) I want to really support this. Working solutions are importnat...
Chris: in our current scenarios we describe stack type stuff. Are you going vertical or horizontal?
[Daniel]
Dave and I used to be friends! that was back in XML-CORE days tho
LOL
[scribe]
Martin: All the way down and then back up again.
Jeffm: When some people think end-to-end they think multiple hops, routing, etc. and that's not what I mean. What I mean is that whatever use case we pick, we do it end-to-end.
Chris: Do we care about multiple hops or is this phase 2?
Martin: What is multiple hopS?
[DaveO]
It was the large trout aspect, not so much the recipient ;-). I do prefer salmon, but I'm from the west coast of Canada...
[scribe]
Martin: My point is that I want to see a full working solution between client and server as opposed to chunks of security that don't fit together.
[Heather]
security info propogation is going to be an immediate problem...
+1 to martin
[scribe]
DaveO: suggestion to deal with this is to do a use case and soe usage scenarios that treat particular aspects of the end-to-end.
[dougb]
+1 to DaveO, subject seems to depend upon use case chosen to frame security WG / also appreciate Martin's extreme programming (extreme architecture?), continuously working process.
[maa-in]
+ extreme UML :-)
[Daniel]
it's nothing to do with extreme anything, it's basic UP iteration
[scribe]
Chris: Here's what I hear: Not boiling the ocean. Targeted. We have suggestions for different approaches or synergisitc approaches for how we might determine prioritization. I sense a stronglevel of rough agreement as to end-to-end solutions. We have a notion of phases. that we start something off and it evolves. We may need overlap of working groups due to market forces.
[tomCarrol]
To be complete would we not need a complete set of use case that describe a web service and use those for the context of the security WG??
[scribe]
chris: break at 3:30. Afternoon for use cases. Right now, could we given this ... pick a prioritized subset of joes and allens suggestions for a phase 1 charter? Can we do that now?
DaveO: We have atleast one use case already - Hugo wrote it. Why don't we look at it and work the process?
martin: Let's narrow the use case for securiyt aspects.
Chris: We have Joe's onion, let's focus on the core of the onion. and thinking about phase 1 only.
[tomCarrol]
Would we want to narrow the use case or would that be delegated to the security WG
[scribe]
Chris: How do we want to break up?
Daniel: want to tackle high priority stuff.
Roger: You could also (in parallel?) tackle the EDI use case
Chris: Of #1 (auth, integrity, confidentiality), what would go into a phase 2?
Joe: It is useless to do integrity and confidentiality alone.
Chris: So is #1 too broad, do we want to further narrow it?
Daniel: Maybe there is some low hanging fruit here because a great deal of work has been done on some of this (e.g., auth and authorization).
DaveO: The solutions and how they deal with XML and the web have not been around. We are just starting to see first proposals on some of these.
Joe: More critical problem for XML encryption is key districution. All we have talked about is message level security but channel level security has been around and that's low hanging fruit.
Daniel: I would rather talk about problems that solutions.
DaveO: but solutions introduce problems. So which of the new problems do we wish to tackle.
DaveO: the process model one is really interesting. This has come up with XML. Can or should an author be able to indicate the steps a recipient should do with a particular message...
DaveO: default processing model, explicit one... clearly in WS we have the same issue. How does a reciever specify the processing model that it will publish to the world.
[Daniel]
do we think we want to adopt/s[pecify a particular processing model?
[scribe]
DaveO: e.g., i will do integrity checks after confidentiality. So sender mus invert this. Security clearly introduces a processing model. We should stay away from tackling this right up front ("there be dragons").
Joe: true for message based but channel based already solved.
DaveO: Missed point, the order that you do things is either the canonical order or you have to publish processing orer.
Chris: Okay, how are we going to divide up this work?
DaveO: suggest taking hugo's use case and then breaking it up around 3 scenarios (auth, integrity, and confidentiality.
Chris: Hugo, do you want to walk us through the use case?
[hugo]
Travel agent use case: http://www.w3.org/2002/06/ws-example.html
[scribe]
Chris: 15- 20 break...
[Heather]
whew!
[scribe]
Hugo: Will present travel agent use case.
Hugo: There is a customer that wants to use travel agents service to book vacation package. Travel agent service will use hotel and irline, credit card co. web services.
Hugo: I divided the use case into 4 usage scenarios. which are basically the steps that the whole thing will go through to book the vacation package.
Hugo: Of course I made simplifications - security is not considered at all.
Hugo: If you want to go step by step, its complicated.
Roger: Wants to quibble. In talking to people who wanted to use web services. When dealing with credit card service, you are dealing with something that is already firmly in place and is not going to change.
Martin: So there are definitely actors, either people or external systems.
Roger: My point is that it is unlikely that these will operate as ws in the new future.
DaveO: Point is what things would look like using ws technology.
Roger: make this point because if you are prioritizing, some legs of a use case are unlikely to change in the near future so they are low priority.
Hugo: Even though parts of the use case won't be used for a very long time, they are still illustrative.
Hugo: User requests travel for some travel dates. Hugo has a complex diagram for this in his document. The customer provide the travel agent some travel dates and the service discovers airlines and then gets descriptions of how to interact with those. So the ontology thing means that the descriptions made sense to everyone (magic).
Hugo: So queries are made, results are returned, merged and sent to the customer. The ustomer chooses and the travel agent service books the flight.
Hugo: Then moves to the hotel reservation (which works much like the airline situation).
Hugo: From here, (purple stuff), when consumer boks hotel, the trravel service gives the cutsomer payment options. The travel agent service interfaces with the credit company to get a guarantee of payment.
Hugo: At this point (Next diagram), the travel company has confirmation and then books the hotel with the credit information. Travel agent company creates vacation package and bill.
Hugo: Security wise, there is confidentiality, credit card company stuff (certificates and guarantee) - identity, encryption for credit card number.
Joe: Integrity cwould come into play since you don't want someone to change your data (london to paris) in transit. Authorization as well.
Roger: We havea system in our company that works exactly like this today. If we want to make this realistic, we could determine exactly how these work. There are sll sorts of elaboration that happen in reality. For example people doing travel on behalf of another person.
DaveO: this is a great start. There are issues of communication, QOS, Orchestration, etc. I love the travel service kind of use case.
[jeffm]
+1
[scribe]
Joe: You can build this up. So you could add NR, etc.
[jeffm]
jeffm: +1
[scribe]
Martin: So, what's the end-toend minimal thing that we need to do to make this secure. The customer looks up something and books, how do we make this minimally secure.
JeffM: Instead of taking the whole thing as and end-toend we could take "little t" transactions and deal with each.
Jeffm: security group might be chartered for little enchilada as apposed to the whoole thing (presumably staging).
Roger: The odering has to do with what gets done first and what is needed first. There are portions of this that are cast in stone (the real world). Some of the example doesn't need to be dealt with in the near future.
TomC: I tend to agree with the Oracle crowd. At a certain level of abstraction, in order to identify the meaningfl parts for a security WG we have to get to lower level parts of the use case.
Jeffm: explicitly not trying to determine which things have to be done first.
[jeffm]
To clarify: I'm suggesting that what is done first is the end-to-end security for the entire steel thread(s).
[scribe]
Chris: So if I want to pull this apart: How do we know that its hugo, integrity, confidentiality,
Thanks Jeff ;)
[jeffm]
Clarify(cont): The prioritzation task is picking the "right set" of steel threads to scope the first phase.
[scribe]
Tom: familiar with the eprocirement scenario. You have to look at the small use cases one at a time. That is you don't get to pull the security areas out one at a time (integrity, authorization,etc.). Must find pertinent use cases in order to define a domain.
martin: You didn't mention authorization or permissions.
Chris: They are all there.
Chris: Key point is getting to the point that roger was making, we could do all of the security things (1-5) or...
CHris: we could do them all, we can parallelize based on specific aspects. In terms of encryption where you have only a credit card number, did you really need XML encryption?
Joe: You could do this two ways (SSL is option).
Chris: Integrity is fundamental (due to multiple), authentication is fundamental, and confidentiality. can we focus on just these three.
Martin: The scenario has to touch on all of them otherwise you will miss something. The steel thread must address all points.
Joe: This is what he was refering earlyier to the minimal set.
Roger: Does not like the use case because he doesn't see the business driver.
Roger: sees apples and oranges of existing systems of different types. He really wants to show the EDI use case because it is different and the business drivers are clearly displayed.
DaveO: In terms of the break up, another way to tease out requirements is to look at what is going on in terms of the channel (e.g., email). So this type of variability might be another way to go in terms of structuring this.
Martin: This use case represents 80% of what the web is used for.
TomC: On rogers point, views the use case as an abstraction (that is that you can abstract out the business portion - the travel agent). The trust model varies based on what side of the travel agent service I belong to. I have trust with suppliers that is completely different that with the general public. So security may be completely different and require completely different technical implementations.
Hugo: Martin said that we should have a look at everything rather than limiting to the 3. If we have a look at everything, everything will be large (e.g., privacy).
Joe: Responds to Roger's use case comment. Can cover all of the security aspects with buying a book from Amazon.com. The EID use case could be different because it is intranet.
Roger: Not intranet, its an internet example!
Glend: two tiny comments. Regardless of whether the use case is connected to reality, it is still a useful scenario. Can we ask Roger to do a short description of his use case.
[chris]
q close
[scribe]
Roger:EDI like interacteraction betweek big and small company to to purchase widgets it is interesting because small company has different capabilityies and security aspects and guts happens when things go wrong.
Mike: How does this use case differ from the travel agent?
[chris]
ignore q
[scribe]
Roger: Assumption here is that you have trusted partners.
[Martin]
q martin
[chris]
zakim, ignore q
[Zakim]
I don't understand 'ignore q', chris. Try /msg Zakim help
[chris]
zakim, ignore queue
[Zakim]
ok, chris, I will ignore the speaker queue
[scribe]
DaveO: I have built SOAP systems doing exactly this. If you take how vendors talk about ws. IBM developer site is example. They use travel, others use this example. This is a connonical exmple for doing WS.
[jeffm]
jeffm wonders where chris is
[scribe]
chris: we don't have time to do the break outs. Suggests that we let Roger present his use case for 5-10 minutes.
Roger: I talked to our EDI people about what they actually do and how they would be interested in useing web services and here's the scenario. You havea big company trying to buy widgets from a small mom and pop co with a big technology difference. We actually want to do this.
Roger: Actors: Engineer, business analyst, lots of people. mom and pop and uncle on weekends.
Roger: Request for purchase, purchase order, request for invoice, purchase, payment.
[hugo]
EDI use case: http://lists.w3.org/Archives/Public/www-ws-arch/2002May/att-0323/02-WS-EDI_Use_Case.htm
[scribe]
Roger: Focus is technical infrastrcutre not the buisiness process. Payments are explicitly out of scope. Because banks have their own processes.
Roger: This is how process works when it works. This is less intereesting than when it doesn't. He has a list of requirements, check the use case for details. It is required that messages are ordered and identified with unique ID but not sequenced.
Roger: Security problem: NR, accessibility, authentication. NR is a lower level than NR but higher than auditing because it is a trusted business parter. No one is going to court over a failure. You just need somewhay to determine what happened.
Roger: So you need to reconciliate. So, the problems in the process are the real meat. This is where people spend their time. Transactio n log mismatch. At the end of each moth the big co will send a list of messages received to small co. The response is checked against the back office to see if there is message agreement.
Roger: Second scenario is that small co thinks that they weren't payed. (incorrectly). They didn't get a payment advise(?). So they got paid bu they don't know it.
Roger: Big purchasing department ... big co sends copies of purchase information to little co, and then little co matches and determines that they were payed.
Roger: Finally, example where small co gets payed and this is similar to former.
[chris]
zakim, track queue
[Zakim]
ok, chris, I will track the speaker queue
[scribe]
Roger: Real important thing is to be able to determine what happened in the past.
Martin: This type of scenario is invaluable. Some things are not in the scope of web services. Alot of the use case is human use case.
Roger: I disagree. Ddifferentiates (human from machine) based on log information needed vs. actual reconcilliation.
Martin: What extra do we need to do to be able to prove that a payment was made (for example).
Roger: It is important that there is an agreed upon method for identifying messages (in time).
Roger: A standards query for getting digest of messages would be great.
TomC: Looks at the abstraction. The activity being performed is ... missed it
[dbooth]
Hmm, it sounds like he's talking about "unambiguously identifying things". Sounds a lot like URIs to me!
[scribe]
JeffM: If the requirement is to have a logging service, and the service has to support a DB query service then that is all that you need to say - that's a solution to the problem.
JeffM: doesn't see how the use case adds more to security.
Roger: I think that it is significant that the financial transactions are out of scope.
[Heather]
why are the financial transactions out of scope?
[dboo-scri]
GlenD: There are lots of scenarios. I suggest we do something to move forward. We've chosen to drill through a use case. We'll do (1) vote for one of these use cases; or (2) tonight you guys can combine them.
Roger: Or we could split and do both.
Heather: why are the financial transactions out of scope?
Roger: Because EDI people told me they were'nt interested in it.
s/EDI/my EDI/
[Heather]
why?
is there no interest from the financial industry to move to web services?

Friday 14 June 2002

[hugo]
hugo has changed the topic to: WSAWG face-to-face meeting; IRC log at: http://www.w3.org/2002/06/14-ws-arch-irc
I put the complete IRC log for yesterday at: http://www.w3.org/2002/06/13-ws-arch-irc-complete.html
this channel is temporarily hijacked by subgroup 1 for authentication work on <http://www.w3.org/2002/06/ws-example.html>
[GlenD]
Ew, authentication!
I'm outta here...
[hugo]
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
[GlenD]
OK, I'm back, but only to ask for the URL of the use-case
Anyone?
[hugo]
hugo has changed the topic to: WSAWG F2F: work in subgroups on use case at <http://www.w3.org/2002/06/ws-exampl
hugo has changed the topic to: WSAWG F2F: work in subgroups on <http://www.w3.org/2002/06/ws-example.html>

Breakout goups for Authentication, Integrity and Confidentiality

Subgroup 2: Integrity

[soliton]
what are our topics?
[GlenD]
Integrity
[shishir]
work in subgroups on <http://www.w3.org/2002/06/ws-example.html>
[chris]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html
[GlenD]
That's the glossary w/definiton of "integrity" we're using
1. Hop to hop
2. End to end
Posit that we have nodes and arcs - each interation is two nodes across a single arc
"end to end" service integrity is about securing the arcs
consider that first
Then get into the fact that the nodes must be considered as well
SERVICE TO SERVICE INTEGRITY
--
[soliton]
we can consider a public-witness model for integrity
are we trying to offer solution here or just locate the problems?
I guess we can classify into: a) one to one 2) one to many
[GlenD]
Where are places in the use-case that bring in integrity issues?
[soliton]
first of all, we need data normalization
[GlenD]
1. Travel agent books flight - make sure that the correct flight gets booked
Travel agent needs complete view of data
other parties need their own views
[soliton]
ok, data normalization model can be in next phase
[GlenD]
First approx - "bits originated at point A must be reproduced at point B exactly"
[soliton]
different views can be classified into access control
are we doing access control?
[omh]
don' think so...
[GlenD]
SCENARIO : Evil Intermediary Changes Flight Times
Travel agent sends "book a Saturday 1PM flight" to airline A
Evil intermediary changes doc en route to say "Sunday 4AM flight"
(could easily see your own biz doing this to ensure saturday night stays....)
Airline A is able to see that the data was tampered with and fails
(perhaps alerting the net.cops)
</SCENARIO>
[soliton]
well, public key-private key solution will do
[GlenD]
OK, so we must have a trusted keystore
[soliton]
symmetry key solution also works, although
[GlenD]
symmetry key == secure channel?
[soliton]
very much
[GlenD]
So if I trust the pipe, I trust the integrity of the data that passes over it
So there are two levels here - channel security and message security
[soliton]
pre-arranged shared key
[GlenD]
If I have a trusted channel, I'm ok
If not, I have to trust each message individually
So this doesn't require particularly web-service-specific technology
[soliton]
the web services specific issues would be to estabilish the
trust between services
[GlenD]
Joe describes the fact that integrity via hash comparisions != encryption
Therefore we can separate the issues
Therefore in this case "trusted channel" == channel which periodically hashes the data and allows both ends to check integrity
[soliton]
but you still need to way to pass the hash
[GlenD]
yup
[soliton]
question is, would ssl be sufficient?
[GlenD]
yup
[soliton]
since ssl is already a web facility
so our mission is to ensure web services does not violate ssl
[joe]
The hash is embedded in the data packet.
[soliton]
can anyone post of url of the svg?
[GlenD]
<SCENARIO name="Evil Travel Agent">
Customer sends travel agent some information about flights/times/etc
Travel agent, either intentionally (evil) or not (mistake) alters the info
Then they pass it on to an airline or hotel
</SCENARIO>
[soliton]
this looks like business
since the travel agent is trusted service
it has to be responsible for its own actions
[GlenD]
Well, yes, but your third-party suggestion from before would work
I.e. both customer and airline/hotel notarize the data
So there's another channel (not via the TA) for confirmation
Can we do it without the third party?
[soliton]
but the airline needs to know where the end customers are
[omh]
does this mean the location of the customer or the identity of the customer?
[soliton]
the public signature of the customer
or the airline needs to share a secure channel to the customer as well
[omh]
yep thats what I thought..
[soliton]
I guess there are two scenarios here
one is that the airline does all the work on behalf of the customer
sorry, I mean agent
the other scenario is that the agent does the initial connection, then the
airline talks directly to the customer
but actually, the agent is already a third party to the airline and customer
I guess the issue here is that we should not interface with the business
[GlenD]
There are business problems and technical problems here
We need to deal in the technical space
But there are certainly technical ways to help deal with business problems
"referee" model
I want to use an agent to talk to third parties for me
I don't necessarily trust the agent 100%
[shishir]
Not only is it a good way to maintain data integrity, but it also idiot proofs the system to some extent :)
[GlenD]
So I put in a reference to a "referee" (which is hashed/secured) in the request
All transactions before committing MUST go through the referee
slows things down, but ensures the "rules" are followed correctly to all parties' satisfaction
[soliton]
maybe we should think hard about what issues are web services specific issues
[GlenD]
Getting a message from one point to another without tampering
[soliton]
actually, the soap extension you mentioned can be one
[GlenD]
To solve these scenarios, we ask:
1) Do we have existing infrastructure to solve these problems?
2) What extensions can we add at the WS layer to solve things if not?
3) Is the problem a technical one or a business one? Where's the line?
* How do you express required technology and policy statements
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch2-irc#T08-34-14
[soliton]
bookmark
RRSAgent, bookmark
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch2-irc#T08-37-32
[soliton]
RRSAgent, help
[GlenD]
We discussed:
Scenarios - two, one where the integrity issue is in the arc, and one where it's potentially in a node
within the graph of interacting parties.
Difference between business and technical issues
Using pre-existing technical solutions
Some solutions are at the infrastructure layer and others need to be layered on top (smooth spectrum)
Two broad sets of solutions:
1. involve a third party (notaries and referees)
2. rely on two-party technical solutions (end to end) (ssl, xml dsig, hashing)
Agreeing on and descibing policies and technologies to be used
There may be cases where you need the WHOLE bitstream to be safe, and other cases where it's only particular subsets
[chris]
rrsagent, where am i?
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch2-irc#T09-14-02

Subgroup 3: Confidentiality

[chris]
this group is confidentiality
[scribe]
definition for confidentiality is protection from observation during transport
Goal is only confidentiality (not integrity).
Doug: Do we want to include obscuring the fact that two people are talking to each other
[chris]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html
[scribe]
David: clealy a case for the military
There are lots of ways to do this.
[chris]
Confidentiality
Assuring information will be kept secret, with access limited to appropriate persons.
[scribe]
Issue: two parties talking, known or unknown
[chris]
from the glossary
[scribe]
Daniel: Do we deal with the isse of access by authorized persons?
DaveO: Thinks that this deals with access by unauthorized parties.
David: Confidentiality clearly overlaps with privacy.
Daniel: this is what I was thinking of. Example is company snooping its own network.
Assumption: privacy is an issue
Roger: agency to hotel is more interesting use case - mom and pop operation is more challenge
David: Let's decide which one we want to do first
DaveO: Suggests credit card company to travel agency
[dougb]
is there a case where user sends information to travel agency only back end hotel should understand?
[scribe]
David: if we are going through a scenario, shouldn't we be going through it in sequence and as we are doing this identify confidentiality issues
DaveO: would like to focus on one aspect and the issues associated
Assumption: web services capable client, travel agency, and credit card company interact.
DaveO: user sends credit card number to travel agency (this is the flow)
DaveO: then the travel serice does something with it (its a black box). Then they forward it to the credit cardd company (probably with additional information).
DaveO: Question? Do we want the travel agency to be able to see the credit card number?
Doug: The other posibility is that the user is sending a series of ff account #s and passwords. All info is forwarded to entire backend system and each can only see what they need to see.
That was ruled to complicated.
[dougb]
s/to/too/
[scribe]
Tom: two ways to do this. either the charge resides with the travel agency and then the suppliers bill or the charge resides witheach supplier.
Tom: The most sensitive piece of data sets the confidentiality requirements for all of the data.
DaveO: differences in channels (SSL vs. SMTP needing encryption).
Roger: so we are assumpting assynchronous
Assumption: XML over SMTP is part of the web.
Roger: There is a portion that's synchronous and a portion that's asynchronous
Doug: Proposes that the initial interaction between travel agency and user is synchronous. Other interactions may be asynchronous
Roger: travel agency has knowledge of what the availability of the hotel is and by the end of the process, this state changes fot he next person who needs a hotel
Zulah: not the way that this works
David: clarifys from use case. Usre submits request, travel agency finds a list of request, ....
[dbooth]
http://www.w3.org/2002/06/ws-example.html
[scribe]
Tom: Let's assume (since our goal isn't to resolve business issues), we should have some base assumption that we have enough knowledge to purchase the hotel.
Zulah: Pre condition: we know what hotel we want, we know its available, we want to reserve it.
Zulah: we will preauthorize with the hotel
DaveO: (the information flow is) credit card number from user to travel agent, from travle agent to hotel, and then an acknowlege (that needs to be confidential as well).
DaveO: synchronous from user to travel agent, asynchronous from travel agent to hotel, hotel confirmation asynch to travel agency, and synchronous to user.
Tom: To steal the steel wwire analogy, we've found two of them
DaveO: Proposes that sync hop it HTTPs and that the async hop is SMTP
DaveO: HTTPS channel is secure. But the SMTP is not secure. Assuming that we want to secure part of the asynchronous message.
DaveO: proposes that we are encrypting part of a document that is contained in a message.
David: This is important because someone who isn't authorized to read the entire messsage can read the portions that it needs to read.
[dougb]
do we have 4 layers: channel, message, document, single information item (credit card) for example? any one layer could require confidentiality
throw out untrusted intermediary and things always get simpler
DaveO: Avoiding description as part of this particular case, assumping infrastructure has (mostly) been set up previously.
... In our case, both user and hotel trust the travel agent. But, hotel and user may not know of each other previously.
Tom: Notes that military cases often involve untrusted parties.
DaveO: Adding "bad employee" problem to the crime we're committing.
[scribe]
Doug: If the user is a sun employee, what is the downside for sun is the user is a rouge employee
DaveO: The downside is that the rouge employee can determine the contents of the packets
DaveO: but we want to avoid this.
[dougb]
I'm logging. Sorry, nothing found for 'where are we'
[scribe]
DaveO: So intemediataries would be an interesting case but we are going to assume that Http will suffice
DaveO: We now need to take an XML doc (can we assume its a SOAP message - yes), so we have envelope and body and reserve (command) and a cc number
Doug: there are atleast four different layer. You can have a secure channel, you can secure the entire message, you can secure a particular doc (in which case the reserve is an encrypted element in the...smime soap w attachments), or you can encrypt at the element level.
Roger: Don't believe we need to encrypt at the element level.
DaveO: Let's assume that the body is encrypted since SOAP provides for this model.
David: Basically in terms of the info content of the XML doc, partis plain text and part is encrytped.
DaveO: Key point, defined an interface and a processing step that they want to be done on the interface
Doug: this is part of the bizarre way that we carve this up. If we had integrity we would in
[dougb]
DaveO: Lifecycle issue important in this case because processing model is an explicit part of the interface.
Doug's earlier comment went on to point out that processing model would include "encrypt before sign versus sign before encrypt" question if we were simultaneously considering integrity.
DaveO: Raised problem of completely encrypted SOAP message should not use same MIME type as "real" SOAP message.
... in our case, it may not be a problem since we've decided to do confidentiality at level of encrypted BODY element
Number 60 or 61 is likely the description of the SMTP confidential message.
[scribe]
DaveO: one of the scenarios is what is the credit card is in an attachment to the message
[dougb]
(that one is 62)
[scribe]
Roger: Let's assume there are no IT peopl eon the hotel side. how do they set this up
DaveO: They cannot do it by hand, there has to be some set up.
DaveO: this is a description issue.
[dougb]
The hotel has a "hotel in a box" system they bought some time ago.
All: In addition, OTA or some other gathering of hotels has probably come up with the syntax and processing model for these agent to hotel interactions.
David: We're making the assumption something exists (some type of encryption mechanism) and that it's identified (some URI or other identifier).
Roger: Agreement will explicitly identify this encryption mechanism.
? is someone asking whether particular encryption scheme will be chosen at run time?
[Daniel]
Here is an example of something very similar from Glen Daniels and the SOAP group
http://www.w3.org/2000/xp/Group/2/01/29/edcopy-soap12-part0-20020129.html#SMTP
please look at it
[dougb]
Daniel, what portion of that example is encrypted?
[Daniel]
no encryption, just SOAP/mail/travel
[scribe]
David: So to generalize, the reason that you might want the encryopted attachment case, you may want this case because only the intented final recipient is the only one in the chain of processing who knows what to do with the document (different document type).
David: Believe that we are making an assumption that has not been expressed. When talking about a WS was are assumingthat WS as a whole really is implemented by two pieces of softare. One is app specific, one is general WS infrastructure.
David: infrastrunction that knows about soap, wsdl, etc.
DaveO: In fieldings thesis, there is an application and a connector. The connector is the general ws infrastructure
David: clarification. Any WS is made up of vendor standardized infrastruction and user app specific stuff
David: this becomes relevant when we talk about SOAP message contents because we can partition the contents of a document between application specific and connector specific parts.
David: So, the connector is the software purchased from Tom, the application is something you got by some other means.
David: The connector information is common to every web service.
David: To further this, we can break it down to three levels: WS (or connector) specific, industry segment specific, and application specific.
[chris]
rrsagent, where am i?
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch3-irc#T09-13-52

Subgroup 1: Authentication

[chris]
this group is auth/n, right?
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html
[auth-scr]
2 parties:
2 cases - either the 2 parties know (KNOWN) each other or not (UNKNOWN)
3 scenarios: first time (S-FIRST), another visit same tx (S-VISIT-CONT), another visit new tx (S-VISIT-NEW)
Assume: Travel Agent is known, no delegation
Issue: Difference between authenicated identity and trust
[jdmunter]
auth-participant: a customer may or may not request credentials from TA
auth-participant: a customer may or may not validate credentials from TA
[auth-scr]
Issue: Can an entity that has been "authenticated" be spoofing?
[jdmunter]
auth-participant: a customer may or may not have pre-established governing policies
[auth-scr]
Assu
Assumption: Every entity has a set of policies (may be empty)
Assume: Customer will pay with credit card
Assume: Travel Agent doesn't care who the customer is
Assume: Customer is booking for themselves
[jdmunter]
auth-participant: TA may validate customer ID at a different time than customer validating TA ID
[auth-scr]
Issue: Entities may be able to act in various "roles"
S-FIRSTa: Customer asks TA for credentials, Cust decides to proceed with TA
S-FIRSTa: Cust browses for a flight
Issue: point to point vs. end to end
S-FIRSTa: Cust supplies TA with a flight query
S-FIRSTa: TA queries a set of airlines for flight info
S-FIRSTa: TA does not need to perform mutual authentication with airlines
S-FIRSTa: TA queries the other providers under same conditions (no more authenticataions occur)
S-FIRSTa: (note: above cust query was for an entire trip, not just flights)
S-FIRSTa: Cust makes their selection of travel arrangements
S-FIRSTa: TA asks Cust for info necessary to make a booking: e.g. name, address, credit card #, etc.
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch-irc#T08-35-53

Reconvening

[scribe]
Martin: Use case is not nailed down enough in terms of the business details
We started with assumptions that define different paths through the use case and then some issues that we raised
First, do each of the parties need to know each others
are there business relations?
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).
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.
We only did the first time scenario.
There is still this issue of locating a trusted travel agent. Once you have discovered a travel agent, you can ask them for credentials.
The sophistication of the challenge response depends on the lelve of trust, the amount of money in a transaction, etc.
We assumed that no one cares who makes an initial query. Only autheicate during booking.
Assumptions: We assumed that the customer is not authenticated, we assume travel agent is known, assume that there is no delegation going on.
[auth-scr]
nick jeffm
[scribe]
Issues: Identity exchange is easy, trust is not. Once you have authenticated, can mascarading still happen (sorry about the spelling).
[hugo]
hugo has changed the topic to: WSAWG F2F: IRC log at http://www.w3.org/2002/06/14-ws-arch-irc
[scribe]
Issues: Role vs. personal authentication - do I need separate credentials for different roles. Point to point vs. end-to-end authentication.
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.
Issues: When you havea multinode set of parties you have node to node integrity and end-to-end.
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.
There may be business issue (not technical) such as miss scheduling. What technical assistance can we provide for business.
Reuse existing technical infrastructure. How do we describe and agree on policies and technologies to be used by endpoints discovery)?
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.
Other solution is to rely on 2 party solutions: ssl, xml dsig hashing
There may be cases where entire data stream needs integrity but also just parts of a document.
DaveO:
DaveO: User talks to travel service talks to hotel and we talked about confidentiality in this reduced setting.
Issues: Is the fact that the two parties are even talking supposed to be confidential. Privacy issues. Both level on table.
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.
There are other scenario issues but we did not consider them.
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.
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.
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).
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.
We finished with a discussion about the line between the web interface (connector) and the application portion of a web service.
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.
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.
Roger: Should we also be figuring out ways that the use case can fail?
Chris: Think about whether or not you are willing to commit time in asisting with the editing of the use cases.
Send email to me or to the member list (okay the member list due to the email change ;).
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.
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.
Chris: We talked about the feedback that we got from TBL about process and flexibility with changing charter.
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.
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.
David: Proposes ...
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.
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.
[Heather]
i agree
[scribe]
Mike: so we would have boxes for confidentiality, integrity, etc. and some technologies (XML Dsig, encryption) and then the WG would begin.
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), ...
Glenn: Can you point out what problem that you are trying to solve because I am resitent to this direction.
Glen: A huge point of what we are doing is that we talk about the wire, not about your end platform.
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.
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.
Glenn: I think that there are better ways to deal with thes types of issues.
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.
David: Eg, there might bbe hotel industry specific portions of the WS.
OUr job is to specify the WS connector stuff. I pose this as a characterization for clarity.
JeffM: How do you know that the WS common stuff is not the empty set.
David: If it is then we haven't defined a spec.
JeffM: Disagree
Martin: are you trying to distinguish what is and what isn't a WS?
David: No. If we decide in our specification that a WS must do X, then X is in the connector stuff.
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.
Chris: I am failing to understand how this helps us scope a WG to do security?
Mass confusion and kots of people talking at once.
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.
DaveO: The SOAP 1.2 spec points this out. But it did this not as software layers.
David: When we go thourhg use cases it is clear to recognize and identify the relm of the parts of the use case.
David: Our job is to decide what bucket items go in (e.g., reconcilliation)
David: Does reconciliation go in the WS bucket or in the app level.
Chris: We agreed that we would talk about level 1 securuty(as defined by Joe)
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 ...
[DaveO]
Scribe, can you use the term "DavidB" for when David Booth is speaking?
[scribe]
Chris: Stops the discussion. Wants to return to security discussion.
Chris: If people could pull up the security requirements, this will help shape our discussion.
Chris: Lets try to determine which of the requirements apply to the WG (which we would put in a charter).
Martin: Please resummarize our agreement yesterday.
Chris: Focus on Joe's Level 1: Confidentialility, integrity, authentication
Phased approach
end-to-end
(steel thread)
[Heather]
what about authorization?
[scribe]
Authorization is level 2
[DaveO]
Heather, auth is listed in phase #2
[scribe]
Phase = level
message level end to end
[Heather]
what else is level 2?
[scribe]
pick relevent subset of reqirements
[DaveO]
that's it
[scribe]
use case driven
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.
Roger: Are we trying to draft the structure of a WG? What are we doing.
Chris: Rough draft of scoping statement from charter.
Chris: What are the relevant requirements?
Roger: 6.2.1 Authentication user, 6.2.2 authentication for data, 6.4 confidentiality, 6.5 integrity.
martin: is there access control in any of this?
Chris: Level 2 its aiuthorization.
DaveO: Are you prposing as part of level 1 that we have to interchange policy statements?
Martin: Access control is fundamental
DaveO: Everyone will build acess control into their software. Its what they have to echange.
Chris: are we changing our agreed on staarting point>
Glenn: is access control and authorization differnt?
Chris: Access control is a means of applying authorization.
Zulah: are we goin to include other requirements (other than security) eg. web freindly?
Chris: No, we are not restricting the reqs to security
Glen: Access control in this scope is part of authorization
[Daniel]
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
[scribe]
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.
Chris: What I understand is that we want to focus on level 1
[chris]
ack
[scribe]
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.
Roger: Lunch is at noon. We should go to lunch.
[Heather]
are you reconvening after lunch?
[scribe]
No decision yet
[Daniel]
Heather: not sure...some ppl are leaving
[scribe]
Glenn: How about having a small group create an outline for a charter and then prpose it to the group.
JeffM: Authorization on or off the table. This is a fundamental question.
Chris: Straw poll, is authorization on or off the table for phase 1?
[Heather]
i'm ok w/ it off for now
[scribe]
(results: most peopl efelt that it didn't belong in phase 1)
Chris: What do people think about a group creating a proposal and then recommending it.
Chris: Are we done with the security specific requiremenst?
Hugo: waht's happening this afternnoon because if the answer is nothing then the people who return from lunch will do this work.
[Heather]
zulah, r u coming back to scribe?
[DaveO]
DaveO suggestions for encryption: Shall support HTTPS, shall support encryption of SOAP messages, shall support encryption of attachments to messages
[Heather]
encryption of parts of messages
[DaveO]
+1 to heathers
[zulah]
Heather, we are going to head to lunch. Then some of us will return and work firther on the security WG stuff.
Presumaly this will be at 1pm. Sorry for the spelling. tired hands.
[Heather]
zulah, are you coming back to scribe?
[zulah]
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?
BTW. We should play that by ear. We can also do that early next week by phone con.
[Heather]
ok
[zulah]
love to scribe... love to scribe... I'll be here if you are going to return.
[Heather]
i will return
as well
[zulah]
So there is some issue on whether or not we can use the room this afternoon. If this fails, I will let you know.
[Heather]
thanks

Scoping and requirements for proposed security WG

[scribe]
Chris: (Choosing requirements from the doc for the WG) We are on 003 - nothing applies
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
Chris: Does not preclude any programming model seems like a req that we would want to impose on the WG
Chris: 005 simplicity, 006 have we pulled everything that applies?
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
DavidB: I agree but we are responsible for creating WGs
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.
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.
Martin: The charter seems premature.
Daniel: The group has a tendancy to move the cart way before the horse.
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).
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...
Joe: Important to scope what we are doing so we can focus our effort... determine what is in and what is out
[Daniel]
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
[scribe]
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.
Martin: I'm not saying that we do a perfect architecture but we don't really have a starting point...
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.
Chris: Our objectives... end of july requirements... outline for arch doc... with cut by July...
DaveO: We have a first cut arch doc and we have had a discussion and we are going to re-work it.
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.
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.
Daniel: I worry about the approach that DaveO is advocating. Same method as developing software (no) standarrds last longer than software. No repeat versioning...
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)
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
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.
Chris: This realistically would put us in the oct time frame wto get something off to the AC.
Martin: I dont' understand the big emphasis on security. The security group has nothing to start from
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)
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.
Chris: There is a process. Submit and issue.
Daniel: I get some sense that we are date driven as opposed to determining how ling things will reasonably take.
Daniel: Should we go back and do some reasonable estimates. We could base our times and deliverables on this. Let's do it right.
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
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.
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.
Hugo: There is a scale of approaches here and we have to choose some middle ground.
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.
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.
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
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)
[DaveO]
+1 to chris point 1)
[scribe]
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.
The longer that we put off the WG the longer we have problems and peole are clamoring for the WG.
Martin: what you are saying is radically different than our current discussions (which are gneric rather than specific). IF we have something specific, fine.
Martin: We haven't said that a WS has a WSDL interface and SOAP.
DaveO: yes, we all know this.
Martin: Independnet of that, by novermeber we must have first scketch of arch.
[Daniel]
Heather, you there?
[chris]
heather, you there?
[Heather]
yes...
got sidetracked for a few minutes
[scribe]
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.
[Daniel]
just pinging to make sure you aren't sleeping
J/K
[scribe]
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.
[Heather]
(and of course IBM doesn't agree that web services must have soap, but I thought I'd save it for another day)
[Daniel]
lol
[HaoHe]
agree with Heather
but this sounds strange from IBM, since it started SOAP
[Daniel]
actually, it was MS
[scribe]
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.
[Heather]
i think we are going to have to divide our time between specific issues and the architecture like the tag
i too feel the need to get some broad agreed architectural brush strokes before we start chartering work groups....
[scribe]
Chris: How does the integrity issue make any differnce with the web architecture issue of using get or post?
Mark: Yes. it makes a difference. Your request is not digitally signed.
[Heather]
but, I also feel the pull of getting security solved by security gurus
[scribe]
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).
[Heather]
the actual implications on the existing runtimes remains to be seen
[scribe]
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.
[Heather]
(in response to Marks comment)
[scribe]
Mark: I agree that the security group is one of the most arch independent groups.
[HaoHe]
so, Heather, why IBM prompts non-soap ws?
[Heather]
IBM defines web services to be defined by wsdl.
[scribe]
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
[Heather]
wsdl can define bindings that are non soap.....
[scribe]
Mark: There are other things that need to interop.
[Heather]
non soap bindings will be very important for internal application integration and high performance
[scribe]
Chris: We are trying to scope this so that ....
[HaoHe]
makes sense.
[scribe]
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.
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.
[Heather]
i'm not sure we need for the ground work to be DONE
[scribe]
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.
[Heather]
what did glen and david say?
[chris]
heather, you're up in a moment
glen abdicated his spot
[DaveO]
david is speaking and glen abdicated.
[Heather]
k, thanks
[scribe]
David: Likes prposal of dividing time between arch and charter for WGs. Phrases this in term of the partitioning proposal.
[chris]
tag, you're it
type away
[scribe]
heather type
[Heather]
what if we compromise on this... can we make a concentrated double time effort (extra ccalls)
to get broad brushes to the architecture
that we agree on
[jeffm]
the crowd moans......
[chris]
the crowd goes ooooooooh
[scribe]
general ooooo
[Heather]
and THEN define the security working group?
bad ooh?
[Daniel]
middling oooo
[scribe]
not clear that this was a bad oooo
[Heather]
Just 2 weeks
big time deadline
[chris]
no, that was a combination interesting, but... ooooooh
[Heather]
or else the security workgroup creation guys win and we make one w/o waiting for the arch guys
[scribe]
Chris: points out that DaveO and chris already do this and they are up for it.
[Heather]
this would motivate the arch guys to NOT argue about how many angels can dance on the head of a pin
[Daniel]
hey, I'm working on Angels-on-pinhead ML 2.0 already
[Heather]
and its easier to dump a lot of time into something if you know its a short duration crush
[scribe]
Dbooth: nothing against the idea of doing double time but not realistic. Difficulty getting people to read documents and participate
[Heather]
ok... flame away
[scribe]
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.
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
soliton: Maybe we can divide into task forcces as the groups are large.
Chris: (frustrated) all for double time but is it realistic to expect people to do the work.
Chris: Architects want to work on everything.
[Heather]
thats why i suggested single threading it
instead of parrallel...
a concentrated effort to get something down on paper
a few people would have to 'sign up' to work very hard
and the rest of the wg would have to agree to do short turn around reviw...
[scribe]
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.
[Heather]
and chris i sympathize in that we have not been good at fast anything
[scribe]
Dbooth: Liked DaveO's proposal, what happened to it?
Glen: We almost got there and then the taskforce idea came up and I am infavor if the latter.
DaveO: at some point the task forces have to report back.
Dbooth: would these be taskforces for things that need charters and the architecture fundamentals?
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.
[HaoHe]
other people can keep going during the break
[scribe]
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).
Tomc: I tend to like the idea of "taskforces". Someone ususally put up a strawman. THis is the most likely way to make progress.
[Heather]
what about bumping up the call schedules?
or making it longer?
[DaveO]
Heather, there's been a fair bit of pushback on extra time...
[scribe]
Zulah: has managed and pontificated a bit
[chris]
zulah: create a scheduel for 5 weeks and see what we can get done
[scribe]
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).
[Daniel]
zulah pontificates again, +1
ing DaveO
[omh]
+1 on Dave0
[chris]
zulah: conceptual architecture is important
[scribe]
Glen: do we want to volunteer people now, mailing list, plan?
[DaveO]
How about: 1) Architecture document; 2) Security, including usage scenarios/use cases and requirements.
[scribe]
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).
Joe: inside the doc there is a securith section and this needs to be filled out.
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).
Joe: Trying to understand more clearly how security and the arch document relate.
MikeM: How would this be more useful to the use case task force?
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.
Soliton: When people see documents they seem like they are pregiven. need process....
Chris: What if the arch guys come back with a doc, what makes you thin kit would be received differently
Glen: There is another complementary idea that somethime when you have a concrete thing to look at it provides a framework for discussions.
[Heather]
can the scenarios work just focus on security issues right now?
[DaveO]
Heather, that was my suggestion.
[Heather]
glen, +1
[scribe]
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.
Chris: Break
[DaveO]
zulah, I agree with you on that.
[Heather]
i don't want to forget to gather other use cases, there are a few I'd like to add...
can we just concentrate on some immediate issues and then look up to the bigger picture in a few weeks?
if we take some brush strokes at the archicture... then we'll have something to tune as we work thru the use cases
[scribe]
Heather, break for 15 mins
[Heather]
did you guys break on me?
[DaveO]
I suggested that too heather.
[Heather]
k...
[mikem]
we just broke....
[Daniel]
we feel broke too
[Heather]
i'm here... ya'll back yet?
[chris]
we're baaaack
[Heather]
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
[scribe]
chris: Who is willing to contribute their effort to one or the other task force.
Zulah: need clear statement of what each group will do
[chris]
i shared the same concerns earlier
[DaveO]
Security: Refine usage scenarios and requirements relating to security, particularly the 6? sections.
Harvesting: Look at the WSDL conceptual model and the XMLP MEP and bindings work and harvest architectural material.
Reliability:
[scribe]
Chris: Looking for people to join either task force. We have DaveO, Joe, Hao, Mike, Tom, Daniel, Hugo, markb, dbooth, glen, eric
[hugo]
MartinC also wanted to participate
[DaveO]
Use Cases: Add use cases with individual owners: Zulah, Hugo, ?
[Heather]
if we serialize this.... i can do both
if we go parrallel we miss come companies's views on both groups...
i tthink the havesting work is VERY important!... so if i choose, I choose that one
[scribe]
Reliability Task Force: Responsible for re-working AG002. Timeframe?
2 weeks.
[HaoHe]
Actually, I will be in the US for the next two weeks, so we can talk a bit more
for the reliability work
[scribe]
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.
Chris: We will iterate.
[Heather]
i agree with davido that usecase is on going in parrallel with architecture
[DaveO]
lol
[scribe]
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).
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
[Heather]
ok
[scribe]
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.
Dbooth:
I see 5 things that chris has doen on the board. Not clear on the proposal.
Chris: there are four and yes this is the proposal. This proposal adds two task forces.
Dbooth: There was discussion about arch fundamentals effort?
Chris: This is the harvesting.
general disagreement
Joe: is this the same as what mark has been evangelizing
Dbooth: similar
[Heather]
i thought harvesting was arch fundamentals too....
[scribe]
DaveO: I was suggesting that we begin with material that already exists
[Heather]
so lets rename harvest to Architectural Fundamentals and assume that they will leverage existing work (like they have a choice)
[scribe]
Dbooth: a task force that will try to pin down...
[Daniel]
naming something "architectural
anything will probably result in social issues in the group
[Heather]
i'm not sure that nameing will prevent social issues :-)
[dbooth]
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.
[scribe]
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.
Chris: Timing, harvesting 3 weeks, reliability 2 weeks, security 4 weeks,
Use cases on going
So we have:
Use cases: gather use cases, ongoing
Reliability: focus on rewording AGoo2
4 weeks
Harvesting: harvest from SOAP and WSDL, existing - 3 weeks
Security: scope requiremenst for charter, technologies to be used, usage scenario work
Dbooth: Architectural principles are not something that we can or should ignore. Also taskforces are efficient work.
DaveO: Keep harvesting taskforce andh scope them to only look at existing stuff. As opposed to a blank check to do architectural principles.
If they agree, let's then try to extract some architectural principles out of that. A starting point.
If the harvesting taskforce becomes the arch fundamental task force then it is too broad (paraphrasing)
[DaveO]
thanks scribe ;-)
[Heather]
the other groups do not address publication and discovery of services... an important aspect
we can't just igore that!
[scribe]
Soliton: In the reliability group, the management stuff didn't get enough comment. I woul dlike to see emphasis on management.
[chris]
soliton == hao
[dbooth]
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.
[Heather]
won't the reliability group still be doing management????
[scribe]
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.
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.
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).
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.
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.
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.
[dbooth]
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.
... To go away and do fundamentals before that would be a mistake.
[scribe]
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.
[chris]
heather, you're up next
[Heather]
k
[scribe]
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
[chris]
type away
[Heather]
i am very confused....
[scribe]
are you typing more detail?
[Heather]
i thought that we were precisely at the point where we need to start creating components and interactions...
the start of this is in dave0's draft already
i must not understand what harvesting is....
i THOUGHT it was factoring in the xmlp and desc groups work into that components and relationships layout
if we're NOT ready to do comopnents someone please tell me what we ARE ready to do...
[scribe]
that seems accurate heather
[chris]
objects?
[scribe]
beer!
[DaveO]
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.
[Heather]
and If i'm too confused to straighten out on irc... then someone please help me out next week on the phone
[MarkB]
components are things like "sender" "receiver", "intermediary", etc..
chunks of software
[Heather]
sorry daveo... your conceptual model confused me too...
[scribe]
heather, I don't think that you are confused
[Heather]
i think it needs work .. words to go with it and explanations
thats ok
yes... and we need a soa diagram with service provider, requester, registry, description all laid out
we all have this picture
[scribe]
Joe: What DBooth said about the importance of the conceptual model then just do one without waiting for the taask force.
[chris]
don't think you're confused... problem is that there's a gestalt delivery problem...
[MarkB]
cool, where?
[scribe]
Joe: I want to see more specifics to determine what I want to buy into
DaveO: are we going to have a fundamentals of WS taskforce over the next few weeks?
Chris: No, this is off the table.
[Heather]
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
gestalt????
[scribe]
chris: micromanagement (paraphrasing)
[Daniel]
chris means "all at once"
[scribe]
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.
[Daniel]
6 weeks not being sufficient time to complete all the tasks....we can only boil the universe one drop at a time
[Heather]
yes, but thats why we have to design by strawman, not by committeee
(how many angels is that?)
[scribe]
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).
I don't sense a full appreciation for the fact that there is a core set of things.
[Daniel]
<pin><head><angels number=50 /></head></pin>
[scribe]
Mark: There is a definition, all things have a URI.
[DaveO]
not-wellformedness error
[scribe]
Dbooth: I understand then that the fundamental principles will come out later from the working group.
Chris: Yes, I believe that they will come out later if they exist.
[Heather]
+10! chris!
[MarkB]
if they don't exist, we're in a whole lot of trouble 8-)
[Heather]
these philosophical problems chris mentioned need to be argued and agreed on (even if grudgingly) before we can solve other problems
[scribe]
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.
[Heather]
the architecture and security solutions will be VERY different if there is a guaranteed SOAP layer ... or no.
[DaveO]
scribe: should be 6 weeks rather than months..
[Daniel]
An architectural principle is a statement of constraint that does not change due to technological change
[MarkB]
right on
[Heather]
whatever arch principles we have will fall out as we work iteratively w/ use cases and a draft arch.
[scribe]
Daniel: on the conceptual level, there is no way to make this happen in tis short of a timeframe.
[Heather]
i don't think we can state them up front
the timeframe is a problem...
[Daniel]
I don't disagree heather, just wanted to offer a defn.
[Heather]
perhaps we should be fixing that one..
(Thanks Daniel... I needed the definition, its a good one)
[scribe]
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?
(result was a majority)
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?
Chris: So, these are the task forces and I will pick some participants and victims to be chairs.
[chris]
use case - gather use cases (edi, travel, others) ** ongoing, but with 4 week freeze for pub
harvesting - outline, etc (clam digging in WSD, XMLP, elsewhere identify
conceptual model aspects like the SOAP process model and WSD extensibility) ** 3 weeks
reliability - focus on proposals for D-AG002 (keep on keeping on) ** 2 weeks
security
- scoped requirements for charter
- technologies to look at
- usage scenarios work focus on security (s61, s62, s63, s64, ...) ** 4 weeks
use cases TF responsible for "harvesting" uc and us from other orgs (OASIS, OTA, RosettaNet, etc.)
[scribe]
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 ...
Chris: its a wrap then...
[DaveO]
that trout gets around..
something smells fishy...
[Daniel]
thanks, Dave0
[scribe]
Heather, we are done. Any confusion can be cleared up via phone calls next week. Have a great weekend!
[Heather]
k
yall have a good flight home
[scribe]
Hao, you and me should do an early phone call next week to deal with 007
[Heather]
me too
[Daniel]
l8r
[scribe]
sorry, that was to you heather ;) I'll talk to you both by email on monday.
[Heather]
k..
by
[zulah]
adios
[Heather]
thanks all!
[chris]
rrsagent, where am i
I'm logging. I don't understand 'where am i', chris. Try /msg RRSAgent help
rrsagent, where am i?
[RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch-irc#T14-42-35
[chris]
rrsagent, please excuse us
[RRSAgent]
I see no action items

Resolutions taken during F2F

resolved: d-ac005.10 accepted

resolved: remove d-ac005.13

resolved: glen resolved: AC010.1 Each new architectural area that has a representation SHOULD be normatively defined using XMLSchema

resolved: d-ac011.1 removed

resolved: remove parentheticals on AC006.3 and AC006.4

resolved: AR006.1 The WG SHOULD consider the threat of Accessibility attacks ([D]DOS, DNS spoofing, etc.) in the security framework.

resolved: 6.2.1-6.6 change "include" to "enable"

resolved: AR006.2.2 The security framework MUST enable persistent and transient authentication of authorship of data.

resolved: AR006.6 The security framework MUST enable non-repudiation of origin and receipt between transacting parties

resolved: remove Note under ar006.6

resolved:D-AR006.7 The security framework SHOULD enable key management and key distribution

resolved: wordsmith the ednote to explain why we might drop it and solicit feedback for those opposed to dropping it.

resolved: drop d-ar006.8

resolved: drop d-ar006.9

resolved: ar006.10.1 WS security framework MUST provide a means of expressing security policy.

resolved: ar006.10.2 WS security framework MUST provide a means to access a web service's security policy

resolved: replaces ar006.10

resolved: d-ar006.11 is dropped

resolved: add "auditing" to glossary so that people understand what they are agreeing to

resolved: add ednote to D-AR006.12 that glossary definition pending

resolved: ask Darran Rolls to simplify and explain by next con-call d-ar006.13

resolved: AC020.1 The Web Services Architecture MUST enable privacy policy statements to be expressed about Web Services.

resolved: AC020.2 Advertised Web Service privacy policies MUST be expressed in P3P.

resolved: AC020.3 The WSA MUST enable a consumer to access a Web Service's advertised privacy policy statement.

resolved: d-ac020.4 out of scope

resolved: add D-AC020.5 WSA MUST enable delegation and propagation of privacy policy as draft

resolved: AC022 conforms to the internationalized character model defined in "Character Model for the World Wide Web" Recommendation


Attendance

Present

==============

Allen Brown

Jens Meinkoehn

Mike Mahan

Joel Munter

Hugo Haas

Mark Baker

Martin Chapman

Jeff Mishkinski

Hao He

Glen Daniels

Oisin Hurley

Shishir Garg

Joe Hui

Roger Cutler

Zulah Eckert

David Booth

Doug Bunting

Tom Carrol

David Orchard

Daniel Austin

Yin-Leng Husband

Sinisa Zimek

Chris Ferris

Via IRC

==============

Mike Champion

Heather Kreger


Web Services Architecture Working Group