Re: Reminder regarding normative references

[Mike West]

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 means that I ought to be reference HTML 5.1 and not 5 in
whatever snapshots WebAppSec produces?

-mike

Re: Reminder regarding normative references

[Mike West]

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 documents. So if you're moving a document forward,
> it's a good idea to look periodically at the references and ping the
> other working groups where those are being developed to make sure that
> dependencies are moving at the pace we need. (This also helps to satisfy
> the "wide review" requirements.)
>

A corollary to this is that "stability" should be balanced against
"accuracy". That is, http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
is pretty stable, but we ought not reference it today, as it doesn't
represent what browsers are doing.

What do you/the director/his delegates suggest that we do if we'd like to
reference concepts that aren't yet present in W3C specifications?

As a concrete example, I'm going to send a transition request for Secure
Contexts shortly. It uses the "creation URL" concept which was recently
added to WHATWG's HTML (
https://html.spec.whatwg.org/multipage/webappapis.html#creation-url). That
concept is not present in the W3C's HTML (nor is it clear to me how to get
it added :) ). How do you suggest that we proceed?

+public-webapps, as I believe specs like Service Worker have similar
problems (and, in this case, the exact same problem).

-mike

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

[Mike West]

BCC: www-tag@, public-webapps@, public-privacy@, public-geolocation@,
public-review-announce@.

Hello, WebAppSec! Two weeks ago, I noted that Secure Contexts was pretty
much done, and ready to review (
https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0068.html).
I've made some changes to the doc based on feedback during that period
(thanks mostly to Anne), and I think we're close enough to call it done and
see if anyone points out crazy things I've missed. :)

This is a call for consensus to transition to Candidate Recommendation with
the document at:

https://w3c.github.io/webappsec/specs/powerfulfeatures/published/2015-10-CR.html

The core of the specification is already implemented in Chrome and Firefox,
and is used in a number of specifications to gate certain features (like
Service Workers) to contexts which offer guarantees about their usage. I
expect those implementations can align with the specification fairly
quickly, and I don't believe anything in the document needs to be marked as
"at risk".

As discussed on public-webapps@, this document references WHATWG documents
in several places where the W3C version is out of date. A list 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 West <mk...@google.com>, @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'm legally required to add this exciting detail to emails. Bleh.)

Normative references to Workers.

[Mike West]

The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML
spec for the
"set up a worker environment settings object" algorithm[2], as the Web
Workers Candidate Recommendation from May 2012[3] substantially predates
the entire concept of a "settings object", and because the WHATWG is the
group where work on Workers seems to be being done.

This referential choice was flagged during a discussion of transitioning
the Upgrade spec to CR, where it was noted that the Web Workers editor's
draft from May 2014 does contain the referenced concept[4].

It seems appropriate, then, to bring the question to this group: does
WebApps intend to update the Workers draft in TR? If so, is there a path
forward to aligning the Workers document with the work that's happened over
the last year and a half in WHATWG? Alternatively, does WebApps intend to
drop work on Workers in favor of the WHATWG's document?

It would be helpful if we could get some clarity here. :)

Thanks!

[1]: https://w3c.github.io/webappsec/specs/upgrade/
[2]:
https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
[3]: http://www.w3.org/TR/workers/
[4]: https://w3c.github.io/workers/

--
Mike West <mk...@google.com>, @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'm legally required to add this exciting detail to emails. Bleh.)

Secure Contexts: It's worth taking another look.

[Mike West]

BCC: www-tag@, public-webapps@, public-privacy@, public-geolocation@ in the
hopes of spurring "wide" review.

I've done a bit of polishing on
https://w3c.github.io/webappsec/specs/powerfulfeatures/ over the last few
days, and I think it's worth folks' time to take another look at the
document. In particular, I've addressed some of Boris' concerns from way
back in June/July (sorry it took so long!), and clarified the algorithms
with what I hope are helpful examples.

Outstanding issues are noted at
https://github.com/w3c/webappsec/labels/SECURE. w3c/webappsec#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 <mk...@google.com>, @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'm legally required to add this exciting detail to emails. Bleh.)

Re: Permissions API vs local APIs

[Mike West]

On Tue, May 5, 2015 at 2:54 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, May 4, 2015 at 10:42 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  Over in
 https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0006.html
  Jonas pointed out that having two APIs for doing the same thing is
  nuts. We should probably decide whether we go ahead with the
  Permissions API or keep doing permission checks on a per-API basis.

 I personally think having a single API, rather than half a dozen
 navigator.*.hasPermission() APIs is better. If for no other reason
 than that's it's likely going to be significantly easier to keep a
 single API consistent, than the half-dozen different ones.

 I'll also note that the reception on twitter from developers for the
 permission API seemed quite positive.


I agree 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 mk...@google.com, @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'm legally required to add this exciting detail to emails. Bleh.)

Re: Privileged context features and JavaScript

[Mike West]

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 Geolocation, for instance: users can disable the API entirely in
Chrome (and, I assume, other browsers). Should we remove the API in these
cases as well?

Either way, expressing the constraint via IDL seems totally reasonable.

-mike
On Apr 17, 2015 07:19, Anne van Kesteren ann...@annevk.nl wrote:

 Soon there will be a number of features that are restricted to
 privileged contexts. Most prominent one being service workers.

 Within user agents the prevailing pattern is that privileged APIs are
 not available in unprivileged contexts. However, both Firefox and
 Chrome currently expose the service worker API everywhere, it just
 happens to reject.

 Should we change this and simply not expose the API in unprivileged
 contexts? E.g. through IDL syntax? That way we don't have to carefully
 secure all access points.


 --
 https://annevankesteren.nl/

Re: CORS performance

[Mike West]

On Tue, Feb 17, 2015 at 8:43 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:

 * Anne van Kesteren wrote:
 On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net
 wrote:
  Individual resources should not be able to declare policy for the whole
  server, ...
 
 With HSTS we gave up on that.

 Well, HSTS essentially removes communication options, while the intent
 of CORS is to add communication options. I don't think you can compare
 them like that. HSTS is more like a redirect and misconfiguration may
 result in denial of service, while CORS misconfiguration can have more
 far-reaching consequences like exposing user information.


I share this concern. Note that CSP pinning as we're discussing it is also
purely negative in nature. It can block you from loading resources you'd
otherwise have access to, but can'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-limited version
thereof).

-mike

--
Mike West mk...@google.com, @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'm legally required to add this exciting detail to emails. Bleh.)

Re: Clarification of CSP sandbox and workers

[Mike West]

The CSP spec should just delegate to HTML here. If/when HTML defines
sandboxing with regard to Workers, CSP will just start using those hooks.

I'd agree, for example, that it does appear that sandboxing a worker into a
unique origin could be interesting. It's not clear to me whether any of the
other flags would be useful, though.

Ian, WDYT?

-mike

--
Mike West mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Nov 12, 2014 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu
 wrote:
  I am implementing CSP for Workers in Firefox, but like to get a
  clarification on workers and the sandbox flag. Currently, a Worker can
  inherit or be accompanied by a CSP header. As written, the implications
  of the sandbox directive on the Worker context is not clear.
 
  [Following up on https://github.com/w3c/webappsec/issues/69]
 
  Arguably most of the sandbox flags don't make sense for Workers, but the
  empty directive (i.e., just sandbox) and sandbox allow-same-origin can
  have reasonable semantics.  So, if a Worker inherits the CSP from the
  owner document (or parent worker in later specs) or is accompanied by a
  CSP header which has the 'sandbox' directive, should the worker script's
  origin be set to a unique origin?  Or should we just ignore (and
  appropriately warn about) the sandbox flag for Workers and address the
  need for sandboxed Workers separately?

 This would affect what a worker can fetch, what storage it has access
 to, and which permissions it has (e.g. can it display a notification).
 Might be an interesting way to run untrusted code.

 But if we are going to do something like this Ian would have to define
 how the sandbox directives affect a worker environment.


 --
 https://annevankesteren.nl/

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

[Mike West]

-Brad's PayPal address (which probably bounces now), +Brad's other address.

Thanks for widening the audience!

On Tue, Nov 11, 2014 at 3:39 AM, Arthur Barstow art.bars...@gmail.com
wrote:

 Brad, Mike - other than the Modifications to WebSockets section, if
 there are any other specific 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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

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

[Mike West]

BCCing public-webapps@, as this proposal started there[1]. It looks like it
might be reasonable to charter the spec work as part of the WebAppSec
WG[2], however, so I'm moving the conversation here for the time being.

Way back in August, I proposed a credential management API. After some
generally positive conversation with folks at Mozilla and other vendors, I
started poking at a prototype in Chrome to help us evaluate whether the API
made any sense. As of some time earlier this week, there's enough in Canary
to start looking at.

If you visit https://credential-manager-api-test.appspot.com/ in Canary
with the '--enable-credential-manager-api' flag set, you can save
credentials via `navigator.credentials.notifySignedIn()` and retrieve them
via `navigator.credentials.request()`. It only supports local
credentials, and doesn't do any of the UI song and dance that's still very
much TBD, but it's a nice proof of concept.

Note: Don't do this on any profile with data you care about. The current
implementation just blindly returns the first credential that matches the
origin on which the API is called, without user mediation. That's probably
not something you want to expose to the web in its current state. :)

I'd invite you to take a look at the strawman proposal (
https://mikewest.github.io/credentialmanagement/spec/), and help me decide
whether the API makes any sense. If nothing else, it'll give us something
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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

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

[Mike West]

On Fri, Sep 26, 2014 at 10:39 AM, Arthur Barstow art.bars...@gmail.com
wrote:

 While some of these longer term options Harry mentioned are sorted out,
 are you looking for a more immediate place to discuss your proposal?


I'm looking for a path that leads to cross-browser agreement and
publication. *shrug* There's no particular rush, but since it sounds like
there's at least partial agreement on the general shape and direction of
the API, it would be nice to get a draft published in the relatively near
future in the hopes of raising visibility and focusing discussion (as well
as the general IPR excitement that published drafts tend to cover).


 If so, although I am currently mostly indifferent as to which existing
 list to use, I don't object to using p-webapps. That said, perhaps the
 Security IG list would be more appropriate (since I think it has an
 implicit `coordination` function). Virginie, Adam - any feedback on the IG
 being a temporary home for Mike's proposal?


Whichever group ends up being the right one for eventual publication,
public-webapps@ seems like a good place for discussion; the right folks are
probably already here. :)

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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Looking for a home for a proposed Credential Management API.

[Mike West]

(I'd originally sent this just to the folks on to: and cc:. Art reminded me
that public is better, so I'm resending to public-webapps@, and BCCing
public-webappsec@ for visibility).

Hello, chairs of the WebApps, WebAppSec, and WebCrypto WGs!

On Friday, I had an encouraging discussion with Jonas Sicking (CC'd) about
the Credential Management API proposed a month or so ago on WebApps (
http://mikewest.github.io/credentialmanagement/spec/).  Chrome has started
experimenting with an implementation, and though we're nowhere near even
considering shipping it, I'd like to make sure that our implementation
doesn't get too far out ahead of the spec process.

I think it's fair to say that Mozilla is interested in continuing the
discussion around the short-term and long-term goals of such an API in an
appropriate venue. I'd like your collective opinion about what that venue
might be. WebApps seems like the right place just in terms of having the
right people involved. It would require a recharter, however, and it's not
clear to me that that would be a worthwhile use of folks' time.

Both WebCrypto and WebAppSec are in the process of rechartering, which
resolves that potential issue, but neither really seems to be appropriate,
as they're concerned with aspects other than credentials and authentication.

There's a credentials community group that has nothing to do with the
proposal, and given the weak IPR protections of a CG, 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 West mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: Proposal for a credential management API.

[Mike West]

On Mon, Aug 18, 2014 at 7:07 PM, Hill, Brad bh...@paypal.com wrote:

 I think the broader goals Jonas has articulated probably belong in their
 own group, perhaps chartered along with some of what comes out of the
 upcoming Web Crypto Next Steps workshop.


I'm certainly interested in seeing what comes out of that workshop, and I'm
equally curious about FIDO in general.

Ideally, then, without being too optimistic, I'd like to see passwords
 replaced entirely by better technology rather than continuing to kludge
 upon them.  They're still a fundamentally broken technology in many
 important respects even with better management tools.


What's a timeframe in which you might reasonably expect that to happen? I
suspect it's not months or next year.

We're having a hard enough time getting folks onto SSL, which is a much
more basic requirement. I, personally, don't honestly expect passwords to
be widely replaced in the near future, especially given how central they
are to identity on today's web. Given the investment in password-based
authentication systems, and the lethargic pace at which things like this
tend to move, I think the use cases spelled out in my proposal remain quite
relevant to today's web, and tomorrow's web. Hopefully they're less
relevant to web 3.0, but that's a ways off. :)


 Also, we should be careful in decomposing our targets here.  Federation is
 a different layer than replacing passwords or password management.  There
 are already a number of standards in that area which could be given
 native support in a browser without having to re-invent the wheel.  (e.g.
 SAML2, WS-Federation, OpenID Connect / OAuth2, 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's following Mozilla's
position paper's call for a box implementations can go in, and is
extensible by design.

--
Mike West mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: Proposal for a credential management API.

[Mike West]

On Tue, Aug 12, 2014 at 10:19 PM, Jonas Sicking jo...@sicking.cc wrote:

  One- or two-click sign _up_, on the other hand, will likely be more
  difficult given the complexities of authorization (scopes, etc).

 I'm not sure what you count as sign-up? Today, if I visit a new
 website that I've never visited before, I can log in to that website
 in two clicks using identity providers as facebook/twitter/google. I
 don't think anything more than that is going get the support we need.


You're right. I was thinking about username/password flows for 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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: Proposal for a credential management API.

[Mike West]

Hi Jonas, thanks for this feedback!

On Tue, Aug 12, 2014 at 11:51 AM, Jonas Sicking jo...@sicking.cc wrote:

 I'm very interested in improving the login experience on websites. In
 particular I'd like to create a better flow when federated logins are
 used, with at least the following goals:


I think these are laudable goals. Taken together, I worry that we'll be
trying to boil the ocean, but I certainly agree with the general sentiment
and direction.


 * Enable the user to manage their accounts in browser chrome rather
 than have to go to specific websites to log out.


This will almost certainly require cooperation from both the RP and IDP
side of the equation. Given that, I worry that the browser will be
promising things that it can't actually guarantee if it pops up a Sign
out button.


 * Enable a login flow which is less jarring UX-wise than today's
 redirects.
 * Don't increase the number of clicks needed to log in. Today two
 clicks are usually enough, we shouldn't be worse than that since then
 websites won't adopt it and user's won't like it.


One-click sign-in (with a zero-click, Keep me logged in option) is a very
reasonable goal, and one that I think is achievable.

One- or two-click sign _up_, on the other hand, will likely be more
difficult given the complexities of authorization (scopes, etc).


 * Make it easier for websites to support multiple federated login
 providers by ensuring that they all use a common API. I.e. adding
 support for more login providers shouldn't need to require running
 code specific to that provider.


I worry about http://xkcd.com/927/. To pick on an easy target, there are
already several dialects of OAuth2 that IDPs provide SDKs to speak.
Moreover, it's not clear that any IDP actually considers this a bug.

Easy migration between IDPs is absolutely a benefit to the user, as is easy
integration with new IDPs for authors. It's something that we should
attempt to provide, but it is a large undertaking.


 * Enable the UA to track which login providers that the user has
 accounts with so that the UA can render UI which only displays
 providers that are relevant to the user.


The strawman I posted does this by using the password manager that's
already in browsers. If you've saved Funky Federation credentials, then the
UA can be reasonably sure that it should present you with that Funky option
when a website claims to support it. This seems like the simplest possible
way of getting the information, without requiring IDP support.


 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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: Proposal for User Agent Augmented Authorization

[Mike West]

Hey Sam, this looks interesting indeed!

It's not clear to me how this proposal interacts with the credential
management proposal I sent out last week. Does the following more or less
describe the integration you're thinking about, or have I completely
misunderstood the proposal?

```
navigator.credentials.request({ federations: ['https://idp1.net/', '
https://idp2.net' ] }).then(function(c) {
  // If the user picks a supported IDP, authenticate:
  if (c  c instanceof FederatedCredential) {
navigator.auth.authenticate({
  authURL: ...,
  returnURL: ...
});
  }
});
```

I was hoping that we could find a way to hide some of that magic behind the
initial call to `.request()`. If the user picks a stored credential from
IDP #1, it seems like we'd be able to come up with a system that returned
whatever IDP-specific tokens directly as part of resolving the promise.
That is, rather than popping up one picker, then resolving the promise,
returning control to the website, and then popping up some additional UI,
we could handle the IDP-side authentication process in the browser before
returning a credential.

We could, for 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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Wed, Aug 6, 2014 at 5:25 AM, Sam Penrose spenr...@mozilla.com wrote:

 We think that users could be well served by providing simple ways for user
 agents and authentication protocols (specifically Oauth, we hope others) to
 support each other:

   https://github.com/SamPenrose/ua-augmented-auth

 Web apps suffer particularly due to non-http URIs and cookie segregation.
 We would like feedback on the specific APIs suggested, as well as the
 overall problem framing. Thank you for your consideration.

 -- Sam

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

[Mike West]

Forking this out into a separate thread, as I think it's a great idea, but
tangential to the original proposal. :)

TL;DR: I put together a strawman based on these suggestions which defines a
'writeonly' attribute on HTMLInputElement:
http://projects.mikewest.org/credentialmanagement/writeonly/, WDYT?

On Thu, Jul 31, 2014 at 6:37 PM, Brian Smith br...@briansmith.org wrote:
 And/or the password form could be annotated with an attribute that
 indicates for which domain an XHR should be allowed to submit the
 password to. And/or, you could have a submit-password CSP directive to
 indicate which domains passwords are allowed to be submitted to.

We already have 'form-action', I think that serves the purpose suitably
well:
https://w3c.github.io/webappsec/specs/content-security-policy/#directive-form-action

 particular, if we are worried about XSS stealing passwords then we
 have to consider the possibility that XSS has inserted a form without
 any httponly attributes being used, right?

Correct. I think we'd also want a new CSP directive which toggles
write-only status for all password fields on a given page: how about
http://projects.mikewest.org/credentialmanagement/writeonly/#credentials-directive
?

 I was thinking the placeholder would be a base64url-encoded
 cryptographically-random nonce of sufficient length, so that the
 browser can replace the placeholders within arbitrary HTTP requests,
 regardless of (most) use of JS to mangle forms before submitting them,
 and without worrying about replacing the wrong part.

I agree, but I don't think we need to specify this normatively. User agents
will know what they can easily replace and what they can't, if they choose
to go down a nonce route.

 This would work with (C) too, would it not? It may be a good idea to
 add an attribute to XHR to trigger such replacement, so that the
 browser doesn't have to attempt substitution for every HTTP request.

I think we'd be able to get away with relying on magical UA behavior: if
the browser process hands a nonce to a renderer, it can set a flag, and
then look at POSTs generated by the page. As soon as one POST contains the
nonce, clear the flag. My suspicion is that most login pages don't do much
POSTing, so the overhead would be trivial.

I'd prefer that approach, because I don't think we want to expose the
actual mechanics to the web. The website shouldn't need to care about
whether or not the password it's received is the real password or not.

 Based on a quick read of Mike's proposal, this would require Mike's
 proposed API to change to pass around tokens that represent passwords,
 instead of the password values themselves. This would add
 complication, but it would be useful.

This approach adds complication to the UA's implementation, but shouldn't
add complexity to the site consuming 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 secure origins. There's no advantage to using
WebCrypto to doubly encrypt the password in this context, and I don't think
it's something we should encourage.

Thanks!

--
Mike West mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

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

[Mike West]

On Fri, Aug 1, 2014 at 3:31 PM, Brian Smith br...@briansmith.org wrote:

 There is some tension here between making things password-specific and
 simple vs. making them general and harder to understand. Defining this
 as a mechanism to protect only passwords keeps it simple. But, it
 seems wrong to have a way to protect passwords but not credit card
 numbers and social security numbers and other very sensitive input
 fields that don't use input type=password.

I hadn't considered autofilled credit cards; that's a reasonable use case.

We could address credit cards by turning the CSP directive into a list
of autocomplete attribute values: `form-readonly cc-number cc-csc ...
current-password new-password`. That seems like it would address the
credential use case, while leaving flexibility for future field types
that developers might care about giving extra protection.

That said, it gets quite verbose. If we go this route, perhaps we
could come up with a chunk of those types we'd expect developers to
want to protect, and give them a special keyword expression:
`form-readonly 'the-usual-stuff'`.

 I am not sure that looking only at POSTs is sufficient.

I don't think we should encourage GET-based submission of valuable information.

 websites put login forms on every page (whether they should or not).

If we filled a form on every page, but the user never logged in, there
would indeed be a (marginal?) performance impact if we had to examine
every POST a website made. That feels like an edgy enough case that we
don't have to worry too much about it, but I don't have any numbers to
back that up.

 But, I agree that it would be better to avoid the need for the
 attribute if we can.

The less work we make the website do to get some security benefit, the better.

 I suspect some websites will want to disable some aspects of their
 form validation code if they are dealing with placeholders instead of
 the real values, especially if the mechanism is extended to things
 such as social security numbers and credit card numbers.

If the field is write-only, they won't be able to do client-side
validation. That's a necessary consequence of keeping the password out
of the renderer, and out of reach of JavaScript. I agree that this is
more problematic for SSN or CC fields than for passwords, but I don't
see an alternative that would keep the renderer in the dark about the
actual value.

If they use the credential management API to get credentials, they'll
only be getting credentials the user saved. Presumably the user
wouldn't save credentials that weren't valid for the site.

 I'm pretty happy to break that use case, given that the credential API I've
 proposed is locked to secure origins. There's no advantage to using
 WebCrypto to doubly encrypt the password in this context, and I don't think
 it's something we should encourage.

 I think it is fine to say that this would be mutually-exclusive with
 WebCrypto-based approaches to encrypting passwords in the short term.
 However, I think it is too early in the history of WebCrypto to say
 that there's advantage to encrypting passwords (or other sensitive
 information like credit card numbers) in a way that protects them from
 the from the web server. I think it is likely that some way of
 composing WebCrypto and this mechanism will be necessary, eventually.

I'm curious about the use cases for protecting the password from the webserver.

I've had some conversations with Sigbjørn Vik about returning hashed
passwords rather than real passwords, which might be going along the
lines you're thinking. That is, the site would provide hash function
and a server nonce when requesting credentials, 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 case you're considering?

--
Mike West mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

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

[Mike West]

Thanks Jacob!

On Fri, Aug 1, 2014 at 6:48 PM, Jacob S Hoffman-Andrews j...@eff.org 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 headers
 on 99% of its website, but then for some reason doesn't have them on one
 page, that page is a potential vector to expose the credential.

1. Nothing in the 'writeonly' document prevents UAs from using some
sort of heuristic to determine when to fill forms. We already look at
things like the form action, there's no reason we couldn't also look
at the page-level policy, or field-level attributes. Tagging the
credential as 'writeonly' is certainly compatible with this approach.

2. We need CSP anyway in order to specify where forms may permissibly
be submitted. Using it as a mechanism for setting a writeonly policy
seems like a reasonable extension.

 I think making input fields write-only is more powerful than we strictly
 need. When a user is manually entering a password, it's okay for the page to
 be able to read the value they are typing in. If the page has been modified
 by an attacker at this point, it's too late.

It seems like we could prevent this attack if we stop firing events on
'writeonly' fields. At best, that would prevent reading the value. At
worst, that would make the attacker's job harder (she'd have to layer
an invisible field over the password field and do magic to get the
value out of the one and into the other).

 What we want is a mechanism to specify 'once this value is stored in a
 password manager*, protect it from future JS on this page.' That's why I
 feel like it's relevant to define credential management APIs for the web.

 *or credit card autofiller.

1. How do we retroactively apply this policy to users' existing
credentials? 'writeonly' is a nice, drop-in solution that works for
existing credentials as well as new credentials.

2. I'd prefer not to rely on multiple subsystems' understanding of the
protect from JS concept. In Chrome, at least, credit cards and
passwords are in separate databases, and filled via different code
paths. I suspect that doing the work once at the DOM-level would be
less error-prone.

 The write-only spec fully breaks XHR form submission (style C in my earlier
 mail). As Brian pointed out, the placeholder approach can be made to work
 with XHR if you're willing to do a little extra inspection of arbitrary
 XHRs.

This approach breaks XHR-based systems which read the data directly
from the form field. It doesn't necessarily break an API-driven
mechanism.

 Also, as you pointed out, write-only breaks client-side validation.
 Client-side validation is very broadly used for password strength meters
 during signup and change password. I think interfering with strength meters
 would make it a lot harder for implementers to adopt the spec.

Would we need strength meters for sign-in forms? We'd really only need
those for sign-up forms when users are creating an account, right? If
we can find a reasonable way of distinguishing the two, we can address
this use case.

For example, if we set a CSP which includes
`autocomplete=current-password`, but excludes
`autocomplete=new-password` (and we assert that browsers are updated
to exclude 'new-password' from autofill), we'd get the advantages of a
blanket page-level policy, while allowing developers to help users
create strong passwords.

 I'm curious about the use cases for protecting the password from the
 webserver.

 One common use case for client-side crypto is removing systems from scope in
 PCI (payment card industry) compliance. There's a set of standards related
 to the handling of credit/debit cards that involve auditing all systems that
 have card data. There are third-party services that offer compliance by
 having you encrypt card data in JS and pass it, encrypted, through all your
 non-compliant systems and into their secure vault where it is decrypted.

Interesting. The proposal I've made doesn't support this use case. How
common do you believe it is? If we need to support it, then blocking
JS-level access to the form data will be difficult.

-mike

Proposal for a credential management API.

[Mike West]

TL;DR: Strawman spec and usecases at
https://github.com/mikewest/credentialmanagement

# Use Cases

User agents' password managers are a fragile and proprietary hodgepodge of
heuristics meant to detect and fill sign-in forms, password change forms,
etc.
We can do significantly better if we invite websites' explicit cooperation:

* Federated identity providers are nigh undetectable; I don't know of
any password managers that try to help users remember that they signed
into Stack Overflow with Twitter, not Google.

* Signing in without an explicit form submission (via XHR, WebSockets(!),
etc) is good for user experience, but difficult to reliably detect.

* Password change forms are less well-supported than they could be.

* Users are on their own when creating new accounts, faced either with a
list of identity providers they've mostly never heard of, or with the
challenge of coming up with a clever new password.

More background and exploration of native equivalents at
http://projects.mikewest.org/credentialmanagement/usecases/.

# Workarounds

HTML defines a number of `autocomplete` attributes which help explain
fields'
purpose to user agents. These make the common case of form submission more
reliably detectable, but are less helpful for XHR-based sign-in, and don't
address federated identity providers at all.

# Proposal:

The API I'm outlining here is intentionally small and simple: it does not
attempt to solve the general authentication problem in itself, but instead
provides an interface to user agents' existing password managers. That
functionality is valuable _now_, without significant effort on the part of
either browser vendors or website authors.

The API quite intentionally winks suggestively in the direction of an
authentication API that would, for instance, do an OAuth dance on behalf of
an
application, but that's not the immediate goal.

```
[NoInterfaceObject]
interface Credential {
  readonly attribute DOMString id;
  readonly attribute DOMString name;
  readonly attribute DOMString avatarURL;
};

[Constructor(DOMString id, DOMString password, DOMString name, DOMString
avatarURL)]
interface LocalCredential : Credential {
  readonly attribute DOMString password;
};

[Constructor(DOMString id, DOMString federation, DOMString name, DOMString
avatarURL)]
interface FederatedCredential : Credential {
  readonly attribute DOMString federation;
};

partial interface Navigator {
  readonly attribute CredentialsContainer credentials;
};

interface CredentialsContainer {
  PromiseCredential? request(optional CredentialRequestOptions options);
  Promiseany notifySignedIn(optional Credential credential);
  Promiseany notifyFailedSignIn(optional Credential credential);
  Promiseany notifySignedOut();
  readonly attribute PendingCredential? pending;
};
```

A more detailed specification is up at
http://projects.mikewest.org/credentialmanagement/spec/.

# Example:

```
navigator.credentials.request({
  'federations': [ 'https://federated-identity-provider.com/' ]
}).then(function(credential) {
  if (!credential) {
// The user had no credentials, or elected not to provide one to this
site.
// Fall back to an existing login form.
  }

  var xhr = new XMLHttpRequest();
  xhr.open(POST, https://example.com/loginEndpoint;);
  var formData = new FormData();
  formData.append(username, credential.id);
  formData.append(password, credential.password);
  xhr.onreadystatechange = function () {
if (this.readyState != this.DONE)
  return;
var loginSucceeded = // Process response: if login succeeded, yay! If
not, boo!;
if (loginSucceeded) {
  navigator.credentials.notifySignedIn(credential);
  // Notify the user that signin succeeded! Do amazing, signed-in
things!
} else {
  navigator.credentials.notifyFailedSignIn(credential);
  // Notify the user that signin failed, and fall back to the usual
experience.
}
  };
  xhr.send(formData);
});
```

More examples at
http://projects.mikewest.org/credentialmanagement/spec/#introduction-examples
.

It's not clear to me that WebApps is the right venue 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 mk...@google.com
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äftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: CSP 1.1 DOM design

[Mike West]

On Sun, Nov 4, 2012 at 9:58 PM, Alex Russell slightly...@google.com wrote:

 Looking at Section 3.4 of the CSP 1.1 draft [1], I'm noticing that the IDL
 specified feels very, very strange to use from the JS perspective.


Thanks for taking a look! This is great feedback.


 For instance, the name document.SecurityPolicy would indicate to a mere
 JS hacker like me that the SecurityPolicy is a class from which instances
 will be created. Instead, it's an instance of the SecurityPolicy interface.
 A more idiomatic name might be document.policy, document.csp, or
 document.securityPolicy as leading-caps tend to be reserved for classes,
 not instances.


Adam, do you remember why we ran with 'SecurityPolicy' rather than
'securityPolicy'? I know we discussed it, but I can only find the comment
resulting from that discussion (
https://bugs.webkit.org/show_bug.cgi?id=91707#c5).


 Similarly, it's not possible (AFAICT) to new-up an instance of
 SecurityPolicy and no API provided for parsing a policy to understand how
 it would react.


That's an interesting suggestion. What's the use-case you see for providing
a mechanism for parsing/examining a policy?

The only thing I can come up with off the top of my head is the tool we
briefly chatted about that would help developers understand the impact of a
policy. :)


 Lastly, there's no serialization method provided. A toString()
 implementation might work well.


What would the string representation of the object look like? Just the
original policy?

One complication is that the page's active policy might be created by the
union of several policies (one sent per HTTP, one in a meta tag, etc).
Would we want to retain that representation in a string version?


 readonly attribute DOMString[] reportURIs;


We decided at TPAC to remove the reportURIs getter unless someone has a
really good use-case for it.


 One open issue: I'm not sure If allowsEval, allowsInlineScript, and
 allowsInlineStyle should just be boolean getters or if they should stay
 methods.


I like the idea of converting these `allowEval()`-style calls to read-only
booleans. Perhaps 'isActive' as well.


 Also, it's unclear if the current document's policy should simply be a
 locked-down instance of a SecurityPolicy class that has accessors for each
 of the policy items (script-src, object-src, style-src, img-src,
 media-src, frame-src, font-src, connect-src).


I think that's more or less what the current interface does. (e.g.
`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 CSP in order to
usefully include on a page. Should we revisit that question?

Thanks again!

--
Mike West mk...@google.com, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91