> I disagree. Voiding a token to stop supporting an algorithm is > perfectly reasonable and might not even require user involvement if the > refresh mechanism is (adopted and) used. And if the reason for this is > a broken algorithm, well, I would hope the tokens are voided, not just > used with the same secret and new algorithm.
Migrating to new algorithms is a very slow and tortuous process -- partly because an algorithm is rarely completely broken in a single instant. Even MD5 is still safe for some purposes. Binding secrets to hash algorithms in the protocol (not just as a choice by one server) will make migrations that much harder. > I am not sure what you mean by "one app may only support SHA-1, while > another only supports SHA-256". Are you suggesting something like a > company with centralized token service but where each service using a > different set of algorithm, but still sharing the same token across > services? Sounds like a company in need of new management. That is exactly what I am suggesting. Old apps, new apps, outsourced apps, legacy apps, white-label apps rebadged, app in this language, app in that language, apps in the cloud, apps from a merger... There is no way I expect perfect consistency in supported algorithms, but I do want to try to have SSO across these apps and a central token service for accessing their APIs. I don't want to have to upgrade every single app (even the niche near end-of-life ones) to support a new algorithm before I can start using it anywhere. If a credential bound to a new algorithm is issued to a client, that client can no longer access apps that have not been upgraded -- or, worst still, the client is expected to manage multiple app-specific credentials where previously they used one. > > Breaking the existing model of HTTP authentication (1 scheme per > > mechanism) is the wrong approach. > > Not sure what you mean. In most HTTP authentication mechanisms, knowing the scheme is sufficient to know the sort of credential required, the security properties, and if you have the code to support it. With Token, the credentials might be just a token, a token and shared secret, or a token and asymmetric key. With Token, you may or may not be safe from passive attacks, or active attacks; may or may not require lower-layer security; might have to do computationally-intensive public-key crypto or might only require trivial copy 'n paste. You have broken the model where the scheme means something about the type of credential and the security. -- James Manger
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
