Confirm
471
edits
Changes
→Format-Upgrade Analysis
[[File:Format-upgrade.png|BrowserID data flow diagram]]
== Recipients ==
There are three bits of code that receive serialized messages (and must understand them for everything to work). The first is the IdP provisioning backend which creates signed certificates, labeled "Step 1". This must understand the browser's pubkey format ("B"). The secondary/fallback-IdP has the same requirements.
The second ("Step 2") is the browser's assertion-signing code, which needs to parse the signed certificate ("C") to learn when it expires (at which point it must go back to the IdP for a new certificate.
The third is the RP's verifier ("Step 3"), either the online service that we run, or a local implementation that does not depend upon verifier.login.persona.org . The verifier will fetch the IdP's pubkey from the IdP, so it must be able to parse the IdP's key ("A"), as well as the browser's pubkey ("B"), the signed certificate ("C"), and the signed assertion. Both the assertion and the certificate are labeled "C", because the current jwcrypto implementation requires both to use the same format/version.
== Generators ==
Those recipients consume messages that are generated in several places:
The IdP's pubkey "A" is served from the IdP's /.well-known/browserid file. The GET request which fetches it does not currently have a way to indicate what version of key is desired.
The browser's pubkey "B" is generated about once a day and delivered to the provisioning frame for certification.
The IdP's provisioning backend creates a signed certificate that delegates control over a specific email address to the browser's pubkey. This certificate is serialized with a specific format ("C") and returned to the browser via the provisioning frame.
The browser signs an assertion (also with format "C" to match the certificate it was given) and delivers both to the RP.
== Dependencies ==
