Reconsider mandatory items in OAuth2

[mmccool]

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...)

[mmccool]

Comments:

• 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

[mmccool]

Logistics challenges:

• Making something optional that is currently mandatory would break backward compatibility
• We could make the NEW schemes with optional elements and leave the old ones alone, but that would be weird and inconsistent

Proposed Plan:

• Make the new schemes have mandatory elements consistent with the existing scheme
• Monitor use cases and see if there are any where optional elements would be useful (look for people using made-up auth URLs, for instance)
• Re-consider making these elements optional in the TD 2.0 spec after further discussion.