IRC log of ws-arch3 on 2002-06-14

Timestamps are in UTC.

07:20:32 [RRSAgent]
RRSAgent has joined #ws-arch3
07:20:49 [zulah]
zulah has joined #ws-arch3
07:20:50 [dbooth]
dbooth has joined #ws-arch3
07:21:55 [Zakim]
Zakim has joined #ws-arch3
07:27:33 [chris]
this group is confidentiality
07:28:16 [tomCarrol]
tomCarrol has joined #ws-arch3
07:32:09 [scribe]
definition for confidentiality is protection from observation during transport
07:32:20 [scribe]
Goal is only confidentiality (not integrity).
07:32:40 [scribe]
Doug: Do we want to include obscuring the fact that two people are talking to each other
07:32:49 [chris]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html
07:32:50 [scribe]
David: clealy a case for the military
07:33:06 [scribe]
There are lots of ways to do this.
07:33:13 [chris]
Confidentiality
07:33:14 [chris]
Assuring information will be kept secret, with access limited to appropriate persons.
07:33:19 [scribe]
Issue: two parties talking, known or unknown
07:33:27 [chris]
from the glossary
07:35:29 [scribe]
Daniel: Do we deal with the isse of access by authorized persons?
07:35:46 [scribe]
DaveO: Thinks that this deals with access by unauthorized parties.
07:36:54 [scribe]
David: Confidentiality clearly overlaps with privacy.
07:37:30 [scribe]
Daniel: this is what I was thinking of. Example is company snooping its own network.
07:37:58 [scribe]
Assumption: privacy is an issue
07:38:54 [dbooth]
q+
07:39:11 [dougb]
dougb has joined #ws-arch3
07:40:15 [TC]
q+
07:40:15 [scribe]
Roger: agency to hotel is more interesting use case - mom and pop operation is more challenge
07:40:23 [scribe]
David: Let's decide which one we want to do first
07:40:36 [TC]
ack Dbooth
07:40:42 [Daniel]
Daniel has joined #ws-arch3
07:40:45 [scribe]
DaveO: Suggests credit card company to travel agency
07:40:48 [dougb]
is there a case where user sends information to travel agency only back end hotel should understand?
07:41:33 [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
07:41:44 [scribe]
DaveO: would like to focus on one aspect and the issues associated
07:41:55 [TC]
q-
07:44:11 [scribe]
Assumption: web services capable client, travel agency, and credit card company interact.
07:44:58 [scribe]
DaveO: user sends credit card number to travel agency (this is the flow)
07:45:48 [scribe]
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).
07:46:05 [scribe]
DaveO: Question? Do we want the travel agency to be able to see the credit card number?
07:46:47 [scribe]
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.
07:46:51 [scribe]
That was ruled to complicated.
07:47:49 [dougb]
s/to/too/
07:48:52 [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.
07:49:18 [scribe]
Tom: The most sensitive piece of data sets the confidentiality requirements for all of the data.
07:50:16 [scribe]
DaveO: differences in channels (SSL vs. SMTP needing encryption).
07:50:25 [scribe]
Roger: so we are assumpting assynchronous
07:51:49 [scribe]
Assumption: XML over SMTP is part of the web.
07:52:06 [scribe]
Roger: There is a portion that's synchronous and a portion that's asynchronous
07:52:30 [scribe]
Doug: Proposes that the initial interaction between travel agency and user is synchronous. Other interactions may be asynchronous
07:54:11 [scribe]
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
07:54:54 [scribe]
Zulah: not the way that this works
07:55:47 [scribe]
David: clarifys from use case. Usre submits request, travel agency finds a list of request, ....
07:55:50 [dbooth]
http://www.w3.org/2002/06/ws-example.html
07:56:50 [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.
07:58:17 [scribe]
Zulah: Pre condition: we know what hotel we want, we know its available, we want to reserve it.
07:58:30 [scribe]
Zulah: we will preauthorize with the hotel
07:59:21 [scribe]
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).
08:00:36 [scribe]
DaveO: synchronous from user to travel agent, asynchronous from travel agent to hotel, hotel confirmation asynch to travel agency, and synchronous to user.
08:01:40 [scribe]
Tom: To steal the steel wwire analogy, we've found two of them
08:02:47 [scribe]
DaveO: Proposes that sync hop it HTTPs and that the async hop is SMTP
08:03:43 [scribe]
DaveO: HTTPS channel is secure. But the SMTP is not secure. Assuming that we want to secure part of the asynchronous message.
08:04:17 [scribe]
DaveO: proposes that we are encrypting part of a document that is contained in a message.
08:04:41 [scribe]
David: This is important because someone who isn't authorized to read the entire messsage can read the portions that it needs to read.
08:05:40 [dougb]
do we have 4 layers: channel, message, document, single information item (credit card) for example? any one layer could require confidentiality
08:06:32 [dougb]
throw out untrusted intermediary and things always get simpler
08:10:29 [dougb]
DaveO: Avoiding description as part of this particular case, assumping infrastructure has (mostly) been set up previously.
08:11:18 [dougb]
dougb has joined #ws-arch3
08:12:09 [dougb]
... In our case, both user and hotel trust the travel agent. But, hotel and user may not know of each other previously.
08:12:57 [dougb]
Tom: Notes that military cases often involve untrusted parties.
08:13:16 [dougb]
DaveO: Adding "bad employee" problem to the crime we're committing.
08:13:57 [scribe]
Doug: If the user is a sun employee, what is the downside for sun is the user is a rouge employee
08:14:23 [scribe]
DaveO: The downside is that the rouge employee can determine the contents of the packets
08:14:46 [scribe]
DaveO: but we want to avoid this.
08:15:49 [dougb]
I'm logging. Sorry, nothing found for 'where are we'
08:15:53 [scribe]
DaveO: So intemediataries would be an interesting case but we are going to assume that Http will suffice
08:17:04 [scribe]
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
08:17:59 [scribe]
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.
08:18:09 [scribe]
Roger: Don't believe we need to encrypt at the element level.
08:18:37 [scribe]
DaveO: Let's assume that the body is encrypted since SOAP provides for this model.
08:18:53 [scribe]
David: Basically in terms of the info content of the XML doc, partis plain text and part is encrytped.
08:19:41 [scribe]
DaveO: Key point, defined an interface and a processing step that they want to be done on the interface
08:20:41 [scribe]
Doug: this is part of the bizarre way that we carve this up. If we had integrity we would in
08:20:43 [dougb]
DaveO: Lifecycle issue important in this case because processing model is an explicit part of the interface.
08:21:39 [dougb]
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.
08:23:00 [dougb]
DaveO: Raised problem of completely encrypted SOAP message should not use same MIME type as "real" SOAP message.
08:23:38 [dougb]
... in our case, it may not be a problem since we've decided to do confidentiality at level of encrypted BODY element
08:24:27 [dougb]
Number 60 or 61 is likely the description of the SMTP confidential message.
08:24:56 [scribe]
DaveO: one of the scenarios is what is the credit card is in an attachment to the message
08:25:14 [dougb]
(that one is 62)
08:25:17 [scribe]
Roger: Let's assume there are no IT peopl eon the hotel side. how do they set this up
08:25:44 [scribe]
DaveO: They cannot do it by hand, there has to be some set up.
08:26:15 [scribe]
DaveO: this is a description issue.
08:28:49 [dougb]
The hotel has a "hotel in a box" system they bought some time ago.
08:30:16 [dougb]
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.
08:31:02 [dougb]
David: We're making the assumption something exists (some type of encryption mechanism) and that it's identified (some URI or other identifier).
08:31:23 [dougb]
Roger: Agreement will explicitly identify this encryption mechanism.
08:31:56 [dougb]
? is someone asking whether particular encryption scheme will be chosen at run time?
08:32:14 [Daniel]
Here is an example of something very similar from Glen Daniels and the SOAP group
08:32:17 [Daniel]
http://www.w3.org/2000/xp/Group/2/01/29/edcopy-soap12-part0-20020129.html#SMTP
08:32:24 [Daniel]
please look at it
08:34:02 [dougb]
Daniel, what portion of that example is encrypted?
08:35:01 [Daniel]
no encryption, just SOAP/mail/travel
08:37:45 [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).
08:38:42 [scribe]
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.
08:38:58 [scribe]
David: infrastrunction that knows about soap, wsdl, etc.
08:39:55 [scribe]
DaveO: In fieldings thesis, there is an application and a connector. The connector is the general ws infrastructure
08:42:19 [scribe]
David: clarification. Any WS is made up of vendor standardized infrastruction and user app specific stuff
08:43:33 [scribe]
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.
08:44:32 [scribe]
David: So, the connector is the software purchased from Tom, the application is something you got by some other means.
08:44:43 [scribe]
David: The connector information is common to every web service.
08:47:03 [dougb]
dougb has joined #ws-arch3
08:49:01 [scribe]
David: To further this, we can break it down to three levels: WS (or connector) specific, industry segment specific, and application specific.
08:59:26 [scribe]
scribe has left #ws-arch3
09:03:16 [chris]
chris has joined #ws-arch3
09:13:52 [chris]
rrsagent, where am i?
09:13:52 [RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch3-irc#T09-13-52
09:43:33 [Zakim]
Zakim has left #ws-arch3
09:54:27 [TC]
TC has left #ws-arch3
12:01:49 [chris]
chris has joined #ws-arch3