Sorry for the late answer. Was musing in the french subforum 
I think we've all followed a kind of implicit norm by reusing the same "/callback" uri but the protocol does not state any such rule.
EDIT: Here is an example of a different callback uri used in my 2FA demo (uses a "/tfa_activation_callback" uri)
Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.
Ooops. That sounds like a more serious issue.
On its side, BitID protocol does not state any specific order for the parameters.
Main problem is that such a rule would have a direct impact for wallets developers.
Thus, I think it's better if Eric answers this point.
I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json.
Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.
The uris "/callback" can be something else. The client should only rely on what it has received in the bitid_uri.I think we've all followed a kind of implicit norm by reusing the same "/callback" uri but the protocol does not state any such rule.
EDIT: Here is an example of a different callback uri used in my 2FA demo (uses a "/tfa_activation_callback" uri)
Quote
Parameters:
uri : string - required - bitid uri used as the challenge
signature : string - required - signature of the bitid uri
address : string - required - address used for authentication
uri : string - required - bitid uri used as the challenge
signature : string - required - signature of the bitid uri
address : string - required - address used for authentication
Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.
On its side, BitID protocol does not state any specific order for the parameters.
Main problem is that such a rule would have a direct impact for wallets developers.
Thus, I think it's better if Eric answers this point.
I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json.