Re: forceAuthentication

[Shane Tomlinson]

+dev-identityto put this into the open

Skinny's question:
"Also, are we NOT asking for the password for primary addresses?"

Response:
We have no way of forcing a primary to force their users to enter their
password. We can only do this for email addresses that rely on the
fallback identity provider.

From my email last week:
This behavior is probably unexpected from an RP POV, but not from a
technical POV. We (currently) have no control over the session with the
IdP.

The following scenario means the user only has to type in an email
address without typing a password:

1) User has a session with IdP
2) RP uses "forceAuthentication: true" in their call to
navigator.id.request
3) User types in email address of IdP from #1
4) Since the user is signed in with the IdP, they are automatically
signed in without typing in a password.

A native implementation could wipe the session cookie with the IdP, but
shimmed flows have no such control.

What would we expect to happen here when the user enters an IdP
supported email address?

Shane



On 02/04/2013 18:21, Jedediah Parsons wrote:
> Thanks for making the video, Shane. It certainly does appear to work a little oddly.
>
> I thought the point was to ask for the user's credentials again
> (https://bugzilla.mozilla.org/show_bug.cgi?id=811012)
>
> I was imagining that this was supposed to be the equivalent of Apple asking you for your password to re-auth you for apple store purchases etc.
>
> Apart from the initial bug, I don't have much more info about this. I would expect that we should be asking for the password and not the email, but maybe there's a question here for marketplace product people?
>
> ----- Original Message -----
> From: "Crystal Beasley" <cry...@mozilla.com>
> To: "Jedediah Parsons" <jpar...@mozilla.com>
> Cc: "Shane Tomlinson" <stoml...@mozilla.com>, "Crystal Beasley" <ski...@mozilla.com>
> Sent: Tuesday, April 2, 2013 10:06:33 AM
> Subject: Re: forceAuthentication
>
>
>
>
> Shane,
>
> I'm not sure I understand. Why are we asking users to enter their email? Do we not have a way of bringing up the popup with their email already filled?
>
> Also, are we NOT asking for the password for primary addresses?
>
>
> c
>
>
>
>
> On Tue, Apr 2, 2013 at 9:33 AM, Jedediah Parsons < jpar...@mozilla.com > wrote:
>
>
>
> Awesome Shane - Skinny, many thanks for taking a look
>
>
>
> ----- Original Message -----
> From: "Shane Tomlinson" < stoml...@mozilla.com >
> To: "Crystal Beasley" < ski...@mozilla.com >, "Jedediah Parsons" < jpar...@mozilla.com >
> Sent: Tuesday, April 2, 2013 9:15:15 AM
> Subject: forceAuthentication
>
> Hey Skinny, can you check out the video that I sent out about
> forceAuthentication? Before Jed and I start the merge into dev, I want
> to make sure everything is as it should be.
>
> http://www.youtube.com/watch?v=IQtCsRkDjQI&feature=youtu.be
>
> Primaries, when the user has a session with them already, seem a bit
> strange because the user only has to type an email address.
>
> Could you respond to the message I sent out on the public list? I want
> to see what others are thinking as well.
>
> Thanks,
> Shane
>
>
>
>

[Ben Adida]

Thanks for digging into this Shane.

Response:
> We have no way of forcing a primary to force their users to enter their
> password. We can only do this for email addresses that rely on the fallback
> identity provider.
>

That's right, and I want to emphasize, again, that we knew going into this
API proposal for FXOS that this would be the case until we make a number of
updates to certs and the IdP protocol. In other words, we accepted that
this would be a very superficial level of security, until we do it right.

Something like:

A native implementation could wipe the session cookie with the IdP, but
> shimmed flows have no such control.
>

is not enough for the full solution. The threat model here is that the site
wants reauthentication, and doesn't trust the user's browser to do the
right thing. So you need support from the IdP.

I believe "doing it right" requires us to fully support levels of
assurance, where the IdP can be asked to generate a certificate of a
certain kind, and embed additional information in the certificate. For
example, the specific level of assurance for this operation would be "fresh
one-time cert", which would be a 1-minute duration certificate with a
"fresh" flag that the IdP commits to only issuing once per actual
authentication action.

That's a high bar: IdP tweaks, data format tweaks, verifier tweaks.

-Ben

[Jedediah Parsons]

Supporting levels of assurance like you describe would be a great feature, and I expect IdPs and RPs would be wholly behind it.

Is it fair to say, then, that the forceAuthentication feature as it's implemented now is the best we can do under the circumstances, and that we can go ahead an merge it into dev as an experimental feature, with the intention of revisiting it in the future?

j

[Ben Adida]

On Wed, Apr 3, 2013 at 11:32 AM, Jedediah Parsons <jpar...@mozilla.com>wrote:

> Is it fair to say, then, that the forceAuthentication feature as it's
> implemented now is the best we can do under the circumstances, and that we
> can go ahead an merge it into dev as an experimental feature, with the
> intention of revisiting it in the future?
>

I think so, as long as everyone is clearly aware of the kind of security
we're trying to provide here, which is superficial at first. Not nothing,
but not super strong either.

-Ben

[Sean McArthur]

I find it a bit disingenuous to add it to the public API, and publicly
document it, when it can't completely work. Identity and security isn't a
place to say "we promise! as long as its not an idp!"

Also, as for an IdP adopting that part of the spec, if we start having many
small parts to being an IdP, we could run into the problem of people only
implementing parts. They can add support for authentication and
provisioning, without the "fresh" certs, and we wouldn't know until an RP
asked for a fresh cert and never got one.

[Jedediah Parsons]

The feature of at least letting an rp specify the time-to-live for an assertion would be helpful here, and also more broadly for the case of b2g sign-in. On b2g, we want authentication to last a long time; on desktop we don't. Currently, 'authentication_duration_ms' is set in the config, so we can't support different behavior on desktop and b2g from the same persona server.

----- Original Message -----
From: "Ben Adida" <b...@adida.net>

[Dan Callahan]

On 4/3/13 1:39 PM, Sean McArthur wrote:
> I find it a bit disingenuous to add it to the public API, and publicly
> document it, when it can't completely work. Identity and security isn't a
> place to say "we promise! as long as its not an idp!"

I'm with Sean.

We have to merge this to resolve divergence between the b2g and mainline
branches, but I'm not comfortable making this publicly available in its
current form.

Can we whitelist this for Marketplace w/ B2G user agents, but ignore it
elsewhere until we can actually back up its claim?

-Callahad

[Shane Tomlinson]

On 03/04/2013 20:51, Dan Callahan wrote:

> I'm with Sean.
>
> We have to merge this to resolve divergence between the b2g and
> mainline branches, but I'm not comfortable making this publicly
> available in its current form.
>
> Can we whitelist this for Marketplace w/ B2G user agents, but ignore
> it elsewhere until we can actually back up its claim?
>

JedP and I have talked about whitelisting the Marketplace set of RPs. A
whitelist allows us to take a conservative approach to feature rollout
but still help our friends in the Marketplace.

Shane

[Ben Adida]

On Wed, Apr 3, 2013 at 12:51 PM, Dan Callahan <dcal...@mozilla.com> wrote:

> Can we whitelist this for Marketplace w/ B2G user agents, but ignore it
> elsewhere until we can actually back up its claim?
>

I'm not opposed to whitelisting (in fact I suggested it), but I think we
want to consider the downside of whitelisting. Why should experimental
features only be available to "our friends?" We can mark features as
experimental, with plenty of disclaimers including the possibility that we
turn it off at any time. Limiting experimental features to only other folks
within Mozilla feels a good bit less open to me.

So sure, let's consider whitelisting, but let's do it with caution. It has
a cost, I think.

-Ben

[Sean McArthur]

Part of the reason it works on Marketplace is that it requires forceIssuer
to be set as well. We could require that both be set to get the desired
circumstances, but that starts to get gross. Especially as we turn on
BigTent, the majority of our users aren't going to be re-authenticated.

As for whitelisting, that's like staff-deploying. We're **testing** on an
RP we can trust to change quickly if we need to. Just don't publicize it.

[Ben Adida]

On Wed, Apr 3, 2013 at 4:39 PM, Sean McArthur <smca...@mozilla.com> wrote:

> Part of the reason it works on Marketplace is that it requires forceIssuer
> to be set as well. We could require that both be set to get the desired
> circumstances, but that starts to get gross. Especially as we turn on
> BigTent, the majority of our users aren't going to be re-authenticated.
>

Yeah, I was thinking about this too, but I think forceIssuer is likely to
die soon, while forceAuthentication may live with a better implementation,
so that doesn't feel right.

> As for whitelisting, that's like staff-deploying. We're **testing** on an
> RP we can trust to change quickly if we need to. Just don't publicize it.
>

I don't know, we're talking about a phone in customer hands! That's not
quite the same thing.

Why does it hurt to call this an experimental feature? I think we agreed we
would be open to this kind of feature category, to test the waters on
something new.

-Ben

[Francois Marier]

On 03/04/13 19:44, Ben Adida wrote:
> Why does it hurt to call this an experimental feature? I think we agreed we
> would be open to this kind of feature category, to test the waters on
> something new.

Back when DanC and I were talking about deprecation policies and trying
to find ways to not be stuck with experimental features forever, we
floated the idea of spamming the console with "Warning: foobar is an
experimental feature that could be removed at any time".

Is that something that could help in this case?

Francois

[Dan Callahan]

On 4/3/13 6:10 PM, Ben Adida wrote:
> On Wed, Apr 3, 2013 at 12:51 PM, Dan Callahan <dcal...@mozilla.com> wrote:
>
>> Can we whitelist this for Marketplace w/ B2G user agents, but ignore it
>> elsewhere until we can actually back up its claim?
>>
>
> I'm not opposed to whitelisting (in fact I suggested it), but I think we
> want to consider the downside of whitelisting. Why should experimental
> features only be available to "our friends?" We can mark features as
> experimental, with plenty of disclaimers including the possibility that we
> turn it off at any time. Limiting experimental features to only other folks
> within Mozilla feels a good bit less open to me.

Misleading people also feels pretty bad. forceAuthentication doesn't
force authentication, at least with BigTent.

If we didn't *need* to do this for the FxOS Marketplace, I'm not sure it
would pass review in its current form for that reason.

> So sure, let's consider whitelisting, but let's do it with caution. It has
> a cost, I think.

We got burned with requiredEmail, including at least one RP that was
using it to protect client-privileged information. And it had ample
"experimental" warnings on it, too.

-Callahad

[Shane Tomlinson]

Comments inline and an environment specific whitelisting proposal at the
end.

> On 4/3/13 6:10 PM, Ben Adida wrote:
>>
>> I'm not opposed to whitelisting (in fact I suggested it), but I think we
>> want to consider the downside of whitelisting. Why should experimental
>> features only be available to "our friends?" We can mark features as
>> experimental, with plenty of disclaimers including the possibility
>> that we
>> turn it off at any time. Limiting experimental features to only other
>> folks
>> within Mozilla feels a good bit less open to me.
>

What are our goals for this feature? Are we going to require that IdPs
support forceAuthentication? Are we going to retrofit this into BigTent?
If we are, and we air our plans publicly, I counter with we are being
open about our plans, we are asking for feedback, and we are releasing
the implementation in an incremental fashion to help flesh out intricacies.

> Misleading people also feels pretty bad. forceAuthentication doesn't
> force authentication, at least with BigTent.
>
> If we didn't *need* to do this for the FxOS Marketplace, I'm not sure
> it would pass review in its current form for that reason.

This was my initial impression as well. FxOS and IdPs are going to
conflict several times during this merge. forceIssuer?

>> So sure, let's consider whitelisting, but let's do it with caution.
>> It has
>> a cost, I think.
>
> We got burned with requiredEmail, including at least one RP that was
> using it to protect client-privileged information. And it had ample
> "experimental" warnings on it, too.
>

Balancing both of these costs is difficult. If we use a whitelist, we
alienate RPs who want to use the feature. If we release the feature to
the public but later have to rescind it, we alienate the RPs who are
happily using it. If we release the feature to the public and RPs are
surprised by how it works w.r.t. primaries, we alienate RPs who expected
something different. If we publicly release it and it all goes well,
hurray. Realistically, is this feature at that point?

For my proposal:

Can we use an environment specific whitelist to determine whether a
given experimental feature is available to an RP? For example, in dev
and beta, forceIssuer would have an RP whitelist of "*", meaning any RP
can use the feature. This gives all RP developers a chance to try
experimental features and give us feedback, in a manner that is
unequivocally understood to mean "this feature can be removed at any time."

In prod, Marketplace is the only RP on the whitelist. Once we feel
confident in the behavior of the API, we change the whitelist to *,
opening the feature to everyone, in all environments.

Shane

[Crystal Beasley]

I'm not comfortable with anyone using forceAuthentication unless they're
also using forceIssuer. This is mainly because of the problems with proxied
primaries.

And I'm not comfortable with anyone using forceIssuer other than
Marketplace, because I don't want RPs taking control of my users'
experience.

Ergo, both features should be whitelisted to Marketplace only.

c

[Jared Hirsch]

-1 to whitelisting. I'm not comfortable shipping closed features.

My understanding of this issue is, we're shipping an incomplete/immature
API for Marketplace. And whitelisting is an attempt to "protect" everybody
else from using a bad API, both RPs and users.

Consider what the future holds:
* Q2: the signin team is not planning to iterate on this API
* Q3: forceAuthentication lands in consumer phones and becomes a de facto
permanent API

If we close off part of the API now, it's going to sit for the next three
months, and be closed for a long time to come after that--probably until we
come up with the "better" version. No clear picture on when that happens,
if at all.

Suppose we treat this as an experimental API: do a proper blog post and
encourage people to play with it and offer feedback!
Sure, stuff will go sideways at times, but we're taking advantage of being
in beta. Feedback from other users will give us better information on how
to evolve the API.

Let's keep on rocking the **open** web :-)

Jared

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Crystal Beasley]

I am a big proponent of forceAuthentication. I opened a bug with the idea
for it back in the yonder whiles when bugs had only three digits. #895 If
we get gmail and hotmail online with BigTent before we have a fix for this,
forceAuthentication won't work for 80% of users. We can ship it now but
what will happen when we bring gmail and hotmail up? Do you think forceAuth
is worth blocking BigTent? Or do we bust forceAuth for 80% of users?

As for forceIssuer, I do not want it to be used by any sites outside of
Mozilla properties. It's something we have to do to support our company's
number one priority, so we are doing it. Making it public only hurts our
users by giving them an inconsistent, confusing experience of sometimes
having a password, sometimes not.

c

[Jedediah Parsons]

You're making me think that we need to have a b2g + BigTent pow-wow and get this in our QA process right away. I think b2g (or b2g and picl, as the collective native implementations) and Big Tent, having been developed independently and in parallel, need to talk to each other more. Big Tent is Persona, and the platform functions that support marketplace need to operate 100% correctly in a Big Tent world.

A footnote regarding forceIssuer: I agree with you that it should be used judiciously, and we can also probably find ways to do it better. But at the end of the day, I don't think it's a Mozilla-marketplace-only thing. As Ozten has pointed out elsewhere, if Google were to become an IdP, they would surely want something like forceIssuer to use with their google properties to make the sign-in flow smoother. So forceIssuer might actually be a feature that encourages broader IdP adoption.

Ultimately the goal of forceIssuer is to make the sign-in process less painful (by not kicking over to primary auth during a sign-in flow for the marketplace, for example, which could get hairy). If our forceIssuer implementation is worse for users than a non-forceIssuer world, that would certainly make a strong case for ditching forceIssuer!

[Sean McArthur]

I don't see how forceIssuer makes it less painful. We're forcing someone,
who could have been logged into their IdP, to not use their IdP, and
potentially create a new password (which face it, will probably be the same
password as they use for their IdP) on the forced issuer. I'd rather see
how we can move Marketplace off that, instead.

[Kumar McMillan]

Why is Marketplace using forceIssuer again? Every time I think I know the answer to this I don't. Is it because only the Mozilla IdP implements unverified emails and we want to be sure new users can unbox Firefox OS and create an account without verifying their email? Is the answer to moving Marketplace off of forceIssuer maybe just "wait until all IdPs support unverified emails"? Not saying that's a realistic solution, I'm just trying to refresh my memory on the rationale.

-Kumar

[Jedediah Parsons]

I think the main purpose is to prevent the login flow from doing primary IdP lookup and potentially a provisioning and authentication flow with that IdP. Doing those flows would open up an additional two screens in addition to the existing persona auth flow, which product strongly disapproved of last year. So to prevent that extra friction, we force the fallback to mozilla's persona idp, which, as skinny says, goes hand-in-hand with unverified email. At the point where you actually have to verify the user's email, then you make them go through the full steps.

If IdPs could support unverifiedEmail in a way that did not involve any user interaction, then I think there would not be much of a case left for this feature. But getting to the point where IdPs can do this is the trick.

But I don't mind admitting that this stuff melts my brain, or at least makes it a bit mushy, and I wouldn't be surprised if I missed something important :) I hope someone will step in and correct me if so!

[Lloyd Hilaiel]

This is my recollection as well. From a usability perspective we were unwilling to put IdP screens (other peoples web content) into the FirefoxOS unboxing experience.

Generally speaking at a higher level - I believe the utility of unverified email is nearly eliminated when a primary is in play. The appeal of "Unverified email" is directly proportional to signup friction, which is drastically decreased when you're using an email address and the password associated with that email address.

lloyd

[Kumar McMillan]

On Apr 4, 2013, at 8:10 PM, Lloyd Hilaiel <ll...@mozilla.com> wrote:

> This is my recollection as well. From a usability perspective we were unwilling to put IdP screens (other peoples web content) into the FirefoxOS unboxing experience.
>
> Generally speaking at a higher level - I believe the utility of unverified email is nearly eliminated when a primary is in play. The appeal of "Unverified email" is directly proportional to signup friction, which is drastically decreased when you're using an email address and the password associated with that email address.

Yeah, I was thinking about this after I hit send. If a user unboxes a Firefox OS phone and logs in with an existing email tied to a *primary* IdP then no verification step is needed anyway.

[Sean McArthur]

I'm sure the reason was brought up long ago, but I don't remember it, so
please forgive me, and it's relevant here:

Why don't we provide a Firefox IdP, and the user just has to pick a
username and a password?

This lets the unverified email problem be on the IdP, instead of trying
fake it in the navigator.id API. If these are Marketplace-specific
requirements, why not solve it with a Marketplace-specific IdP? Added
benefit is that now, all those users are logged in to an IdP, and elsewhere
on the web, can log in with that one instead.

I can't help but feel like that would be the answer we would choose if this
were for someone else. If it were Google, or Yahoo, or GitHub, or whomever
else, wouldn't we say "you can handle that however you like in your IdP
implementation"?

[Ben Adida]

Hi Sean,

It's something we debated for a good bit. But, as per the blog post I wrote
today, we did not want to forever enshrine the idea that you had to create
an account with Mozilla to use the phone. The bar for being a phone IdP
would likely be high (same as IdP++), but it would not be artificially hard.

So forceIssuer is really a temporary thing that fakes the IdP++ situation.

I'll respond to the initial issue separately :)

-Ben

[Ben Adida]

Hi team,

So we have a lot of strong opinions on this thread, which is a good thing.
Let me try to unravel/simplify a little bit. Let's keep an open mind (and
that includes me.)

First, let me try to put a couple of arguments to rest:

- changing forceIssuer for Firefox OS at this point is a no-go. Maybe in a
future version. I don't think we got this wrong, actually, but we probably
should postpone this conversation since pragmatically, we're not going to
change the course of action for the next few months.

- requiredEmail is a very different situation. We thought we had a use case
that was useful to RPs. It turns out we didn't. No RPs really needed this
feature the way we anticipated. When we killed the feature, we found out
someone was using this feature in a *completely unintended* way. Not in a
way we intended that we only partially implemented, but in a way we *never*
meant to implement and never even foresaw. So I don't think the comparison
really helps us here.


So, putting those two issues aside, we're weighing the concern of a feature
we haven't fully implemented, which might mislead RPs, vs. the concern of a
feature we're whitelisting for another Mozilla property only.

Like Jared, I've realized recently how uncomfortable I am with the notion
that we would offer a feature only to another Mozilla site. It feels quite
closed. I'm also worried that we would refuse to implement an experimental
feature until it's perfectly right, which is a very hard thing to do in
this case. In fact, it's such a huge feature to do fully right that this
approach might mean we never do it. And yet we know we have a use case,
with a number of RPs having asked for it, and it's an existing web pattern.

So, ignoring Firefox OS for a second: are we saying we just won't do this
feature ever because some RPs might get it wrong? That seems overly
conservative to me, as long as we make a real focused effort to prevent
confusion.

I think we agree that, if we can ensure RPs understand the limitation of
this feature, then it would be okay. We're mostly worried they won't get it.

What if we took this approach:

- to enable experimental API support, the RP has to call:

navigator.id.enableExperimentalAPIs();

This spits out a console warning about "be careful to consult this URL to
make sure you know what you're doing!"

- if an RP calls .request() with forceAuthentication, and the experimental
API has not been turned on, then it's a hard-fail, no popup, big error in
console.

- in any case, calling .request() with forceAuthentication spits out
warnings on the console.

- we do not commit to supporting this for any period of time.

- we take extreme care to document this only on the experimental API page,
not on the main doc page.

Would this be okay?

-Ben

> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Kumar McMillan]

Massive +1 to documenting features like this on a special experimental API page. At least once someone on marketplace used the wrong flag because the feature wasn't documented; we followed a comment in a bug which by that point was already outdated.

Kumar

>
> Would this be okay?
>
> -Ben
>
>

>> ______________________________**_________________
>> dev-identity mailing list
>> dev-id...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>>

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Shane Tomlinson]

I can see the value in this, it is kind of like an experimental DOM api
(mozPay) or experimental CSS declaration (-moz).

As an alternative, can we make use of already existing, well understood,
vendor prefix conventions? This would allow other browser vendors to
experiment with new features as well:

navigator.id.request({
mozForceAuthentication: true
},...


Shane

[Ben Adida]

Hi Shane,

I haven't seen vendor prefixing for optional parameters before... we might
be treading new ground.

In a different context (web crypto), I've seen proposed an approach that
involves an initial .enableCrazyStuff() call, then leaving the rest of the
calls as they would be if the stuff becomes less crazy/experimental. That's
the inspiration for my proposal.

-Ben

[Sean McArthur]

Something the prefixed argument would gain: you could read it and know
which parts were experimental. enableExperimentalFeatures() wouldn't tell
the developer reading the code which part is experimental.

While I could be OK with this, I think it'd be best if we just didn't
document it at all. No announcement. If there's a couple RPs who want to
test it, we tell them privately. Trying to keep small the amount of people
using it.

And no matter how hard we try (just like with _private methods in
JavaScript and Python), there will be people who will use it because they
can, and then potentially never come back to it if we remove it or change
it later.

[Austin King]

+1

This was my assumption and why I didn't document it on MDN. That and I'm
lazy.
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Shane Tomlinson]

On 08/04/2013 21:28, Sean McArthur wrote:
> Something the prefixed argument would gain: you could read it and know
> which parts were experimental. enableExperimentalFeatures() wouldn't
> tell the developer reading the code which part is experimental.
>

This is what I was aiming for, explicitness in the API without the need
to scan multiple lines of code. It may be treading new ground API wise,
but the idea is in the spirit of existing conventions.Has any other API
had to deal with these issues? Is there precedent?

Shane

[Jedediah Parsons]

I'm +1 for prefixes like _experimental_ for our experimental parameters.

I'm less sure about adding .enableCrazyStuff(). You would still need to label your experimental crazy stuff parameters as such, so this would establish one more hoop to jump through but without an obvious (to me) improvement for safety or clarity. Also, more on my mind, in the present situation, introducing such a function would require us touching the b2g client code, which at this point is going to be hard.

/me goes to stand in the side of the room where we have _experimental_forceIssuer and _experimental_forceAuthentication

> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>