Standard parameters for Boneh–Lynn–Shacham signature? The Boneh–Lynn–Shacham signature is (as far as I know) unrivaled in compactness, promising $b$-bit security for $2b$-bit signature (perhaps: asymptotically).

Are there standard parameters for BLS signature, (being?) defined by standard bodies, security authorities, or other recognized authority; or otherwise common/recommended?

In particular, is there something with a size recommendation, perhaps in ISO/IEC&nbsp;15946-5: Information technology - Security techniques - Cryptographic techniques based on elliptic curves - Part 5: Elliptic curve generation?

What does the state of the art ([BD 2019] I guess) implies about the size of BLS signature for $b$-bit security, for practical $b$ like 128?



Some references (now dated except the last two) :

[BLS 2004]: Dan Boneh, Ben Lynn, Hovav Shacham, Short Signatures from the Weil Pairing, in Journal of Cryptology, 2004 (originally [BLS2001] is proceedings of Asiacrypt 2001).

[BN 2005]: Paulo S. L. M. Barreto, Michael Naehrig, Pairing-Friendly Elliptic Curves of Prime Order, in proceedings of SAC 2005; slides.

[SSS 2006]: Mike Scott, Hovav Shacham, Terence Spies, P1363 presentation of 2006/10.

[NNS 2010]: Michael Naehrig, Ruben Niederhagen, Peter Schwabe, New software speed records for cryptographic pairings, in proceedings of Latincrypt 2010; software linked at referring page.

[ABLR 2013]: Diego F. Aranha, Paulo S. L. M. Barreto, Patrick Longa, Jefferson E. Ricardini, The Realm of the Pairings, in proceedings of SAC2013, with slides (reporting actual use since 2002).

[KB 2016]: Taechan Kim, Razvan Barbulescu, Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case, [KB16] in proceedings of Crypto 2016, originally [K 2015] of October 2015 and [B 2015] of November 2015.

[BD 2019]: Razvan Barbulescu, Sylvain  Duquesne, Updating key size estimations for pairings, in Journal of Cryptology, October 2019
Well, the Boneh-Lynn-Shacham "BLS" signature scheme is currently in the process of being standardized through an Internet Draft named "draft-irtf-cfrg-bls-signature-00" (a working document of the Internet Engineering Task Force "IETF"), which you can track here. It appears Algorand might be behind this process, along with Dan Boneh's own support.

As stated in there:


  There are two variants of the scheme:
  
  
  (minimizing signature size) Put signatures in G1 and public keys
     in G2, where G1/E1 has the more compact representation.  For
     instance, when instantiated with the pairing-friendly curve
     BLS12-381, this yields signature size of 48 bytes, whereas the
     ECDSA signature over curve25519 has a signature size of 64 byes.
  (minimizing public key size) Put public keys in G1 and signatures
     in G2.  This latter case comes up when we do signature
     aggregation, where most of the communication costs come from
     public keys.  This is particularly relevant in applications such
     as blockchains and compressing certificate chains, where the goal
     is to minimize the total size of multiple public keys and
     aggregated signatures.
  


While they do not (yet) specify explicit parameters that are to be used, they do refer to the Internet Draft "Pairing Friendly Curves", which in turn has multiple recommendations depending on the level of security you want to reach. 
Regarding the above quote, it notably lists BLS12-381 in the recommendation to have 128 bits of security.

Also, when compared with ECDSA, they mention that (emphasize mine):


  The following comparison assumes BLS signatures with curve BLS12-381,
  targeting 128 bits security.
  [...]
     In terms of sizes, ECDSA uses 32 bytes for public keys and 64 bytes
  for signatures; while BLS uses 96 bytes for public keys, and 48 bytes
  for signatures.  Alternatively, BLS can also be instantiated with 48
  bytes of public keys and 96 bytes of signatures.  BLS also allows for
  signature compression.  In other words, a single signature is
  sufficient to anthenticate multiple messages and public keys.


So it appears that the current "standard" is to have ~384 bits of signature to reach 128 bits of security, which means having $3b$ bits signatures for $b$ bits of security. (BN curves having "lost" favors, as Bristol said already and their current 128 bits contender being BN462.)

Also, notice this is a working document, and as such is not complete. For instance it is missing things that are yet to be added:


  TBA: additional discussion on this, e.g.  [Ristenpart-Yilek 06], and alternative mechanisms for securing aggregation against rogue key attacks, e.g.  [Boneh-Drijvers-Neven 18]; there, pre-processing public keys would speed up verification.


And the rogue key attack is typically something important to defend against in the case where we want to have aggregate signatures, which is one of the nice features of BLS.

Notice that in pairing based crypto we had to move significantly our security estimates within the last 3 years most notably because of the advances in the FFDLP (see [KB16]), with your latest reference [BD 2019], being the current state of the art regarding security estimates and recommendations. 

So it might still take a while until the above-mentioned IETF draft is finished and becomes an actual "standard", but this is in process.