Minutes of June 12-14, 2002 WSAWG F2F
Scribes: David Booth, Allen
Brown, Zulah Eckert, Tom
Carroll
Agenda, Resolutions, Attendance
Wednesday, Thursday, Friday
Agenda
- [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
- [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
- [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!
- [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?
- [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>
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
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