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
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
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
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
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'
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
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
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
;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
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
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
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
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
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
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'
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
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://
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
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
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
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
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
`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
23 matches
Mail list logo