Web Application Security Working Group Teleconference

21 Sep 2015


See also: IRC log


bhill2, dveditz, francois, Jonathankingston, gmaone, mkwst, deian, KristijanBurnik, jww, rbarnes, terri
dveditz, bhill2


<trackbot> Date: 21 September 2015

+present bhill2

<mkwst> +present mkwst

<Jonathankingston> +present Jonathankingston

<mkwst> (Hope that does something... ;) )

<francois> +present francois

<Jonathankingston> haha

(I can't remember which side the plus goes on!)

<mkwst> If wseltzer is still around, I'm sure she can help.

<Jonathankingston> https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=%2B%22present%2B%22+w3c&nfpr=1 << suggests after

<gmaone> +present gmaone

<scribe> Meeting: WebAppSec Teleconference, 21-September-2015

<dwalp> +present dwalp

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0136.html

minutes approval

Minutes Approval : 12:05-12:07

<dveditz> http://www.w3.org/2015/08/24-webappsec-minutes.html


dveditz: minutes approved by unanimous consent


TPAC coming up

bhill2: hotels are filling up fast in Sapporo, book now

SRI status and issues:

<dveditz> freddyb: just use the phone :-(

francois: not much to report spec-wise
... in final cleanup phases
... expect to announce ready for CR soon
... 2 implementations shipping

<dveditz> https://github.com/w3c/webappsec/milestones/SRI-v1-LC

francois: tests are close to passing

<Jonathankingston> I'm not sure if this has been checked in browsers yet: https://github.com/w3c/web-platform-tests/pull/2028 I think there are other fetch tests needed somewhat

francois: failing closed vs. open when CORS attribute is missing is main open issue
... what remains is a corner-case extension of that
... not a big one

dveditz: target date for CR?

<bblfish> ah yes, JS libraries for example

here's a nice example: http://githubengineering.com/subresource-integrity/

mkwst: should do what I did, send a note "we think we're done" to a number of lists and wait for no response

Credential Management

<mkwst> that is, something like https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html

<mkwst> seems effective enough. *shrug*



mkwst: some revision since last WD publication, mostly in response to input from Credentials CG and Web Payments IG
... believe we've resolved the majority of conflicts and API is pretty stable and solid
... Chrome has a reasonable impl of the API behind a flag, want to work on it more, especially UI
... but does what we want with passwords, questions about federation are still more open
... question at the moment is how to present federations both to websites/relying parties and the identity providers themselves.
... currently a relying party mode, where RP declares which origins it supports federations from
... another model is to declare support for e.g. "OpenIDConnect"
... think we need an origin-based model, that is what many RPs are using today

<rbarnes> +1 to using origins

mkwst: need to give them the ability to specify their trust relationships in that way
... but also important to support protocol-based declarations to support the long tail
... should be able to do same synthesis logic as for origin based credentials
... my proposal is to have a static method on the cred object to associate a protocol with the origin registering
... so RP could declare support for a protocol and user agent could map that to origins at which user has that kind of relation
... biggest remaining issue then is to figure exactly what we are doing with protocols

rbarnes: might be useful to port some identity provider proxy stuff from WebRTC, seems like spec may be moving sorta in that direction
... have a personal todo to see if that makes sense

mkwst: do think IdP proxy is interesting and we should look into it
... currently spec can treat passwords as an opaque form data object that is only accessible to the network not local script
... a very light version of what IdP proxy provides, hope its enough, but interested in exploring what it could provide

rbarnes: would importing something like IdP proxy help unify these two cases: opaque password submission and entirely opaque credential for federation

mkwst: when we define data provided by federatedCredential, currently it is just a hint
... next step, deeper integration in browser, requires protection of tokens where IdP proxy might be interesting way of doing that
... anyway - close to what I consider a first cut is done
... requesting feedback from 1Password
... users of Android equivalent APIs are interested in using it on the web

dveditz: could browsers on Android use the backing store to support this API?

mkwst: would have to talk to android folks, but there is broad conceptual similarity
... reasonable to move into "wide review" and advancing past WD in a few weeks, but needs more feedback from other browser vendors

<bblfish> It's odd because Ryan Sleevi wrote on blink-dev that blink no longer uses OSX keychain to store passwords or certificates

<Jonathankingston> I was working on a chrome extension to mock the API nothing to show yet

dveditz: tanvi has been looking at this with moz password manager folks

<mkwst> bblfish: Chrome doesn't use keychain. sorry if my description was confusing.

dwalp: aware and tracking, not much bandwidth to do more given other priorites

<bblfish> it used to. I am pretty sure I was able to switch between Safari and Chrome - ( and was really happy about that )

<deian> (me and some folk at stanford were planning to take a look and evaluate this in the coming month)

<mkwst> bblfish: Apple removed all the advantage of the integration by locking things down to applications delivered via their app store. Due to sandboxing, Chrome won't be in their app store.

<bblfish> ah

<bblfish> sad

COWL status

deian: integrated all talked about changes, thanks for feedback
... think we have an version ready to announce and get feedback from developers + implementers on the APIs

<dveditz> https://w3c.github.io/webappsec/specs/cowl/

deian: a few issues of particular interest, maybe now or maybe after we announce the draft
... need to look at going back into CSP spec for message-src and navigation-src
... want to ask this group about covert channels
... seems a bit nasty to have to go modify leakage through things like height + width
... could tighten it down in future versions
... curious what people think about this?

mkwst: establishing reasonable behavior for overt channels is interesting enough
... but document covert channels and come back to those
... there will probably be a lot of them, doesn't seem to be an explicit goal to stop this
... do the easy covert channels, but don't make that the focus

deian: ok, will add a section on existing covert channels we may lock down later
... also, questions about top-level navigation
... once you unlabel a unique label, you can only talk to the sender of that message
... currently spec allows you to navigate the page away in a top-level context
... this would leak
... worried about unlabeling without checking, and then user has to use address bar to move away
... maybe have a default url that can be navigated to...

mkwst: I do think punting is reasonable, it is expected for a FPWD that there are issues and things will change. moving to list or github issue is probably best way to resolve that

<dveditz> bblfish: I think deian has patches for Firefox, but you'd have to build it yourself. don't think it works as an add-on

deian: so then maybe we should ship this as FPWD

bhill2: +1

deian: re: browser to play with, there is a firefox build but doesn't implement this API
... on cowl.ws

<bblfish> cool

deian: but maybe working with JS polyfill is best first

splitting out specs into their own repositories in GitHub

mkwst: has been suggested by a number of people, pretty much everyone seems interested except Joel
... posted an example of what that might look like

<mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0071.html

bhill2: main benefit here is to get updates to TR pushed automatically

dveditz: what happens to issues?

mkwst: github has an api to port issues
... worst case, keep existing issues where they are and start using new repos for new issues

dveditz: anyone object to announcing decision on the list to be effective in one week?

<nobody objects>

dveditz: one of the chairs to post such an announcement to the list

secure contexts

mkwst: this spec is done, read it and give feedback please, expect to issue a call to move to CR within a week or two

dveditz: next call is Oct 5

<Jonathankingston> +1

<Jonathankingston> Thanks all

<deian> +1, thanks

<bblfish> wave

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/06 23:45:49 $