See also: IRC log
<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
<dveditz> http://www.w3.org/2015/08/24-webappsec-minutes.html
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
<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
<mkwst> that is, something like https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html
<mkwst> seems effective enough. *shrug*
https://w3c.github.io/webappsec/specs/credentialmanagement/
https://github.com/w3c/webappsec/labels/credential
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
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
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
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