Confirmed users
471
edits
Identity/FormatUpgrade: Difference between revisions
Jump to navigation
Jump to search
→Recipient-Advertisements
(more text) |
|||
| Line 53: | Line 53: | ||
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). | 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 ... | Backing all the way up to the IdP's /.well-known/browserid advertisement, it might be useful for the browser and/or RPs to fetch different URLs from the IdP depending upon what versions they are capable of handling, or using some <tt>Accept:</tt> header negotiation to ask for different versions. Some changes won't require this (e.g. if clients will ignore any keys that they can't parse, then the IdP could publish both new- and old- format keys, and know that old clients will safely ignore the new ones), but others (like publishing multiple keys at all, rather than a single key) may need to be hidden from older clients altogether. | ||