Confirmed users
471
edits
Identity/FormatUpgrade: Difference between revisions
Jump to navigation
Jump to search
more text
(more text) |
|||
| Line 46: | Line 46: | ||
=== Recipient-Advertisements === | === 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 ... | |||