1. If the identity provider tries to present different views of the username-to-public-key mapping to different parties, then there will be publicly verifiable evidence of misbehavior (or the different views must be maintained indefinitely). Also, if a malicious identity provider tries to distribute an attacker-chosen public key for a user, then the user’s client can detect this and report misbehavior. For privacy, an attacker cannot learn information about other usernames or public keys present in the system via consistency proofs, and can only learn an upper bound on the number of users in the system (based on the number of added “dummy entries”).

2. When Bob is offline, the identity provider could change his public key. Bob would not immediately detect this (because he is offline), and other users could look up the incorrect public key for Bob. However, when Bob comes back online, he can see that this attack took place and report it. (Optional note: if Bob uses the default key update policy, the identity provider can change Bob’s key to any arbitrary key. If he uses the strict key update policy, then the identity provider can only set Bob’s public key to an old public key value, provided that the identity provider has not compromised Bob’s secret key.)