So this is to follow up on my discuss point#2, which said: (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there.
In -28 you added a bit of text to 3.2.1. saying: "The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered "token_endpoint_auth_method" is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider." That new text may be fine, but I'd like to check that I understand it correctly and that it addresses the issue sensibly. Say I'm a developer who writes and distributes a client that uses this and I test it with the BIGreg.example.com registration endpoint and it works, but for my application to work I need a specific token_endpoint_auth_method, say client_secret_basic. Say time passes, and we discover that client_secret_basic is bad for some reason and client_secret_supergood is invented and gets used a lot. At that point BIGreg.example.com would like to turn off the (now-crappy) client_secret_basic and only allow use of client_secret_supergood. If it does that, then new installs of our application will fail at registration time with an (opaque) error to the human user and we need the application developer to do an update to add client_secret_supergood. Or, what seems more likely is that BIGreg.example.com will have to keep offering the now insecure client_secret_basic until essentially no interesting applications remain that don't support the new, better thing. And that's the bit I don't like so much. This spec could (maybe, I'm not 100% sure) have been written to allow for the client and registration endpoint to first try to use the new better things and, if that doesn't work, to try fallback to the old not so good things, but that is not supported here afaics - once the client sees response metadata it doesn't like, there's no way for the client to say "bummer, I'd have been fine if only you'd said foo and not bar, can we try register again and use foo?" And I also don't see how the client who is really stuck can tell the registration endpoint "actually, I'm not successfully registered because your said bar and I don't like that bit of metadata" - won't that lead to our BIGreg.example.com ending up with a misleading picture of what clients were successfully registered? So my question is: is all that really ok, or am I confused in the above? (And confused is quite possible - this is OAuth after all:-) Cheers, S. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
