Not in academic terms, no. tl;dr IBE refers to a specific process of mathematically using identifying data as a public key like a phone number or email. As alw

Not in academic terms, no. tl;dr IBE refers to a specific process of mathematically using identifying data as a public key like a phone number or email. As always with cryptography you have a key exchange/identity binding problem: if you receive my public key, how do you know it actually came from me? There are a few solutions to this problem: 1. Certificate authorities do an ID check (domain or extended validation). You know the cert is valid because (in theory) the CA doesn't sign unless it too is convinced and you trust them to do a good job (there's a whole history of CA issues and implementation problems I won't discuss further here - this is by and large the concept). 2. Web-of-Trust/Keybase - the valid key is signed by enough other people you trust / signs enough other public statements from accounts you trust you don't think MITM can happen. 3. Compare hashes (fingerprints) - OTR, OMEMO, Signal, WhatsApp, ZRTP et al. You have the right key because you trust the digest function. 4. Authenticated Key Exchange e.g. PAKE, SPAKE, NAXOS etc. IBE solves the key exchange problem a different way - what if your public key was some identifiable piece of information (not necessarily biometric as others have suggested, but) e.g. an email address or telephone number? To realise this you need a key management server to go from these public keys to a private key, via a protected master secret and other global parameters, see https://crypto.stanford.edu/~dabo/papers/bfibe.pdf https://crypto.stanford.edu/~dabo/papers/bfibe.pdf , https://crypto.stanford.edu/~xb/ab09/latticeibe.pdf https://crypto.stanford.edu/~xb/ab09/latticeibe.pdf, https://eprint.iacr.org/2014/794.pdf https://eprint.iacr.org/2014/794.pdf for example (Boneh's was the first discovered IBE scheme). In this system, you transform the identity piece of data into a public key and only the user in possession of the private key from the master authority/key management server should be able to decrypt it, assuming they global domain parameters are trusted. The advantage here is that assuming, for example, you work in a government department and have a government supplied telephone you do not also need to verify key material for the user at the other end - you can derive an appropriate public key simply by typing in their telephone number, which you do when you initiate a call. Users no longer need to think about key material or activating "secure mode" or whatever might be required to make an encrypted telephone function. So far as I know at least the UK's GCHQ are keen: https://www.ncsc.gov.uk/articles/using-mikey-sakke-building-secure-multimedia-services https://www.ncsc.gov.uk/articles/using-mikey-sakke-building-... but their scheme has been criticised: https://www.benthamsgaze.org/2016/01/19/insecure-by-design-protocols-for-encrypted-phone-calls/ https://www.benthamsgaze.org/2016/01/19/insecure-by-design-p... The downside from everyone else's point of view is that the key management server / master authority can derive private keys for all users of the system. The article mentions certificate-less cryptography as a potential solution, however, you need to distribute (the non-IBE) part of the key, bringing you back to 1-4 above.