Confirm
471
edits
Changes
more text
=== Recipient-Advertisements ===
A more robust (but more difficult) approach is to somehow allow the creator of each message be aware of the abilities of all potential recipients.
For example, the RP might advertise which versions they can tolerate via an extra argument to the <tt>navigator.id.request()</tt> call. If the RP does not signal tolerance of the V2 format, then the browser (in Step 2) must create a V1-format assertion. It needs a V1-format certificate to do that, which may require going back to the IdP for a new (old-format) cert. It may also require creating a V1-format pubkey B. Finally, it requires the IdP to publish a V1-format pubkey A (in addition to the V2-format one it publishes for newer RPs).
Similarly, if the browser is not yet V2-capable, it needs the IdP's certificate (generated in Step 1) to be V1-format. It would most likely signal this by handing a V1-format pubkey B to the provisioning frame, and the IdP's backend code would stick to using V1-format certificates. (this is not actually sufficient for the general case, since the pubkey format can evolve independently from the certificate format).
Backing all the way up to the IdP's /.well-known/browserid advertisement, it ...
