Currently the OAuth2 scheme in the TD spec makes certain items mandatory, i.e. the authorization or token server URLs.
But these are also provided by the protocol, and may in fact vary. If we "bake" them into the TD there is the chance that they will become obsolete. In other cases they might be a useful check.
So the question is, should these items really be mandatory, and if they are provided, should it be an error if the device provides something different? Note that generally (and there is an assertion for this) if the device provides something different the assumption is that the TD is wrong, e.g. it is not considered authoritative. But for security, especially if signed, making it authoritative may be useful in some cases. Or not (the actual OAuth2 spec has gotten better review, so...)
If there is one use case where authorization server from device may be different from the device, then it should be optional
Still want to make it highly recommended to include if possible
Even if auth server in TD is wrong, worst case is that the device will return an error when given an incorrect token and will return a link to the (correct) authentication server
Updating the authentication server requires updating the TD, which complicates discovery (caching). However this should be pretty infrequent.
Advantage of having the auth server in the TD is the consumer can get tokens in advance
Currently the OAuth2 scheme in the TD spec makes certain items mandatory, i.e. the authorization or token server URLs. But these are also provided by the protocol, and may in fact vary. If we "bake" them into the TD there is the chance that they will become obsolete. In other cases they might be a useful check. So the question is, should these items really be mandatory, and if they are provided, should it be an error if the device provides something different? Note that generally (and there is an assertion for this) if the device provides something different the assumption is that the TD is wrong, e.g. it is not considered authoritative. But for security, especially if signed, making it authoritative may be useful in some cases. Or not (the actual OAuth2 spec has gotten better review, so...)