Confirmed users
471
edits
Identity/FormatUpgrade: Difference between revisions
Jump to navigation
Jump to search
→Dependencies
| Line 27: | Line 27: | ||
The browser signs an assertion (also with format "C" to match the certificate it was given) and delivers both to the RP. | The browser signs an assertion (also with format "C" to match the certificate it was given) and delivers both to the RP. | ||
== | == Solutions == | ||
=== Time-Based === | |||
The easiest approach (albeit not the one most likely to succeed) is to make time-based assumptions about which formats will be accepted by everybody. In this scheme, we tell all implementors (IdPs, browsers, and RPs) to either use our hosted services (for which we take the responsibility of keeping up-to-date), or that they'll have some window (maybe 6 months) to get their own code up-to-date. For example, if we define our current formats as "V1", then the rollout timeline for "V2" would look like: | |||
* Jan-2013: we publish the specifications for "V2", with sample implementations. We begin modifying the hosted services to accept both V1 and V2, but only emit V1. We tell all implementors to start working on V2 tolerance. | |||
* June-2013: we expect that all implementations are now V1+V2-tolerant | |||
* July-2013: we modify hosted services to unconditionally emit V2. We tell all other implementors to change their code to emit V2. | |||
* Dec-2013: we expect that no implementations are emitting V1 messages | |||
* Jan-2014: it is now safe for implementations to remove V1 tolerance | |||
Naturally development of V3 can proceed in parallel with the shutdown of the V1 code, so July-2013 would also see the start of V3 work, and V3 could be switched on in Jan-2014. | |||
Pros: fairly simple, no additional messages need to be passed. Implementations only need to tolerate 2 simultaneous versions. | |||
Cons: laggards will probably cause breakage, and the true source of the problem may be hard to track down. | |||
=== Recipient-Advertisements === | |||