Fwd: Re: [webappsec] Topics for Rechartering

Note connection between OpenSocial and WebAppSec's rechartering, as well
as likely the Social API deliverable of the WG.

The WebAppSec rechartering discussion starts at 3:00 PM and goes on
tomorrow morning.

   cheers,
       harry

-------- Forwarded Message --------
Subject: Re: [webappsec] Topics for Rechartering
Resent-Date: Mon, 27 Oct 2014 18:19:20 +0000
Resent-From: public-webappsec@w3.org
Date: Mon, 27 Oct 2014 19:19:11 +0100
From: Harry Halpin <hhalpin@w3.org>
To: Brad Hill <hillbrad@gmail.com>, public-webappsec@w3.org
<public-webappsec@w3.org>, James Snell <jasnell@gmail.com>

[Adding James Snell from IBM]

On 10/19/2014 10:12 PM, Brad Hill wrote:
> Reminder: Our group is operating under a short-term charter extension
> and we need to work on a new charter at TPAC.  Below are some ideas on
> what the group might work on in the next year or two.
> 
> I've tried to keep running notes for the last few months as our
> recharter approached, and this is what I have.  Apologies if I missed
> your contribution - I'd love for you to reply and add it here if I
> did.
> 
> I'll put together a poll somewhere shortly where folks can vote on
> what they're interested in, but feel free to use the list in the
> meantime to encourage or disapprove, or most importantly, to volunteer
> if you'd like to be an editor, implementer or test coordinator for one
> of these ideas.
> 
> -Brad
> ---------------------
> 
> 1) Credential management API, write-only DOM elements and the draft
> specifications Mike West has posted here for comment and review.
> 
> 2) Revive a formal spec for the Content-type: No-Sniff feature and
> publish it here. (previous efforts at IETF failed, but this is about
> browser behavior and I think it is reasonable for this group to work
> on)
> 
> 3) Specify better how Service Workers and CSP interact
> 
> 4) Joel Weinberger's Sub-origins proposal, previously discussed on this list.
> 
> 5) Return additional cookie data to servers:  Servers might want to
> know if a cookie with httpOnly was set by JS or if a secure cookie was
> set insecurely
> 
> 6) Block loading of insecure content in child browsing contexts - so
> if you load an ad in an iframe and it tries to load insecure content,
> it doesn't bust your green lock
> 
> 7) Web Components security model?
> 
> 8) Something resembling a Cross-Origin+Sandboxed Worker.  An
> alternative to <script src="remotehost.com"> that lives in an isolated
> world with no DOM but has structured APIs to interact with the
> containing page.  Web Components were motivated by the overhead of
> loading into an iframe.  It's not sustainable to have 20 or 30 nested
> browsing contexts, especially in a multi-process model.  But an
> isolated JS runtime is much lighter-weight (no DOM, no renderer).  Can
> we support the models people want with script includes in a more
> secure fashion?  Maybe we can support legacy JSONP in a secure way
> with this, too.
> 
> 9) Even richer Cross-Origin Worker APIs, e.g. allowing persistent
> Shared and Service workers to communicate x-origin.

Note that I think the "Social API" deliverable of the Social WG may have
a connection to 7) and possibly 9). Currently, OpenSocial (one of the
input docs to the Social API) is built with Gadgets, and they want to
remove Gadgets support in the future and replace it with Web Components.

I believe they'd like to have some cross-origin communication between
iframes that is not mediated by the page the iframe is embedded in I
believe, but I must admit I am not quite familiar with the details.
James from OpenSocial Foundation (IBM) has been cc'ed.

> 
> 10) Better authentication APIs?  WebCrypto Next Steps workshop results
> - does any of what people wanted belong in this group?

On an aside, this will be discussed Thursday as well in the afternoon at
the WebCrypto F2F.

>

Received on Monday, 27 October 2014 18:43:06 UTC