You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm thinking how to handle ID migration. E.g. you use the header Signature-Agent: x="https://bot.example/.well-known/..." but then the keys move for some reason to something.example/jwks.json. If you simply update the header to the new address then all the allowlists/denylists/reputation accrued on the web becomes invalid.
Linking the old json from the new one so that verifiers know that it is a successor of the old one
Co-signing with both keys for a period of time
It becomes more tricky when the migration is not 1:1 but bots split or merge.
A related broader issue here is that the protocol could signify many things (e.g. I'm moving the bot's identity from a.com to b.com) but there is no way to test what the ecosystem does with the signal. During my experiments with WBA it was very hard to even know how websites react to these headers (is the new header going to break a bunch of sites? do they recognize the header? do they parse it correctly? did they adopt #71? if parsing fails, do they fall back to IP verification? do they treat IP and WBA the same way?)
This makes any type of migration very costly.
Maybe something like the web platform tests could help here, but things like "does the reputation carry over" will be very hard to test because providers might not want to share reputation signals back to the client.
I'm thinking how to handle ID migration. E.g. you use the header
Signature-Agent: x="https://bot.example/.well-known/..."but then the keys move for some reason tosomething.example/jwks.json. If you simply update the header to the new address then all the allowlists/denylists/reputation accrued on the web becomes invalid.Some components of a solution could be
It becomes more tricky when the migration is not 1:1 but bots split or merge.
A related broader issue here is that the protocol could signify many things (e.g. I'm moving the bot's identity from a.com to b.com) but there is no way to test what the ecosystem does with the signal. During my experiments with WBA it was very hard to even know how websites react to these headers (is the new header going to break a bunch of sites? do they recognize the header? do they parse it correctly? did they adopt #71? if parsing fails, do they fall back to IP verification? do they treat IP and WBA the same way?)
This makes any type of migration very costly.
Maybe something like the web platform tests could help here, but things like "does the reputation carry over" will be very hard to test because providers might not want to share reputation signals back to the client.