CREDENTIAL: Reconsider the top-level browsing context limitation.

[mikewest]

From @mikewest on May 20, 2015 18:54

Step 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.

I'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.

I 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.

/cc @devd, @terriko, @dveditz who also participated in the discussion.

Copied from original issue: w3c/webappsec#380

[mikewest]

From @hillbrad on May 20, 2015 20:15

Thanks, Mike. It think requiring user mediation is a good safeguard here.

On Wed, May 20, 2015 at 11:54 AM Mike West notifications@github.com wrote:

Step 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 https://github.com/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.

I'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 https://github.com/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.

I 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.

/cc @devd https://github.com/devd, @terriko https://github.com/terriko, @dveditz https://github.com/dveditz who also participated in the discussion.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/380.

[mikewest]

From @terriko on May 20, 2015 21:25

The more I think about this, the more I think we should really do some usability research on this front, at least at the level of "buy a user a beer and get them to tell us if this is totally confusing" repeated a few times before it gets encoded into a standard, because it's pretty clear that what's confusing to us and what's confusing to other users is going to be pretty different. I'll do a quick trawl through some usable security papers and see if this is obviously a bad (or good) interface, too.

[mikewest]

CCing @adrifelt, who has both opinions about security UX and permissions/requests from iframes.

[mikewest]

From @adrifelt on May 22, 2015 21:37

I agree with the concerns stated here: iframes are confusing to people, and it may not be clear who the request for credentials is coming from.

I'm somewhat confused though. When will credentials every be supplied without user interaction?

[mikewest]

I'm somewhat confused though. When will credentials every be supplied without user interaction?

Assume something like the mock in https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection, which gives a user the ability to automagically log into a website if they choose to do so.

[mikewest]

From @adrifelt on June 4, 2015 1:17

@mikewest Raymes Khoury and Ben Wells are going to do a usability study on the topic of iframes and user expectations. This might be worth mentioning to them. I have no good answers for what users expect w/r/t iframes so I'm really glad they're planning to look into this.

[mikewest]

Punting this for the moment, as the status of permission requests in frames is somewhat up in the air.

@hillbrad, would this block Facebook from implementing?

[mikewest]

From @hillbrad on September 4, 2015 16:12

Just to be clear - you're not changing the requirement that the promise for get() be rejected in anything but a top-level browsing context.

I don't know that this would particularly block Facebook, but I know it would greatly decrease the usefulness of the features to someone like PayPal, which uses in-context iframes for checkout and has short-lived sessions. I see that pop-up dialogs are problematic in embedded contexts, but still feel that for origin-bound credentials this should be safe, modulo some UI redress scenarios that can and should be addressed by X-Frame-Options or CSP frame-ancestors.

Is the form auto-filler disabled for iframes?

On Fri, Sep 4, 2015 at 2:29 AM Mike West notifications@github.com wrote:

Punting this for the moment, as the status of permission requests in frames is somewhat up in the air.

@hillbrad https://github.com/hillbrad, would this block Facebook from implementing?

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/380#issuecomment-137688661.

[mikewest]

My thought here is that it's easy to add functionality if we discover that we need it, but taking it away is hard.

I'd like to get a minimal version of this shipping in Chrome so we can begin iterating on the implementation based on experience rather than guesswork. shrug

It may well be that the initial feedback is "I can't use this because frames!" In which case, we should revisit this big for v1. :)

I suspect the bigger chunk of complaints will be around the HTTPS requirements, though. That's what I'm hearing today (though I'm not inclined towards budging on it :) ). On Sep 4, 2015 18:12, "Brad Hill" notifications@github.com wrote:

Just to be clear - you're not changing the requirement that the promise for get() be rejected in anything but a top-level browsing context.

I don't know that this would particularly block Facebook, but I know it would greatly decrease the usefulness of the features to someone like PayPal, which uses in-context iframes for checkout and has short-lived sessions. I see that pop-up dialogs are problematic in embedded contexts, but still feel that for origin-bound credentials this should be safe, modulo some UI redress scenarios that can and should be addressed by X-Frame-Options or CSP frame-ancestors.

Is the form auto-filler disabled for iframes?

On Fri, Sep 4, 2015 at 2:29 AM Mike West notifications@github.com wrote:

Punting this for the moment, as the status of permission requests in frames is somewhat up in the air.

@hillbrad https://github.com/hillbrad, would this block Facebook from implementing?

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/380#issuecomment-137688661.

— Reply to this email directly or view it on GitHub https://github.com/w3c/webappsec/issues/380#issuecomment-137779437.

[AngeloKai]

Re-activating this thread again because a couple of RPs using WebAuthn have indicated the top level browsing context is important to them. A good data point to have is that cred ui dialog (a similar mockup as seen here) already have been used in iframe context in a couple of times. At least for the WebAuthn use case, our dialog shows the origin and name of the RP. If an iframe prompts the dialog, which would be at the center of the page, the user would recognize the origin.

[battre]

Just to be sure I understand this. You are saying that RPs want to give access to the api in a non-top level browsing context, right? (www.example.com embedds www.my-identity-provider.com which talks to a security token)

Looking at your screenshot, I am actually surprised if users noticed that they are granting access to an iframe instead of the top level browsing context. Where is the origin mentioned?

[AngeloKai]

@battre The origin isn't in the screenshot because the screenshot isn't the actual webauthn one. I can't share the actual UI on a public domain without at least going through a round of legal approval.

[mikewest]

If changing things to allow nested access makes y'all happy, that sounds fine. I don't know how we'd present UI for it in Chrome, so I'll defer to @battre for actual implementation questions, but weakening the language in the spec to allow the browser to decide whether or not it allows a given request sounds reasonable to me. Do you have a preference for what we should say in https://w3c.github.io/webappsec-credential-management/#security-origin-confusion instead of the current language?

[battre]

I followed up on an email with Angelo and it was unclear what is actually desired: Supporting the API in cross origin iframes or agreeing that it will never happen.

[mikewest]

@jcjones brought it up in the WebAppSec TPAC planning doc. Perhaps he has opinions from Mozilla's side?

[jcjones]

In-person at the last Web Authentication meeting, there was discussion of relaxing the limitation to permit usage in a nested browsing context if all the nested contexts were from the same origin as the top-level one. Not having caught up over here, I didn't realize this wasn't already under discussion. I'm pinging the relevant parties over email to join in here.

[equalsJeffH]

this issue was at least improved by the recent PR #114 "Remove the blanket restriction against nested usage"

[apowers313]

I just want to echo @AngeloKai 's comment: I'm hearing from RPs that they need this for WebAuthn.

I'm not really clear about what the next steps are to progress this issue. Does CredMan have standing calls? Or is there some other forum for driving this to resolution?

[mikewest]

@apowers313: I believe the credential management API delegates the decision about what to do in nested contexts to y'all (see the PR @equalsJeffH noted above). If y'all wish to change step 2 of https://www.w3.org/TR/webauthn/#discover-from-external-source to not exit early, you could.