WSC WG face-to-face -- 14 Nov 2006

<tlr> http://www.w3.org/2002/09/wbs/39814/wscweekly/results

Mez: if you have looked at those results, you will see there is no time that no one has specified as a 1 ..
... that said, looks like Tuesday at 9am US/Eastern ...
... only person who says he can't make that time is Brad ...
... bill gave it a 2 ...

Hal: 10 US/Eastern is a "sweet spot" ...

Mez: I'm still leaning toward 9am US/East

<bwporter> yes, before 7am PST is rough on the pacific

<tlr> 9am or 10am on tuesdays are options

<stephenF> both ok for me

rob: would prefer that we try to nudge the time till 10am US/East

Mez: for the record, it is Tuesday US time

<bwporter> 10am Tues conflicts with voice browser working group, but I can make trade-offs

<tlr> 10am Eastern, 7am Pacific

so we have a decision?

Mez: consensus is 10am US/east

RESOLUTION: The group will meet regularly at 10am EST on Tuesdays, for 1h.

<Nadalin> 1 hr right ?

<tlr> 1h

<stephenF> so that makes us 10 minutes into the first call:-)

Mez: please show results for next f2f ...

<tlr> http://www.w3.org/2002/09/wbs/39814/wscspring07/

<tlr> http://www.w3.org/2002/09/wbs/39814/wscspring07/results

Mez: we have not decided on the place ...

Hal: I have offered host on either coast
... personally I would rather do in Boston ...

PHB:who is from East Coast?
... and who is from West? ...

<stephenF> me, different island is all

<Tyler> lives on the West Coast

<bwporter> hard to hear the question from here

bwporter, which coast you live on

<YakovS> yakov - East Coast

<bwporter> west coast

<PHB> PHB is from the East

tlr: please indicate preference

<staikos> north america pref here :)

... East Coast, West Coast, or Dublin? ...

<staikos> east or west should be fine

<Nadalin> PHB Boston does not count

tlr: where should be go?

<bwporter> bwporter prefers north america (west coast opens up more dates for me to attend)

Mez: we will have somewhere in US

show of hands in the room suggests Boston

<bwporter> bwporter votes for san jose

tlr: we do need to consider need to rotate the meetings
... we have already had (now) first f2f on East Coast, also Workshop, also Nov 07 Tech Plenary in Cambridge ...

<Nadalin> yes and this one was on east coast

PHB: I can also do West

Mez: in terms of choosing dates, does the placement matter?
... host is BEA ...

Chris: Isn't there are holiday around there?

(Discussion around holding meeting in the 16/18 January time frame.)

MEZ: inclined to make decision off-line within those parameters

<staikos> oh correction, I'm in london england 18th->22

Mez: does anybody have problem with delaying decision until later today?

<Nadalin> what is the range ?

tlr: Everybody: fill in the questionnaire asap!
... see: http://www.w3.org/2002/09/wbs/39814/wscspring07/ ...
... we don't have enough responses to the survey yet ...

<bwporter> is there a new questionairre or the existing one?

<tlr> use the existing one, please update it

Mez: conflicts should be indicate by a 1
... make sure to add comments ...
... we are now on break for 30 minutes ...
... until 10:50 ..

charter review

Mez: let's do "chop through" the charter
... we have the afternoon to cover discussion of deliverables ...

<tlr> http://www.w3.org/2005/Security/wsc-charter

Mez: does everybody have access to the charter? ...

Mez: this is not about creating any new protocols ...
... this is not meant to disrupt or create new server-side protocols ...
... not meant to radically change the infrastructure ...
... phishing problem has created the need ...

hal: make that "social engineering" attacks

PHB: yes, so-called "pretexting" also

hal, PHB are making the point that problem is broader than just "phishing"

Mez: I am working under the assumption that we are not dealing with e-mail issues.
... attacks on the "human processor" need to be considered
... for instance, I have had some people send me "anomoly" stuff offline

Tyler: Example: Right now if I give you two X.509 certs, there is no way to tell if those came from same company?

Tyler, please type your question into IRC for the record.

tlr: We can always call on other WGs to request specs about some of this stuff.

<tlr> (both internally & externally)

Mez: Deliverables: Notes document, two Rec's, other stuff (see charter)

hal:as I understand it the scope is limited to cases where there is a human at one end of the wire

Mez: I agree.

<Tyler> Mez indicated "no new protocols"; however, I am hoping we can clarify use of existing protocols. For example, how can client software tell if two separate X.509 certificates were issued to the same company? For this question, we clarify how the fields in the certificate are expected to be used.

hal: we need to be more explicit by what we mean by the word "user"

<YakovS> Is handling of the mixed traffic (standard browser + web services) in the scope?

<YakovS> SOAP 1.2 GET bindings, REST scenarios, potentially WS-Trust challenge-response?

<Pau1> Scope: limited to users? Isn't the scope really limited to places where a browser is at one end point? In other words, we're not trying to solve the problem for WebDAV, CalDAV or other systems layered over http, right?

Tyler: my question was not about human issues, it was about we have no algorithm for identifying whether two X.509 certs are issued to same company

PHBthe information is what we need

<YakovS> yes

PHB: the current tools are tools for sysadmins, not for end users

Paul Hill are we talking about when there is a browser in the loop?
... as opposed to webdav / caldav ...?

Mezwe are talking about Web protocols...
... more broadly -- not necessarily just browser ...

YakovS: mentions specific Web protocols and wonders if they are in scope

tlr: charter does not rule those out of scope
... but we would need storytelling and use cases to motivate discussion about whether we want to include those ...

Mez: part of my job is to come up with useful use cases

<tlr> tlr: use cases and stroy telling are a generic requirement; see also note deliverable

Mez: the Note brainstorming might go longer than half a day
... we need to have the Note at least "really well fleshed out" by January
... I realize that there are a lot of holidays between now and then, that would be agressive ...
... but that is actually only 2 months from now ...

Mez mentions tombstone

tombstone = "small textual indicator"

<tlr> tyler: FPWD effects in terns of patent policy?

<tlr> tlr: for rec-track deliverables, not for note

Mez: January is actually the 3-month mark, as far as hearbeat goes
... Last Call for Note April ...

<Tyler> Tyler asked how detailed the first Public Working Draft is expected to be. This document triggers reviews based on the W3C patent policy, so avoiding a vague document is important.

Mez: That's it for schedule.
... the chair is the liason to the W3C Hypertext coordination group
... they seem to be delighted that there is now a separate security group to review all other WG's specs for security issues ...

tlr: there are some groups whose work does dovetail with our work ...
... and we do need to review their specs ...
... but review of random specs is not an explicit responsibility of this group ...
... that is, specs other than the ones that dovetail with ours ...
... Web APIS and WAF groups are ones whose specs we /do/ need to review

MezIETF, OASIS, Liberty, APWG ...

halWS-SX - secure conversation is still relevant...
... but WSS is close to completing their charter ...
... and probably not be meeting any more (or only meeting one more time) ...

hal: interesting question around single-signon protocols

Tyler: what is relationship with CA/Browser Forum http://www.cabforum.org/

<YakovS> I didn't hear whether SSO issues are in the scope?

<stephenF> just on irc not phone

<Nadalin> its WSSX

<hal> WS-SX TC at OASIS has as its scope WS-SecureConverstion, WS-Trust & WS-SecurityPolicy

Discussion about APWG

<tlr> ACTION: Thomas to organize call with APWG to discuss liaison mechanisms with WSCWG [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-2 - Organize call with APWG to discuss liaison mechanisms with WSCWG [on Thomas Roessler - due 2006-11-21].

YakovS asks if single-sign-on related use cases are in scope

Mez: It will be if we can find use cases
... and it gets into the Note ...

<Nadalin> +1

Mez: it is not ruled out of scope at this point ...

<Nadalin> Is federation in scope

tlr: we are talking to Liberty around generic liason mechanisms

Mez: IETF PKIX WG

PHB they have been officially in "wind down" mode for a long time (4 years?)...
... they have recently accepted new work ...
... e.g., they have interest around secure logotype ...

<stephenF> I'll have to exit for a bit in a bit so my DKIM query is whether or not this group want to think about the authentication-results work item that may be happening in DKIM

<stephenF> I can fill in details later but potentially one might end up presenting DKIM results to users

<YakovS> I assume that WS-Federation will also be in the scope assuming that use cases will be provided?

Mez: what I am hearing is that we do not yet have compelling need to name a liason for that?

<Pau1> There was also a recent individual draft submission within the IETF- "GSSAPI authentication for HTTP", Leif Johansson, 13-Oct-06, <draft-johansson-http-gss-00.txt>

Mez: I take it back, PHB will be liason if we need one ...

<hal> chair of Liberty Alliance Identity Theft SIG is Britta Glade britta@projectliberty.org

<Zakim> stephenF, you wanted to talk about DKIM and to

Nadalin: says we have covered his question already

<stephenF> just typed my query above if covered already great

Mez: DKIM is about e-mail ...
... so I am not sure it is in scope ...

PHB: if you look at use cases and storytellling, I think you will find that many originate in e-mail
... begins by when the get the e-mail message from attackers
... second is after they follow the link and go to the Web ...

Mez: e-mail is most prevalent form of first contact

Tim: first contact can be following a URL in a magazine

<stephenF> +1 to phb, question is about presentation of things like dkim results that may originate from a mail and affect whether the user directs their browser

PHB suggests making stephenF the liason, since he's the chair of DKIM

<stephenF> to DKIM? I can do that

<tlr> ACTION: Stephen to contribute use cases for Note [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-3 - Contribute use cases for Note [on Stephen Farrell - due 2006-11-21].

<YakovS> WS-Federation?

MezWS-Federation is *not necessarily* out of scope

hal: how are we going to liason with the UAAWG group?

Mez: through Hypertext coordination groupfor now

hal: we need to consider that early on to avoid wasted work

Mez: we have 40 minutes left
... before the break ...
... move on now to brainstorming about deliverables.

Mezthe Note documents use-cases and assumptions...
... I would like for it to have more data on what is in-scope and out-of-scope ...
... to help people think about the implications...
... and backgrounder, required reading ...
... What other things would people like to see included in the Note? ...

Mez: How about we brainstorm about use cases?

<stephenF> question is whether the more complex xml structures like XPath etc need special consideration here?

Tyler: are we going to consider cases where there might be a Trojan?

<stephenF> Personally I've no idea, but they are worrying since they're complicated enough to badness

Tyler: I would prefer to deal exclusively with cases where we know that the user's environment has not been compromised.

hal_: mentions ability of malicious software to alter browser chrome

tlr: we assume there is something on the client side that can implement certain behaviors, and can implement those reliably.
... assuming that we have this kind of reliable users environment, what kinds of things that we can do? ...
... negative screen coordinates ...

tjh: we would assume there is some level of UI(?) that is trusted

stephenF, is your question on this same topic?

stephenF's question appears to be on another topic

<stephenF> similar; my concern is specifically that xpath, xquery etc are generally not part of security analysis

PHB: we need to define boundary between platform and...
... for example Javascript-based UI issues ...
... are we going to consider code downloads to be in scope ...

<tlr> PHB: Javascript as web context in scope, as programming language for browser, out of scope. it's where stuff comes from, not what technology is used.

... I would suggest that we should not ...

<staikos> code downloads can do anything - not worth dealing with

Mez: would like to keep malicious code out of scope if it didn't get there through something mechanism that is in scope for this WG

hal: there is some kind of TCB that you have to assume is functioning

<Zakim> stephenF, you wanted to ask about xquery etc

<stephenF> yep - I think Mez is right but would like someone (who knows, not me) to consider whether xquery/xpath etc when thinking about

<tlr> stephen, people are confused and second-guessing what you talk about.

<stephenF> ...active content you may download. So just a "don't forget" type note is enough for now

<stephenF> I can send a mail later this evening

Mez:stephenF, please do

<stephenF> ok

some brief discussion about security considerations around XSLT document()

tlr: I think it is out of scope for this group

Tyler: phishing pages checking for browser cache/history
... can enable fraudster to more effectively target a phishing attack ...

tlr: that information is collected through a not-trusted path

<stephenF> gonna disappear for a ~1 hr again

tlr: I don't think it something that we should be trying to address soon ...

Tyler: example: should we state that CSS should not expose the browser history?

tlr:that is a known issue and out of scope for this group

Mez: I'm wondering if we want to sketch out in the Note where our works falls in the Universe (universe of security issues)

<Nadalin> Phone problems !

PHB:privacy issues...
... stopping J. Edgar Hoover from knowing what I'm up to ...

tlr: this becomes relevant if we go down the route of "use history information as a trust piece"
... but it is not the job of this WG to deal with, for example, cross-domain scripting issue ...

bwporter: we need to talk about what classes of browser we are covering

<tlr> break now

<tlr> back at 1pm Eastern

Mez: if anybody finds there is some class of browser we are not covering, let me know

break time

<Zakim> tlr, you wanted to put yourself into the queue

<YakovS> also may return a little bit late

<tlr> please fill in this form: http://www.w3.org/2002/09/wbs/39814/wscspring07/

<tlr> Issue and action tracker is linked from group home page

<tlr> See http://www.w3.org/2006/WSC/Group/track

<tlr> Looking at http://www.w3.org/2002/09/wbs/39814/wscspring07/results, I think we have a clear winner: 30/31 January

<tlr> we'll reconvene in 8min

<tlr> meeting reconvenes

<tlr> ScribeNick: tjh

Mez: suggestion
... as part of each use case/scenario, there should be an ACTION assigned to them to follow through on the use case/scenario.
... resolution could be to drop it or to formalize the scenario in a wiki or e-mail.

dinner reservation at a Tapas place - 120th and Amsterdam

Mez: opens the floor to use case brainstorming
... please, the harder, gnarlier the better

quiet in the room

tlr: lets try to go after the easier ones first

PHB: lets tell a story, and find what is in and out of scope
... we talked about phishing
... Alice gets an email (supposedly from BUsyBank)
... Alice clicks on link ... lands on a site
... that site asks for credit card number and PIN (but this is a phishing site)
... root1 - Alice enters site and enters data
... root2 - Alice notices that this is a phishing site and navigates away
... root3 - Alice picks up the phone and calls BusyBank (costing BusyBank $10 to answer the phone).
... in 10% of cases, the user then goes on to enter the spoofed site and enter their information.

tjh: did they just not notice?

PHB: this does seem to be happening. In some of the cases, it is that the user has already given their information out before they called the bank.

MEZ: another scenario - BusyBank really does send the e-mail out.

<tlr> ACTION: Hallam-Baker to formalize the scenario of user getting a request via e-mail and using that information to contact a web-site using HTTP protocol (e.g. using a browser) [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-4 - Formalize the scenario of user getting a request via e-mail and using that information to contact a web-site using HTTP protocol (e.g. using a browser) [on Phillip Hallam-Baker - due 2006-11-21].

Chris: if you e-mail a bank, they have a site where they log various phishing attacks - perhaps we could get banks to get more comfortable with sending e-mail out.

PHB: stepping back - there are some cases where the user has no prior relationship with the bank.

Chris: wait - there are finer levels of that - you may have an account but not have done anything over the web yet.

PHB: 1) no relationship
... 2) have an account (but no web access)
... 3) have an account (but have used the web access)

<Pau1> Remember that banks do, or used to, get acquired. (Bank of Boston acquired by BayBank which was acquired by Fleet which was acquired by Bank of America...)

Chris: have chosen not to address the "no relationship" case because this falls under "know your customer"

<tlr> who joined?

tlr: while not in scope for Chris, it could be in scope for the WG.

PHB: different forms of authentication here
... 1) initial authentication
... 2) primary authentication (one time password, userid/password, etc.)
... 3) secondary authentication (cookies, etc.)

MEZ: other industries besides financial?

PHB: original authentication applies to many cases, "almost everything I do"

MEZ: mis-typing a URL (whether I've been there before) is a use case.

<tlr> ACTION: Zurko to formalize the use case of mis-typing a URL (and various variants - been there before, not been there before) [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-5 - Formalize the use case of mis-typing a URL (and various variants - been there before, not been there before) [on Mary Ellen Zurko - due 2006-11-21].

PHB: impossible to eradicate typos

MEZ: while doing use cases, we would want to investigate different ways in which some set of information is made to look like other information
... right now, all we have are URLs - in the future perhaps we would have other forms of information to use. For example - history.

Tyler: Phil has said we should not try to weed out typos (after all, they may NOT be typos).

PHB: preventing registration of the domain names is NOT feasible ... the browser could do something.

Michael: Opera is doing something about this already - we have registrars on a white-list who have a process in place that prevents registering domain names that are similar to other names.

PHB: want to be clear - we don't want to give recommendations to ICAP.

Michael: we don't have the insight on how to spec this - even at the mixed case level, let alone the use of Kanji characters which may look similar.

tlr: summarizing - we should make no assumptions on what constitutes a domain names. And should not do something that leads to domain names being understandeable.

Mez: if it is security context information, then it ought to be in-scope; but outside of that, it's not clear what should be exhibitable.

Tyler: perhaps an example of this is that, for HTTPS - domain name in a URI should NOT be displayed, but rather the domain name from the CN field of the SSL-sent server certificate.

MEZ: should be vetted in a use case

Tyler: this is starting to overlap with other anti-phishing groups - which are saying that to combat phishing, make your URLs look pretty

Hal: there are some browsers that are starting to look at this type of thing.

PHB: you might have a rule (as a browser) that if you receive a URL that is of a deprecated form, you should do something other than just go to that site.

tlr: there is a difference between using URLs as communication from the user and communication to the user.

MEZ: what is the security context information available to us that is useful?

PHB: perhaps there is information that falls through the cracks when an e-mail program hands off to a browser.
... today, any info about how the info was displayed to a user or if it came in a signed form is lost by the time the browser gets a hold of the URL to use.

Michael: would need a whole lot more communication between the two programs

PHB: would need some APIs or data flow between processes

MEZ: was hoping that our recommendations would be implementable without major infrastructure changes

Hal: can a browser distinguish between a URL that has been typed and a URL that has been clicked (in another application)

tjh: it depends (on how invoked)

Hal: then it is not always true ... and thus is an issue

PHB: I could envision a way of solving this without OS changes

Tyler: is there consensus with the group indicating that users should NOT rely on informaiton in the URL for security context?

<scribe> ACTION: Tyler Formalize the statement regarding users not relying on information within URL strings for establishing context (or security context) [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-6 - Formalize the statement regarding users not relying on information within URL strings for establishing context (or security context) [on Tyler Close - due 2006-11-21].

<Yakov> It's OK on the phone - certainly better than it was :)

tlr: lets get back to "we have a person who needs to do something on the web, what information do they need to do it?"
... would like to hear a use case story involving Federation scenarios.

Hal: issue of going somewhere and authenticating there (the site probably used SSL). But in a federation, you might be re-directed to another company
... and you (user) are expected to trust where you landed.
... is there a problem here? Or not?
... in reality, you're getting handed off to several different locations and sites all with different policies.

<scribe> ACTION: Hal Formalize use case around user contacting one site, then getting re-directed to another (as part of a federation of organziations working together, legitimately), how does the user trust where they landed on? [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-8 - Formalize use case around user contacting one site, then getting re-directed to another (as part of a federation of organziations working together, legitimately), how does the user trust where they landed on? [on Hal Lockhart - due 2006-11-21].

PHB: we see massive spikes in various types of crime because something was working before no longer works so the attackers move on to something else.

Hal: that phishing continues means that the technology is still allowing it.

MEZ: there seem to be use cases around SSL - this seems an active area for browser folks right now.

Hal: how about this - using cache poisoning, you can make it look like you are from BusyBank. And recognizing that some SSL session is in place, you can capitalize on it.

MEZ: what is the issue?

Hal: the screen looks like it is SSL-protected, but it is not.

<staikos> We have to remember that user education is even a blocker here. Drawing a padlock in the page is often sufficient

<staikos> not yet :)

PHB: this was very much the case before IE7 came out. Lots of pieces in IE7 are designed to thwart this (by stopping people from creating windows that obscure the padlock icon)

<Pau1> And we even see real bank sites putting padlocks into their html pages, which tends to teach users to accept that as an indicator. Shouln

<staikos> http://www.staikos.net/~staikos/isitencrypted.png

Rob: have two cases.

<malware> Pau1, right. Those banks should really not be doing that.

Rob: 1) building on surfacing the domain name out of SSL server certificate. Problem still remains with old HTTP sites not signing their traffic.

<Pau1> So a best practices guideline should point that out.

Rob: will need a set of recommendations on how to represent the security identifier for this HTTP site.

<malware> Pau1, agreed

Rob: some sites will scramble the URL to fiddle with the Address bar to give the impression of a standard HTTP site.

<scribe> ACTION: Rob Formalize the use case of an attacker messing with the information in the address bar and confusing the user. [recorded in http://www.w3.org/2006/11/14-wsc-irc]

Created as ACTION-29; provisionally allocated to tlr in order to track action until Rob joins group.

Michael: we have cases where parts of forms (from content providers) will add "lock" icons to their content ... thus diluting the meaning of such icons that are meant for the browser "chrome".

<PHB> The problem I see is misdirection of the user, telling them its safe whan its not, in particular the issue of FAVICONS,

<malware> staikos's png is exactly what I was talking about

<malware> http://www.staikos.net/~staikos/isitencrypted.png

<rfranco> status bar is another example...

<staikos> I use that site regularly :)

Tyler: FAVICONs are just one example. there are other areas that are over takeable as well - so need chrome, but FAVICONs aren't the only target.

<staikos> very often the case that APs use invalid or expired SSL certificates

<Zakim> rfranco, you wanted to raise another use case

Tyler: have to get to a point of NOT presenting un-reliable information as if it were reliable.

Rob: agree. We also need to accept some of the realities of how the Internet is today.

Rob: use case 2: give users better information about content they have downloaded that is not text (e.g. script, .exe)
... rather than have debate about launching these things (which is another issue), can the user understand where the information ame from?

<tlr> ACTION: msmith9 to formalize the use case of content providers using the same icons as are typically used in the "chrome area" and thus diluting the meaning of such visual aids [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-9 - Formalize the use case of content providers using the same icons as are typically used in the \"chrome area\" and thus diluting the meaning of such visual aids [on Michael Smith - due 2006-11-21].

<staikos> http://www.skype.com/download/skype/macosx/downloading.html?download=Download+now <--- look at the evil instructions that Skype gives in this page

<PHB> reply to staikos - too many restrictions means we end up training users to circumvent them

MEZ: security people who have designed interfaces before have concentrated on attacks

<staikos> exactly

<staikos> and too many circumvention mechanisms means they will all be used

... Are we going to discuss PKI and information from this? ...

billd: other forms of authentication (one time password, PIN)

Tyler: how much does that step into not creating new protocols?
... since they are not in the browser yet

MEZ: not in the browser is not the same as not in the protocol.

<Zakim> phb, you wanted to say should talk about the user part of the context, ie wetware, what is in their head

<staikos> the concepts of cardspace and wallet seem to really -really- help users

<staikos> KDE users are completely addicted to KWallet, and that's the simplest implementation of the concept I can imagine

PHB: user context is not the context on the machine but the user experience context in the user
... user's head.
... hundreds of usernames and passwords are unweildly and un-rememberable within a user's "context"

Hal: sites I use INfrequently I am inclined to use the SAME password while sites I use heavily (and thus remember) I am inclined to use something else

MEZ: reviewing items from the charter:
... GOALS/SCOPE
... NON GOALS/OUT OF SCOPE
... Background/References
... Validation/User testing
... USE CASES/SCENARIOS

<PHB> There seems to be a methodology here differential use case analysis

<PHB> You specify a pair of good/bad use cases

<Zakim> tjh, you wanted to ask about HTTP headers

<PHB> Requirement is satisfied when you are able to distinguish them

Hal: I see no use cases where there is no chance of attack

MEZ: on tjh's question about defining new HTTP header fields for additional information - this feels to be out of scope as it is close enough to extending protocols.

Hal: highest priority should be those that a single organization can implement without requiring another organization - and these can provide incremental benefit.

MEZ: not sure if that privileges or disadvantages organizations with a larger scope

Tyler: we talked about it being nice to have chrome ... but we don't have it.
... would it be good to state that we should provide chrome?

tlr: see deliverable 3

?: working with chrome is not good enough - because if it shows up on the screen, it's going to be considered trusted.

Tyler: existence of the "secured area" needs to be both in the mind of the user and in the browser ... so has to be consistent.

Sunil: if browser did all of this - we still have the problem of each service provider/content provider wanting to show something different or value-add.

MEZ notes use cases can cover ATTACKS, NON-ATTACKS, and Content practices.

<Zakim> malware, you wanted to talk about making behavior consistent across browsers

Michael: consistency across browsers - agree - that this will not be useful if not consistent.
... advice for this is that the group as a whole should get as many browser vendors as possible involved.
... value of the feature must be clear to the browser vendors (so they will invest in providing it)
... in desktop space, pretty much one browser is used.
... in the mobile space, there are MANY more browsers. And there are other constraints.

MEZ: more categories for use cases: protocols, sec context, browsers/VAs

Michael: mobile devices: Nintendo DS, palm phones

tjh: Sony PSP contains a browser

<tlr> ACTION: msmith9 to find mobile browser vendors to recruit to group [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-10 - Find mobile browser vendors to recruit to group [on Michael Smith - due 2006-11-21].

Michael Smith later noted that he felt uneasy about this action item. It is closed in the issue tracker.

Hal: there seem to be some use cases involving a shared computer.

Sunil: or the kiosk situation

MEZ: and kiosks within enterprises

Hal: and user portability (without carrying their device)

<Pau1> One of my coworkers is the "mobile device platform coordinator" for MIT's IS&T department. He was also the founder of a former mobile device company. I can commit him to be a reviewer in this area.

<scribe> ACTION: Hal Formalize a use case for using a browser on a shared device (e.g. kiosk device). Examples of kiosks intra-enterprise, hotel lobbies, Kinko's, libraries. [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-11 - Formalize a use case for using a browser on a shared device (e.g. kiosk device). Examples of kiosks intra-enterprise, hotel lobbies, Kinko\'s, libraries. [on Hal Lockhart - due 2006-11-21].

Billd: how well is security context information managed with the user to make it useful?
... is there a way to convey a level of trust in that session?

Hal: should define, by enumeration, what is meant by security context infomratoin

<PHB> The idea of 'Member since' in certs has come up a few times

<scribe> ACTION: Hal List, by enumeration, what is meant by security context information [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-12 - List, by enumeration, what is meant by security context information [on Hal Lockhart - due 2006-11-21].

MEZ: existing authorities can provide additional context information.

<stephenF> FYI: sent a mail about that xpath stuff, as promised http://lists.w3.org/Archives/Member/member-wsc-wg/2006Nov/0018.html

Billd: have seen reasonable authorities generating so-noted "bogus" certs ... there should be some level of trust capable in these entities - right?

<tlr> stephen, please send e-mail to public list

PHB: would be unhappy if this group started talking about how CAs work or how the CAs validate information that goes into certificates.

<staikos> definitely

<staikos> suggestions of usefulness of these things would be very valuable

PHB: but if this group wants to talk about information to put INTO the certificate ... that would be good.
... examples - logotype, or MemberSince information

tlr: back to kiosk use case for a bit - and on what information is passed between users.
... assume we have a browser that recognizes one user at the time ... to keep us from getting into issues of user-to-user "bleed over" of information.

<stephenF> tlr, done - btw is there a URL for the irc log?

Hal: but we have some things that are coming along for authentication that are only useful if a user's system is not compromised (or used by multiple people)

Tyler: would be nice if CAs could indicate what algorithm to use in extracting the relevant information from certificate chains.

PHB: this gets tricky based on certificate type, and CA vendor's practices.
... Verisign has not commented on certain aspects of Policy OID discussions because it hasn't seen value in it.

Tyler: on some banking sites - you login and then get re-directed to another system that has a different certificate (because the system is a different one than the first one)
... would be useful to be able to indicate that this is, really, the same entitty.

<tlr> ACTION: tyler to elaborate on multiple certificates & domains for session servers case [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-13 - Elaborate on multiple certificates & domains for session servers case [on Tyler Close - due 2006-11-21].

Tyler: what is used right now is end entity information.

PHB: would recommend using the certificate serial number information

<malware> tjh: mentions work of Amir Hertzberg

<malware> http://www.cs.biu.ac.il/~herzbea/

Tyler: would be good if CAs could describe how to do it reliably

<malware> Tyler, is that the person you meant to refer to?

PHB: note above about using certificate serial number is patented

<stephenF> phb, got a patent # for that?

<Pau1> Isn't a CA bridge usually target for use when a number of organizations can't agree on a common root CA?

Chris: what certificates are available and valid within the company is now a cost for them (costing them resources to maintain). They are now creating a "CA Bridge" to help address this.

tlr: case of having two session servers where critical context information varies between session servers. What should be invariant in order to be useful?

<PHB> stephen, the assignee is VeriSign. don't remember the inventors. Think its from peter William's time

<scribe> ACTION: Hal write up use case of session servers and having critical information invariant in order to be useful. [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-14 - Write up use case of session servers and having critical information invariant in order to be useful. [on Hal Lockhart - due 2006-11-21].

<PHB> like if people really wanted to all copy the way we do things we might talk about putting the patent on the table, but I really don't think that is a good idea

<tlr> I thought the action that got added as ACTION-14 was on Tyler?

Billd: CA Bridge would seem to change the degree of trust in that site?

<tlr> (And is actually ACTION-13?)

(ACTION-14 was indeed a duplicate of ACTION-13, and therefore closed immediately.)

<Pau1> It sounds like they are using CA Bridge model as a way of partitioning the management of certificates. The model can also be used to keep CRLs small. But I can't imagine that a bank is running into issues with the size of their CRLs.

<PHB> remember that the one useful function of the USPTO is to keep bad ideas out of standards.

Mez: concerned about kiosk use being out of scope

tlr: kiosk - machine is shared, and browser state NOT cleared between different users using.
... this is what I meant to be out of scope - because it is clearly a misuse of the tools.

tjh: but how does a user know not to use a kiosk or not?

<PHB> [Would like to suggest that we distinguish a scenario and a situation, we have a small number of scenarios (alice gets email, goes to Web site) and a larger number of situations (kiosk, web browser, mobile, roaming, etc]

tlr: you have no way of knowing ... thus no way of trusting ... thus out of scope because it cannot be a known "TCB"

<tlr> ACTION: Zurko to produce use case story for kiosk case that is in scope (action can be discharged by declaring defeat) [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-15 - Produce use case story for kiosk case that is in scope (action can be discharged by declaring defeat) [on Mary Ellen Zurko - due 2006-11-21].

Tyler: one way to get some of the kiosk scenarios out of scope is a discussion of viruses. The next user is getting access to information much like a virus would.

maritza: people who would do online banking at a kiosk are the same that would fall for a phishing attack...
... since they do not have a mental model of what is secure and not secure ... why not include such issues?

tlr: it is a different problem of whether a MACHINE (that I walk up to) is "secure" from the problem of understanding if a page displayed on that machine is "ok".
... this is about scoping down to what we can accomplish.

Billd: within the available protocols, is it possible to determine if you are on a shared system or not?
... within the current capabilities, it seems we cannot do it.

Sunil: one extreme is airport kiosk ... this seems too hard.
... but there are other situations (enterprise kiosks) that could be assumed trusted in some sense ... how about these?

<stephenF> on kiosks - if the browser were to declare itself as one in some way the user understood...how to do that might be in scope?

<PHB> Point of information, is possible to know if you are on a trustworthy kiosk if you have TOFKAP and know one trustworthy node that can verify TOFKAP status.

<stephenF> me disappearing again for ~30 mins

Billd: back to existing standards - TOFKAP is a proprietary mechanism and so it doesn't appear to be something we can base upon.

PHB: perhaps this is a point that we can just note that there are things that other groups are doing and doing better than we could do
... thus we would not want to go into that here.
... (on the issues of trusted computing)

Michael: we will not rely on anything proprietary.

<tlr> reconvene at 15:25

<tlr> To minute a hallway conversation: The real question around kiosks is whether we should make the assumption that user agent state is limited to one user (or one session, for that matter), or whether that assumption should be relaxed into state-leaking kiosks and an investigation about what these mean for security contexts -- think context linked to browser history.

Mez: during the break, considered how to proceed for next couple of hours.
... walked around the space - will be useful as we start to write the use cases.
... would be good to get a list for things now:
... security context information
... protocols
... browsers

Hal: we haven't exhausted the things that could be improved by better user interface

Billd: if we drill further down on enumeration - would other stuff bubble up?

Mez: yes.

Hal: ok, that sounds reasonable

Mez: let us enumerate security context information
... URL
... SSL in effect, what properties of it
... any data we have about current situation that did not come the current website
... browser history
... configured trust roots
... referring page

Hal: would not configured in trust roots

Yakov: cookie in browser, request headers
... Use case - document-based security context (something in the HTML/XML document).

<rfranco> FYI, my return to the call is delayed another 20min, sorry

<scribe> ACTION: Yakov Formalize the use case of flowing security information as a part of the document mark up (as in XML marked up content information). [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-16 - Formalize the use case of flowing security information as a part of the document mark up (as in XML marked up content information). [on Yakov Sverdlov - due 2006-11-21].

Malware: security context info: your web of trust - people you trust and sites those people trust
... if you go to a site, you would have some way of knowing that someone else you knew was on that site.

Hal: Netcraft toolbar (which can give additional information about sites landed on)

malware: web of trust maps to talking to someone in the real world, and based on their input, go and use it.

Mez: is there something to these being from a trusted channel versus an untrusted channel?

Tyler: notes a bookmarking addition that logs annotations about sites visited (and are displayed in chrome area when sites are re-visited)

Malware: mozilla working on some type of annotation mechanism too

Mez: might be good for a demo - can we do those?

tlr: we can share URLs - but not live web demos via W3C infrastructure.

<tlr> (but happy to use infrastructure if anybody has something available)

<scribe> ACTION: Tyler Give a demonstration of "pet name" annotation of bookmarks plug-in [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-17 - Give a demonstration of \"pet name\" annotation of bookmarks plug-in [on Tyler Close - due 2006-11-21].

more sec context info:

<malware> the mozilla mechanism is something they have described as "microsummaries", for putting dynamic text into bookmarks

HTTP basicAuth headers

<malware> http://wiki.mozilla.org/Microsummaries

<malware> Myk Melez did the work on that, I think

<Yakov> Should we separate "dynamic" context (like HTTP headers) versus persitent (cookies)?

Hal: don't agree to limiting it to information coming from the site.

<malware> I am interested in the idea of the pet-name or microsummary getting the annotation over the network instead of just locally stored

<malware> though I recognize such a mechanism would have security issues of its own

reputation service

past introductions from friends (e.g. in email)

<malware> but microsummaries are actually getting data over the network, actually

automatic re-direction (that the browser was re-directed here rather than the user requesting)

Billd: there is the attribute of password protection or not (protocol protection attributes)

PHB: the more general case - when people typing in information that is sensitive to them, they need to understand that it is going to be handled securely.
... difference between Basic authentication and Digest authentication (and there is NOTHING to tell the user what is going to be used)

<Yakov> leaving earlier today

Tyler: from workshop - there was a paper noting that there is no difference between Basic and Digest because Digest can be cracked so easily

<Mez> take care Yakov

Tyler: issue is who I am giving data to (not what they do with it - because one cannot control what is done with it)

Billd: with SSL used, can change cipherset such that encryption NOT used. So this site would look good, not really be good.
... should be able to figure out underlying mechanism used.

<tlr> ACTION: Doyle to formalize the need to be able to understand/visualize the "strength" of SSL protection in place [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-18 - Formalize the need to be able to understand/visualize the \"strength\" of SSL protection in place [on Bill Doyle - due 2006-11-21].

<staikos> there are discussions to make some of these "warnings" impossible to circumvent

<tlr> staikos, want to be on the queue?

<stephenF> on ssl - there was a suggestion to build in "evidence" generation at the IETF last week, dunno if accepted (hopefully not) but it came from a reputable source

<staikos> let's here what PHB says first :) It's a bit difficult to talk with the group over the phone

Michael: there are many different scenarios and logic paths in handling SSL connections.

<stephenF> URL for that ssl evidence thing: http://www3.ietf.org/proceedings/06nov/slides/tls-1.ppt

malware: what should be done and what should not be done is sometimes unclear.

Hal: for the minutes - when you ask about this - you hear that pop-up boxes are "bad", you also hear that users just click through pop-up boxes.

PHB: the Internet is insecure by default.
... should not tell people when they are insecure (because this is the default) ... should only tell when secure. This is a change in perspective.

<stephenF> phb, when were you last secure? :-)

<Zakim> staikos, you wanted to mention that there are discussions to make some of these "warnings" impossible to circumvent

<PHB> I am secure when the probability of loss times the expected amount of the loss is within acceptable parameters.

Staikos: popping up the question that user is possibly insecure and what do they want to do is likely in need of change.

<stephenF> phb, so sometime in 1995 then:-)

Staikos: if we look at these cases, perhaps we'll learn more.

<PHB> This last happened on January 19th 2001

malware: this gets back to consistency between browsers again.

<staikos> Fully agreed with Michael

<staikos> one browser is considered "broken" if it can't view a site that other browsers can

malware: if can't get to one site from one browser, user will interpret this as a browser bug, not a fault in the site.

Hal: another item - IP address.

<stephenF> my question is whether we want to think about locally trusted

Tyler: some sites are starting to offer "general location" of server based on IP address - list it

<stephenF> devices, e.g. phone etc.

Billd: this is not secure - because the IP address can be spoofed

PHB: we have used IP address to deny services before.

<stephenF> just on irc still btw

<Zakim> stephenF, you wanted to ask about locally trusted devices

<stephenF> yes - sometimes people talk about using trusted local

<stephenF> stuff (e.g. phone), we might want to just note that for

<stephenF> now

Michael: there is the notion of combining various sources to build up a base.

Billd: Example - site that you visited before, but the cert has expired ... you might still trust it. ... that sounds feasible

<stephenF> (advertisement: xkms can nicely ignore expiry:-)

<malware> maybe something like a progress bar to indicate the level of security (aggregating all the different factors)

Billd: methods of authentication - id/passwords; others

<malware> or like gauge that indicates how high battery level on your laptop is

Billd: shared secret knowledge (personalization info, pet name, picture, etc.)

<malware> thermometer is the simplest analogy, I guess

PHB: is there a need to note ANTI-PATTERNS?

PHB: anti-pattern: supplying "shared public knowledge" (e.g. mother's maiden name, zipcod)

some discussion about anti-patterns being placed into the recommendation, not the note.

<PHB> Thomas: did we come to closure on the date of the F2F 2.0? Just noted that there is a MAAWG meeting in San Francisco 29-31 Jan which means that is most likely when the san fran APWG will be.

<tlr> phb, I thought their next meeting is in June?!

<tlr> Dublin?

<tlr> "their" = APWG, not MAAWG

<PHB> They have a european meeting and 2 north america

<tlr> (right now, 30/31 Jan has the smallest number of conflicts)

<stephenF> maawg are here june 5-7, 2007

<stephenF> maawg are in San Fran, jan 29-31, 2007

<scribe> ACTION: tim formalize a user-facing use case for WS-Security (e.g. use of WS-SecureConversation) [recorded in http://www.w3.org/2006/11/14-wsc-irc]

<trackbot> Created ACTION-19 - Formalize a user-facing use case for WS-Security (e.g. use of WS-SecureConversation) [on Tim Hahn - due 2006-11-21].

tjh: said use (ACTION-19) would lend credence to listing WS-Security attributes as security context information that would be useful.
... what about AJAX-style communications between client and server?

tlr: this is HTTP and some type of structured content that flows within the content area

PHB: view AJAX as a form of constructed content.
... when a page comes from one source, it might be trustable or more trustable than if it comes from here, there, and everywhere.

<malware> I suggest that for sake of precision that we don't use the term "Ajax"

<tlr> +1 to malware

<Zakim> malware, you wanted to talk about using "XHR" = XmlHttpRequest instead of Ajax

<stephenF> ok that's me done for the evening - if you include a summary agenda slot tomorrow, I'll dial in to the audio for that otherwise I'll be on irc tomorrow

<staikos> JSON - JavaScript Object Notation

malware: the term Ajax is imprecise. use XHR - it means asynchronous communication using XmlHttpRequest.

<staikos> uses ECMAScript syntax as a mechanism for serializing objects

tyler: context info: has the page completed loading?

Mez: this seems to exhaust our brainstorming on this list/enumeration
... how about looking at browser/user agent list next.

Hal: charter says "on the web"

tjh: so does that mean anything that speaks HTTP protocol?

Hal: that seems necessary but not necessarily sufficient as a definition

Billd: include HTTPS as well

Mez: list browsers

Opera

Mozilla

Konquerer

Netscape

<staikos> Safari

Safari

<Pau1> Pocket IE

<staikos> Series 60 Browser

Firefox

<tlr> blazer

<staikos> There are numerous KHTML/WebKit based browsers now, just like numerous Gecko based browsers

iCAB

Camino

Camino is Gecko-based

Shiira

curl

wget

elinks

Notes

EclipseRCP

<tlr> add amaya it's a browser as well

phone: e-mail clients are using web-engines for rendering e-mail.

<staikos> tjh: that was me btw :)

rfranco: even things like Quicken are using IE object to display content, but chrome is handled by the program.

<staikos> the question is, does the application allow navigation to uncontrolled content

<staikos> in Email, this is the case

<staikos> in applications, not necessarily the case

malware: some of the other vendors are not investing in standards work so uncomfortable listing them.

<malware> http://en.wikipedia.org/wiki/List_of_web_browsers

<malware> http://en.wikipedia.org/wiki/Comparison_of_web_browsers

<malware> my comment that tjh refers to was specifically in relation to vendors of mobile browsers

malware thank you for clarifying

<malware> further for the record, I very much would like to see as many browser vendors as possible getting involved in the work of this group

tlr: recommend categorizing types of browsers -- what are the different constraints on user interfaces? ...
... think mobile phone, think screen reader, think braille line ...

Hal: key question is who/what is in control of the display of the security context.

<tlr> tyler, can you make that "constrained UI" instead of "constrained I/O"?

<malware> http://en.wikipedia.org/wiki/Microbrowser

<malware> above is list of mobile browsers

Hal: heavy client on the list or not depends on who controls the rendering and who controls the chrome.

Mez: does the notion of portlets and proxies play here?

Hal: this is back to not all the content on a page coming from one place.

tlr: the general idea of aggregated content (not limited to XHR, but XHR is an example)

<Zakim> malware, you wanted to talk about "combined" pages

<scribe> rob, please try to summarize that statement into the IRC - I missed it.

<staikos> anyone have a Mac to demonstrate?

<staikos> Hit F12

<Pau1> Konfabulator works on Mac or Windows.

<staikos> http://www.apple.com/macosx/features/dashboard/

<staikos> yes :)

<staikos> can you guys email me dinner?

<Pau1> FTP (food transport protocol)

<malware> staikos, will send you some tortillas in exhange for KDE stickers

Mez: beginning to wrap for the afternoon

<staikos> I still don't even have a stuffed Konqi

Mez: still looking for an editor
... should there be a wiki for this stuff or not?

tlr: we have dealt out a lot of action items - good application of a wiki. However, an editor must grab that stuff and put it in specification format and polish it.

Tyler: I will write if someone will help supervise

tlr: will help with technical

Tyler: chosen as Editor.

<tlr> ... for note

Meeting adjourned.

WSC WG face-to-face

14 Nov 2006

Attendees

Contents

Welcome

Agenda Bashing

W3C Process and Tools 101

Scheduling

charter review

Summary of Action Items