Re: Reminder regarding normative references

On Wed, Oct 7, 2015 at 9:30 AM, Steve Faulkner wrote: > hi mike, i think you will find your example is in the W3C HTML 5.1: > > http://www.w3.org/TR/html51/webappapis.html#creation-url > > not saying there aren't other examples that would be concrete. > I am pleasantly surprised! I assume this

Re: Reminder regarding normative references

On Wed, Oct 7, 2015 at 12:44 AM, Wendy Seltzer wrote: > A reminder that has come up in some recent transition calls: When moving > a spec to Candidate Recommendation, we look to see that the normative > references are to documents of equivalent stability[1] -- ideally, also > CR, if they're W3C d

CfC: Transition "Secure Contexts" to CR; deadline October 1st.

st of the referenced terms are available for review at https://w3c.github.io/webappsec/specs/powerfulfeatures/#index-defined-elsewhere . The deadline for this CfC is one week from today, October 1st. As always, explicit (positive!) feedback to public-webapp...@w3.org is appreciated! -- Mike We

Re: Normative references to Workers.

gs that are missing from W3C's HTML, but are present in WHATWG's)). What I hear so far on this thread is that we should simply reference the WHATWG version of those specs, which seems like a reasonable thing to do. -mike -- Mike West , @mikewest Google Germany GmbH, Dienerstrasse 12, 8

Normative references to Workers.

w3.org/TR/workers/ [4]: https://w3c.github.io/workers/ -- Mike West , @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'

Secure Contexts: It's worth taking another look.

bappsec#406 <https://github.com/w3c/webappsec/issues/406> is probably the most interesting of these. I'd appreciate feedback on the document, either on public-webapp...@w3.org, or via GitHub at https://github.com/w3c/webappsec/issues/new?title=SECURE:%20 -- Mike West , @mikewest Google

Re: Permissions API vs local APIs

e with Jonas. Extending the permission API to give developers a single place to check with a single consistent style seems like the right way to go. -- Mike West , @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesel

Re: Privileged context features and JavaScript

I'd be fine with this, if it's what folks end up preferring. That said, throwing/rejecting gives us the opportunity to explain to a developer _why_ her favorite API isn't available. It's not clear how we'd help them understand what's going on if we just remove the API entirely. Consider Geolocati

Re: CORS performance

;t force your host into exposing resources you otherwise wouldn't. Brad's .well-known suggestion is interesting. I'm worried about the latency impacts, but it's probably worth exploring what it would take to add this kind of thing to the Manifest spec (or some same-origin-limi

Re: Clarification of CSP sandbox and workers

any of the other flags would be useful, though. Ian, WDYT? -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch

Re: RfC: WebAppSec's Last Call Working Draft of Mixed Content; deadline December 11

ecific section(s) you want WebApps to review, please > let us know. > http://www.w3.org/TR/2014/WD-mixed-content-20141113/#powerful-features is certainly very relevant to various specs WebApps is considering. Review and comments there would be helpful. -- Mike West Google+: https://mkw.st/+, Twit

[Credential Management]: Tiny prototype to play around with.

to talk about at TPAC. [1]: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0141.html [2]: http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0009.html -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Die

Re: Looking for a home for a proposed Credential Management API.

e. :) Another option would be to create a new a new CG (although I suppose there > could be some confusion with Manu's Credentials CG < > http://www.w3.org/community/credentials/>). I guess that's an option. -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cel

Looking for a home for a proposed Credential Management API.

I'd prefer to avoid them in the long run (though they might be the right place for short-term incubation). Brad suggested that an authentication WG might be spun up out of the conversations in the recent WebCrypto workshop. Are there concrete plans for such a group? Thanks! -mike -- Mike W

Re: Proposal for a credential management API.

2, etc.) > I agree with this division. However, I'm hopeful that the strawman I've proposed is flexible enough to support a number of potential forms of credentials. It currently defines "local" and "federated" credentials broadly, and vaguely. In spirit, at least, it'

Re: Proposal for a credential management API.

r sign-up, which can be significantly more complex than IDP's general "pick an IDP, then grant access" flows. I'd like to support both, for what it's worth. -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Di

Re: Proposal for a credential management API.

t. > All of these goals are likely not required. But I definitely want to > make sure that whatever we build is attractive enough to users, > webdevelopers and federated-login-providers that it actually gets > used. > I agree that this is paramount. -- Mike West Google+: https://

Re: Proposal for User Agent Augmented Authorization

instance, remove the need for parameters to `authenticate` by defining suitable attributes in an IDP manifest, as sketched out at http://projects.mikewest.org/credentialmanagement/spec/#identity-provider-manifest . -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 25

Re: Write-only form fields (was Re: Proposal for a credential management API.)

Thanks Jacob! On Fri, Aug 1, 2014 at 6:48 PM, Jacob S Hoffman-Andrews wrote: > I think the CSP directive is unnecessary and makes things more fragile. The > 'protect this credential from XSS' attribute should be a property of a > stored credential, not a web site. If the site has the correct CSP

Re: Write-only form fields (was Re: Proposal for a credential management API.)

tials, and the UA would return a client nonce and a LocalCredential whose password value was `hash(password + server nonce + client nonce)`. I think that's worth exploring, but it's tough to do well without requiring the site to hold passwords in plaintext. Is that the kind of use

Write-only form fields (was Re: Proposal for a credential management API.)

the API. > This would probably not interact well with use of the WebCrypto API to > encrypt the contents of input fields (passwords, credit card numbers, > etc.) before submission. I'm pretty happy to break that use case, given that the credential API I've proposed is locked to

Proposal for a credential management API.

ue from a process perspective, but this is almost certainly the right group of people to evaluate the proposal. Thanks in advance for your feedback, suggestions, and time. :) -mike -- Mike West Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstr

Re: CSP 1.1 DOM design

`document.SecurityPolicy.allowsFontFrom('xxx')` is an accessor for the effective permissions granted via the 'font-src' directive). Would you prefer more direct access to the policy? We'd shied away from that on the assumption that this interface required less knowledge of