See also: IRC log
<bhill2> wseltzer, I can't find the minutes for the last meeting...
<bhill2> http://www.w3.org/2015/05/04-webappsec-minutes.html
<bhill2> even http://www.w3.org/2015/05/04-webappsec-irc is missing...
<wseltzer> it looks as though rrsagent was never there
<wseltzer> but I have backlog still
<wseltzer> starting part-way through
<wseltzer> http://www.w3.org/2015/05/04-webappsec-irc.txt is what I have
<wseltzer> bhill2, if someone has better logs, I can generate the full minutes
<bhill2> thanks, I'll ask on the call if anyone has scrollback saved
<wseltzer> and using "trackbot, start teleconf" gets all the bots going at once
<wseltzer> trackbot, start teleconf
<trackbot> Date: 18 May 2015
<gmaone> Is zakim@voip.w3.org broken? I get "500 - Service unavailable", while the echo test (123@voip.w3.org) does work.
<tanvi> bhill2: yes, i can send you my irc logs
<bhill2> if anyone has last meeting's IRC logs, I could use them
<tanvi> sent
drx-goog: What is EPR?
... intended to be complementary to CSP against XSS, but also
address CSRF
<bhill2> scribenick: mkwst
drx-goog: difficult to implement
full locdown CSP
... EPR is another option to address the issues.
<tanvi> a bit hard to hear.
drx-goog: EPR is intended towards
self-contained webapps.
... web page admin interface. consequences of compromise are
catastrophic.
<dveditz> https://w3c.github.io/webappsec/specs/epr/
<ekr> Is it just me that is having trouble hearing?
drx-goog: How EPR works?
... Each site that wants to opt-in serves a header that says "I
support EPR."
... corresponding policy file.
... externally sourced navigation requests to non-entry points
have an action defined by the policy.
... "externally sources" === policy doesn't apply for user
initiated navigation, same-origin navigation, address bar,
bookmarks, etc.
... various actions: blocking outright, redirection, etc.
... applied on a per-policy basis.
<tanvi> so policy works for things like window.open?
drx-goog: That's a quick overview. Questions?
bhill2: I have a few questions.
The spec says that the delivery mechanism is specified in terms
of Manifest.
... Other parts are hinting at things that don't match
up.
... One policy per origin?
... Manifest spec allows multiple manifests per origin on a
path basis.
... Intent to allow more than one manifest per origin?
drx: Not today.
... Format would be the same as manifest spec.
... Policy file would be separate.
... No fundamental objections to combining them.
... Multiple policy files per origin? I hadn't accounted for
that in the spec. Wasn't intended.
bhill2: Implies that the manifest might come from a different origin.
[crosstalk]
bhill2: Need to define the algorithm clearly.
dveditz: Manifest specified in a
<link> tag in a document.
... Might be in a document without such a tag, not intended to
be part of the app?
... Suggest .well-known instead.
... Multiple policies for the same origin isn't workable; in an
origin, don't know where you're going.
drx: Agree. Today, would set one
policy file in a well-defined location, could make it
flexible.
... using the `Link:` HTTP response header field could solve
the <link> tag problem.
... Not in the spec, but if interest, we could add it.
... Hardcoded is simplest.
dveditz: Would it be better to use a max-age like HSTS/HPKP in case sites lock themselves into a bad policy?
drx: That was the original idea,
now we're just using the default cache header expiration.
... do recognize that problem. Could certainly be the case
however one specifies the expiration, if a broken policy is
served, etc.
dveditz: Cache might expire things faster than you'd like.
drx: I see. One thing mentioned in the spec is the idea that when a policy takes effect you can decide to issue an async request for the policy file to refresh.
<terri> Caching might also be a bit of an issue if we start talking per-path policy. That could result in a bunch of extra round trips
drx: UAs could implement sane
behavior here.
... Perhaps "the first time violation happens in a day, pull
down a new copy".
... More questions?
bhill2: If I've seen the header,
and downloaded the manifest, covers a resource, and then load
that resource that doesn't contain the EPR header, do I apply
the policy?
... Given a.html and b.html: a.html has an EPR header. I
download the manifest, declares that b.html should be
covered.
... I load b.html, not served with an EPR header. Do I apply
the policy?
drx: it would apply the policy.
interesting point, though.
... lack of EPR header doesn't mean you've opted out of
EPR.
bhill2: tricky to say that you
can be opted in without sending the header.
... If one resource can set a header which impacts policy
elsewhere on the origin, we should be cautious about specifying
the behavior.
drx: Not defined today, we should be careful.
bhill2: If I see manifest data, but no EPR header, should I apply it?
drx: No. No header, no EPR.
... Should specify that.
bhill2: Have you thought about
interactions with CORS?
... What is the order of operations/rules for omit-credentials
in EPR vs credentials in CORS?
drx: Action that allows to omit credentials seemed like a nice-to-have; need to define more clearly to specify interaction.
bhill2: Rename to
"omit-credentils"? Better not to mint new concepts, but to
reuse names.
... Whatever fetch says.
... "credentials=omit" => "omit-credentials"?
dveditz: Do the redirect URL/reporting URL need to be same-origin?
drx: Should be explicit; should lock to same-origin.
<bhill2> we don't lock CSP reports to same-origin...
dveditz: In the IDL, misusing
`sequence`. Only for parameters/return values.
... check with Anne.
... Concerned about regex bit here. Wild west. Flavours,
etc.
... Even if we reference JS, it's changed over time.
... Wondering if there's a better way.
... Simpler globbing format, perhaps?
drx: Probably fine. Needs to be
finer-grained than a string comparison.
... Implementing this via the prototype, we needed to specify
something under a path, for instance.
dveditz: Unix utils;
basic/extended regex.
... Would be nice to have a basic version.
... Minor concern, just not well specified yet.
drx: Want to point to something
that exists. Don't want to define something new.
... Just need to be a bit more flexible than string
comparison.
dveditz: And not just a simple prefix match?
dwalp: Check the apparmour(?) format. It does something similar.
<francois> apparmor, actually
https://wiki.ubuntu.com/AppArmor ?
ccowan: Opensource linux security
product.
... Developers on it are at Ubuntu.
<terri> I'd be surprised if there isn't some well-defined implementation of regex we could use somewhere
dveditz: Navigational seems wordy. Perhaps "document" or "page"?
<dlongley> http://www.ecma-international.org/ecma-262/5.1/#sec-15.10
drx: ?
dveditz: Need to type "navigational" pretty often. "document" seems simpler.
drx: "document" would work too, I suppose.
dveditz: The algorithm runs
through the rules in order.
... Match one, good to go, don't check anything else.
drx: Yes. Match one, it's an
entry point, good to go.
... Then do the default action.
... Unless the UA decides it's exempt, like a bookmark action
or etc.
dveditz: Needing to type `allow`
is tedious.
... When it's the default on the web, perhaps something else
should be the default.
... Don't want a complex policy. Downloading, parsing, etc.
<bhill2> dveditz: time check?
dveditz: allow-data false means that if the request has data it doesn't match, right?
drx: yes. doesn't force the data to be stripped.
dveditz: One more question: has to be a secure request? Only for HTTPS?
drx: Seems reasonable. Don't need to enable for non-secure sites.
dveditz: Something in the middle of the spec. Perhaps should be clear from the beginning that ti's true, or the bit in the middle is confusing.
drx: will pin it down.
dveditz: Section 4.3, step 1.
bhill2: further questions? GitHub
issues!
... last words, David?
drx: GitHub issues! Send me email! Chat! Whatever!
<bhill2> scribenick bhill2
https://w3c.github.io/webappsec/specs/credentialmanagement/
<bhill2> mkwst: a number of issues open, many editorial, some more fundamental
<bhill2> ... summarize first, then turn over to Manu and David for their concerns about extensibility
<bhill2> ... summary of current API
<tanvi> if you are not talking, can you mute
<israelh> +1
https://github.com/w3c/webappsec/pull/292
bhill2: The part where it says
it's applicable to the top-level browsing context.
... Concern is that the user doesn't understand anything other
than the address bar.
... Set ofuse cases for collecting credentials in frames.
<dveditz> eeeeeevil
bhill2: Prevalent in payment,
etc.
... Common use case.
<terri> side note: there's scientific evidence that the user doesn't really understand the address bar, even
<bhill2> mkwst: I agree with you on those use cases, not stunningly common but certainly used on the web
<bhill2> ... would prefer to specify something with a more narrow scope and determine how to open it up more safely
<bhill2> ... address bar is only user context, has been core to model that the spec is putting together
<bhill2> ... hard to understand how to make it safe for iframe to request credentials
<dveditz> terri: too true. but if they understand anything it might be the URL bar and the lock. maybe
<bhill2> ... assume PayPal were to do this ... they don't do this now and there is a reason
bhill2: Paypal does have an iframe flow.
<terri> dveditz: the eye-tracking studies on EV certs found that they don't even look at the url bar and lock, even when they claim to, sadly. But I agree that it's still the best bet, it's just kind of a crappy best bet.
bhill2: in response to other payment providers.
<bhill2> ... if browser is going to ask the user and the origin is different from address bar
dev: Should this spec get into that?
<dveditz> yeah. anecdotally I think my family only checks the URL bar if something on the page "looks off"
dev: Invariant across everything
we do.
... We can mention the invariant, but shouldn't specify
that.
... Verified by Visa, etc.
<bhill2> mkwst: if you can't trust it, we can't expect anyone to trust it
<bhill2> ... user mediation is critical
<bhill2> .. credential info is sensitive, esp from UI perspective
<bhill2> ... means persistent access to a user's data at an origin
<bhill2> ... going to be confused and not able to make a good trust decision when multiple origins in play
<manu> +1 to mkwst
<bhill2> dev: this is a problem with http basic auth, etc. quick redirects can bypass
<bhill2> ... much harder and broader problem, we won't solve it in this spec
<bhill2> mkwst: set the bare minimum bar
<bhill2> ... possible to do more, not les
<bhill2> dev: worry about doing the bare minimum, it's like doing RC4
<bhill2> ... would rather acknowledge the problem
<bhill2> mkwst: how we decrease security by limiting context
bhill2: I don't like iframe
flows, but this UI could increase my trust.
... Chooser must indicate the origin.
... That's trusted interaction, perhaps I'll have better
understanding of what's going on.
... Origin-locked delivery to the iframe is a reasonable
increase in security.
... Iframe can only ask on its own behalf.
... Protecting the credential itself, this ight be safer,
assuming the iframe flows exist.
<bhill2> assuming these flows exist, this is a safer way to handle than excluding htem
<bhill2> israel: can we scope to high level with understanding there is more work to do later, easier to expand.
israelh: Why couldn't we start with the top-level, and perhaps extend to nested contexts later?
<manu> Potential Web Payments IG and Credentials CG concerns here: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0101.html
<bhill2> manu: couple of groups interested in credentials work
<bhill2> ... web payments IG, credentials CG working on slightly different type of credentials
<bhill2> ... would like to harmonize these new types of credentials with the api being created here
<bhill2> ... types of credentials these groups talking about are broader: driver's addresses, proofs of age, address, etc.
<bhill2> ... same origin vs. cross-origin credentials
<bhill2> ... is the current API shape extensible enough to handle cross-origin credentials?
<bhill2> vijay: seems there is a more expansive definition of credential, why do feel they must be accomplished by extending this API rather than creating a bigger framework this API can plug into?
<bhill2> manu: our thinking is very similar, so close we feel we would be duplicating work, vs. just making small modifications on extensibility
<bhill2> vijay: seems like you think it should be possible to put a payment instrument into this API
<bhill2> manu: new credentials are associated with an identifier, not a "has a" identifier relationship
<bhill2> ... we are committed to get something to Mike on an extensibility mechanism
<terri> I have a question about usability work in this space, but I'll try to bring it to the mailing list.
<bhill2> .. we have some questions, specifically about what browsers think about this work, data structures, etc.
<terri> +1 to bringing this to PING
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/dwalp/ccowan/ Succeeded: s/conrext/context/ Found ScribeNick: mkwst Inferring Scribes: mkwst Default Present: mkwst, manu, dlongley, +1.503.712.aaaa, terri, +1.206.876.aabb, +1.206.348.aacc, +1.418.907.aadd, [Microsoft], francois, +1.310.597.aaee, dveditz, ekr, bhill2, tanvi, +1.617.324.aaff, keiji, vgb, +1.415.857.aagg Present: mkwst manu dlongley +1.503.712.aaaa terri +1.206.876.aabb +1.206.348.aacc +1.418.907.aadd [Microsoft] francois +1.310.597.aaee dveditz ekr bhill2 tanvi +1.617.324.aaff keiji vgb +1.415.857.aagg Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0073.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 18 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/18-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]