1009849 - Provide a way for developers to test whether navigator.mozId supports Firefox Accounts

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: FxA, defect)

Description

[Sam Penrose]

Through FirefoxOS 1.4 (which has not shipped yet), navigator.mozId() existed to implement Persona. For 2.0 we will also use it to implement Firefox Accounts via one new optional parameter to watch():

  {wantIssuer: 'firefox-accounts'}

and one to request():

  {refreshAuthentication: i} // i is an integer >= 0 representing a grace period in seconds

RPs who attempt to use those parameters on 1.4 or earlier will not see the behavior they expect. Given that dramatic changes are under consideration* for 2.1, I propose that we add a .version attribute to navigator.mozId starting with B2G 2.0. Could you folks please weigh in and invite others as you see fit?

No opinion about how to version; presumably some monotonically increasing number type. Start with 1.1 for B2G 2.0, the .1 indicating the new additions? Alternately we could use the B2G version, although that could get confusing given that we hopefully will sometimes not change the API for a new B2G version.

* possibly dramatic enough to no longer involve BrowserID

Comment 1

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

I've been wondering the same thing, and I came to the same conclusion as you: Add a .version property to mozId.  So +1 from me :)

I agree that we should not use the B2G release as our index.  That could be confusing, especially if we have no change in functionality between releases but the version number jumps from 2.0 to 3.0, for example.

FWIW, I've always been skeptical of version numbers that say, "only a major revision will cause incompatibilities."  That's not reliably been the case in my experience.  (I think I was scarred for life by a 0.0.1 increment on SVN some years ago that destroyed my entire repo.)  Which is to say that I don't mind monotonically increasing version numbers, like Firefox's.

A common pattern for front-end developers is to test for capabilities, and we don't support that nicely with all the arguments to request() and watch() that keep cropping up.  You would not, for example, be able to tell whether forceAuth was supported.  Maybe it's a crazy idea, but we could have navigator.mozId.capabilities be a dictionary of features and something descriptive (maybe a number?).  navigator.mozId.capabilities.forceAuthentication == '1' or something.  That might be more work for us, but it could be a lot easier on developers.  It could also be a crazy idea.

Comment 2

[Sam Penrose]

I love the capabilities listing; didn't suggest it myself because I am trying to provide a proposal with the smallest possible Surface of Unhappiness and Controversy. If no one else objects, let's do it.

Comment 3

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

> one new optional parameter to watch():
> 
>   {wantIssuer: 'firefox-accounts'}
> 
> and one to request():
> 
>   {refreshAuthentication: i}

We also have the onerror callback in FxA, which is not part of normal browserid.

Comment 4

[Andy McKay]

Maybe relevant, there's a navigator.hasFeature (bug 983502) and getFeature (bug 1009645) API landing, the wiki page is here: https://wiki.mozilla.org/WebAPI/Navigator.hasFeature

Perhaps being able to say (and I'm making things up here): api.window.Navigator.id.refreshAuthentication would be a way to go?

Comment 5

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Having spoken with Sam and callahad, assigning this to me because it dovetails with other efforts to begin to disentangle fxa from persona (which both live in mozId at present).

Comment 6

[(no longer active)]

We usually try really hard to avoid versioning Web APIs and there's usually ways of avoiding that.  Comment 0 doesn't contain enough information for someone not familiar with mozId to figure out why we're considering versioning the API, but given the fact that we seem to want to do a new API (bug 1014077) for this, it would be really great to avoid doing this.

Comment 7

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

But we have an immediate problem that we have to solve for marketplace at the very least.  If you call navigator.mozId on a pre-2.0 phone, you will get persona.  There's no way to test for this.  The wantIssuer property is not supported pre-2.0, and is just ignored if you pass it in.

So unless marketplace wants to inspect the assertion they get back from request() to see whether they got persona or firefox-accounts, we need to offer a way for callers to ask what issuers are supported.

/cc kumar

Comment 8

[(no longer active)]

(In reply to comment #7)
> But we have an immediate problem that we have to solve for marketplace at the
> very least.  If you call navigator.mozId on a pre-2.0 phone, you will get
> persona.  There's no way to test for this.  The wantIssuer property is not
> supported pre-2.0, and is just ignored if you pass it in.
> 
> So unless marketplace wants to inspect the assertion they get back from
> request() to see whether they got persona or firefox-accounts, we need to offer
> a way for callers to ask what issuers are supported.

Are we going to support Persona in any future releases?

Comment 9

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #8)
> 
> Are we going to support Persona in any future releases?

That is an excellent question.  I've not heard otherwise.

But even if we don't, we still have it in 1.4 and all previous phones.  And Marketplace needs a way to know which one it's dealing with.  So I think we still have the problem, don't we?

Comment 10

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Attachment: navigator.mozId.capabilities (PoC for feature detection)

Throwing this out as a strawman.  Possibly a strawman soaked in gasoline.  Bring your own lighter.

This patch exposes a read-only dictionary keyed by the method names supported on navigator.mozId (e.g., watch, request, ...).  The values are dictionaries of the names of supported parameters and their type.

For example,

    navigator.mozId.capabilities.onerror == "function"
    navigator.mozId.capabilities.watch.wantIssuer == "string"

If Marketplace, for instance, were to use this to determine whether it was dealing with a pre-2.0 phone where mozId exposes Persona only, or a 2.0-or-later phone in which mozId exposes either Firefox Accounts or Persona, depending on the issuer you ask for, the usage might be:

    var capabilities = navigator.mozId.capabilities;
    if (capabilities && capabilities.watch.wantIssuer) {
      // we can use firefox accounts    
    } else {
      // wantIssuer param is not supported, so no fxa on this device
    }

Thoughts?

Comment 11

[Sam Penrose]

This meets FxA's needs for FxOS 2.0. Thanks very much Jed.

(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #10)
> Created attachment 8438033 [details] [diff] [review]
> navigator.mozId.capabilities (PoC for feature detection)
> 
> Throwing this out as a strawman.  Possibly a strawman soaked in gasoline. 
> Bring your own lighter.
> 
> This patch exposes a read-only dictionary keyed by the method names
> supported on navigator.mozId (e.g., watch, request, ...).  The values are
> dictionaries of the names of supported parameters and their type.
> 
> For example,
> 
>     navigator.mozId.capabilities.onerror == "function"
>     navigator.mozId.capabilities.watch.wantIssuer == "string"
> 
> If Marketplace, for instance, were to use this to determine whether it was
> dealing with a pre-2.0 phone where mozId exposes Persona only, or a
> 2.0-or-later phone in which mozId exposes either Firefox Accounts or
> Persona, depending on the issuer you ask for, the usage might be:
> 
>     var capabilities = navigator.mozId.capabilities;
>     if (capabilities && capabilities.watch.wantIssuer) {
>       // we can use firefox accounts    
>     } else {
>       // wantIssuer param is not supported, so no fxa on this device
>     }
> 
> Thoughts?

Comment 12

[Andy McKay]

Works for the marketplace, thanks.

Comment 13

[Sam Penrose]

Comment on attachment 8438033 [details] [diff] [review]
navigator.mozId.capabilities (PoC for feature detection)

(Per previous comment)

Comment 14

[(no longer active)]

Comment on attachment 8438033 [details] [diff] [review]
navigator.mozId.capabilities (PoC for feature detection)

Review of attachment 8438033 [details] [diff] [review]:
-----------------------------------------------------------------

No, we should not do this, as we can't change the code that we have already shipped.  If MarketPlace needs to differentiate 1.4, it can use UA detection.

Comment 15

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Andy, will UA detection work for you (per Comment 14)?

Comment 16

[Andy McKay]

(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #15)
> Andy, will UA detection work for you (per Comment 14)?

That was the original plan Sam had proposed, it will work as long as the UA's are different. Just that, you know, UA sniffing is something we ask everyone not to do, its the worst so I was hoping we could get something better.

Comment 17

[Andy McKay]

> No, we should not do this, as we can't change the code that we have already
> shipped.  If MarketPlace needs to differentiate 1.4, it can use UA detection.

Sorry, not sure I understand how jedp proposal changes old code. Isn't it about adding code to 2.0 onwards?

Comment 18

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Ehsan, yes, as Andy says in Comment 17, I wasn't proposing we'd try to make changes to shipped clients; just that starting with 2.0, when Firefox Accounts will first be used, we provide a way for RPs to see that navigator.mozId supports issuing firefox accounts assertions as well as persona assertions.

That's why I had my example code (for an RP) begin with

    var capabilities = navigator.mozId.capabilites || {};

UA detection is a pretty shaky business.  And despite our (Mozilla's) hopes that vendors would not monkey with the strings [1], they've gone ahead and done so anyway [2].  This could easily spiral out of control, leaving a very messy situation.

I would really like to provide a way that Marketplace can know for a fact whether navigator.mozId supports the issuing of firefox accounts assertions.

So how about this.  We add this single property onto navigator.mozId:

    navigator.mozId.otherIssuers = ['firefox-accounts'];

For devices that support only persona, there is no other issuer, so it's fine that this property is undefined.  For version 2.0, we additionally support 'firefox-accounts'.  (And to protect against future awkwardness, we make this a list of strings.)

What do you think?

[1] https://wiki.mozilla.org/B2G/User_Agent/Device_Model_Inclusion_Requirements
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Gecko_user_agent_string_reference#Device-specific_user_agent_strings

Comment 19

[(no longer active)]

My point was that we cannot get this capability API into older versions of our products, so the API will only be available where these new capabilities are available.  This is a good example of why we should never expose APIs in the first place without thinking about their long term implications.  Unfortunately that ship has sailed with navigator.mozId, but at least we can now stop adding ad-hoc things to that API.

Also, the reason that I'm suggesting the use of UA detection here is that it's the lesser of the two evils.  The other proposal of adding this capability API is even worse since it encourages us to keep extending this non-standard API in an ad-hoc manner.  Note that we typically avoid exposing things such as capability levels or API version numbers on the Web by basically ensuring that any API that we expose will remain backwards compatible (IOW we assume that we won't be able to break any API once we expose it to the Web as doing so breaks existing applications that rely on it.)

So my recommendation here is to not do anything in this bug, and try to remove navigator.mozId completely as soon as we can and avoid exposing similar APIs in the future.  How does that sound?