{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/3","labels_url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/3/comments","events_url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/3/events","html_url":"https://github.com/w3c/webappsec-credential-management/issues/3","id":110423792,"number":3,"title":"CREDENTIAL: Reconsider the top-level browsing context limitation.","user":{"login":"mikewest","id":1497,"avatar_url":"https://avatars.githubusercontent.com/u/1497?v=3","gravatar_id":"","url":"https://api.github.com/users/mikewest","html_url":"https://github.com/mikewest","followers_url":"https://api.github.com/users/mikewest/followers","following_url":"https://api.github.com/users/mikewest/following{/other_user}","gists_url":"https://api.github.com/users/mikewest/gists{/gist_id}","starred_url":"https://api.github.com/users/mikewest/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikewest/subscriptions","organizations_url":"https://api.github.com/users/mikewest/orgs","repos_url":"https://api.github.com/users/mikewest/repos","events_url":"https://api.github.com/users/mikewest/events{/privacy}","received_events_url":"https://api.github.com/users/mikewest/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/webappsec-credential-management/labels/CREDENTIAL","name":"CREDENTIAL","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-10-08T10:53:28Z","updated_at":"2015-10-08T10:53:31Z","closed_at":null,"body":"_From @mikewest on May 20, 2015 18:54_\n\nStep 3.2 of https://w3c.github.io/webappsec/specs/credentialmanagement/#request-credential rejects the Promise returned by `get()` if it's called from a nested browsing context. @hillbrad suggested that this limitation would be a problem; I argued with him a bit on the last call (http://www.w3.org/2015/05/18-webappsec-minutes.html#item01), but now I think he might be right.\r\n\r\nI'd suggest changing the text to prevent returning credentials _without user mediation_ in a nested browsing context, but allowing the user to choose to grant access to credentials in a nested context. @hillbrad's argument that this actually increases security (for all the reasons that the API/password managers in general increase security in the top-level frame) seem reasonable.\r\n\r\nI am still a bit worried about confusing the user with a popup that refers to a frame inside the document they're looking at, but I'm working on convincing myself that it's fesiable.\r\n\r\n/cc @devd, @terriko, @dveditz who also participated in the discussion.\n\n_Copied from original issue: w3c/webappsec#380_"},"comment":{"url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/comments/146502279","html_url":"https://github.com/w3c/webappsec-credential-management/issues/3#issuecomment-146502279","issue_url":"https://api.github.com/repos/w3c/webappsec-credential-management/issues/3","id":146502279,"user":{"login":"mikewest","id":1497,"avatar_url":"https://avatars.githubusercontent.com/u/1497?v=3","gravatar_id":"","url":"https://api.github.com/users/mikewest","html_url":"https://github.com/mikewest","followers_url":"https://api.github.com/users/mikewest/followers","following_url":"https://api.github.com/users/mikewest/following{/other_user}","gists_url":"https://api.github.com/users/mikewest/gists{/gist_id}","starred_url":"https://api.github.com/users/mikewest/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikewest/subscriptions","organizations_url":"https://api.github.com/users/mikewest/orgs","repos_url":"https://api.github.com/users/mikewest/repos","events_url":"https://api.github.com/users/mikewest/events{/privacy}","received_events_url":"https://api.github.com/users/mikewest/received_events","type":"User","site_admin":false},"created_at":"2015-10-08T10:53:31Z","updated_at":"2015-10-08T10:53:31Z","body":"My thought here is that it's easy to add functionality if we discover that\nwe need it, but taking it away is hard.\n\nI'd like to get a minimal version of this shipping in Chrome so we can\nbegin iterating on the implementation based on experience rather than\nguesswork. *shrug*\n\nIt may well be that the initial feedback is \"I can't use this because\nframes!\"  In which case, we should revisit this big for v1. :)\n\nI suspect the bigger chunk of complaints will be around the HTTPS\nrequirements, though. That's what I'm hearing today (though I'm not\ninclined towards budging on it :) ).\nOn Sep 4, 2015 18:12, \"Brad Hill\" <notifications@github.com> wrote:\n\n> Just to be clear - you're not changing the requirement that the promise for\n> get() be rejected in anything but a top-level browsing context.\n>\n> I don't know that this would particularly block Facebook, but I know it\n> would greatly decrease the usefulness of the features to someone like\n> PayPal, which uses in-context iframes for checkout and has short-lived\n> sessions. I see that pop-up dialogs are problematic in embedded contexts,\n> but still feel that for origin-bound credentials this should be safe,\n> modulo some UI redress scenarios that can and should be addressed by\n> X-Frame-Options or CSP frame-ancestors.\n>\n> Is the form auto-filler disabled for iframes?\n>\n> On Fri, Sep 4, 2015 at 2:29 AM Mike West <notifications@github.com> wrote:\n>\n> > Punting this for the moment, as the status of permission requests in\n> > frames is somewhat up in the air.\n> >\n> > @hillbrad <https://github.com/hillbrad>, would this block Facebook from\n> > implementing?\n> >\n> > —\n> > Reply to this email directly or view it on GitHub\n> > <https://github.com/w3c/webappsec/issues/380#issuecomment-137688661>.\n> >\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/w3c/webappsec/issues/380#issuecomment-137779437>.\n>\n"}}