Remove redundant normative language about draft-dpop HOT 7 CLOSED

Note:

If the access token response contains a different `token_type` value than `DPoP` in the response, the
access token protection provided by DPoP is not given.
In this case, if this protection is deemed important for the security of the
application, the client MUST discard the response and MAY continue as in a regular OAuth interaction otherwise.

Is that interoperable?

from draft-dpop.

Note:

The second sentence there is pretty awkward and should be reworded.

from draft-dpop.

There are some requirements that folks have specifically asked to be repeated for pragmatic and reasonable reasons (#106 being a recent one). That is to say that a lot of what is in the document is there for some reason or another. If there's specific redundant language that you believe is problematic, please raise such instances for discussion. But I'm reluctant to make changes at this point that might undo content that has been requested.

from draft-dpop.

There are some requirements that folks have specifically asked to be repeated

My personal view is that, in a specification, repeating requirements increases the probability of introducing inconsistencies.

I will PR specific points though :)

from draft-dpop.

I'm of course aware that repeating requirements increases the probability of inconsistencies. But that is but one consideration and reality is messy - six fricking co-authors on a draft developed over years trying to capture (rough) consensus on a topic about which there are many opinions is messy. Trying to introduce substantial changes, regardless of the quality of the intent, at this point in the doc lifecycle also introduce risk of introducing inconsistencies or other issues as well as risk of inadvertently undoing things that are there for legitimate reason.

from draft-dpop.

I understand: the Digest work is lasting years, and while it started with a simple rewriting of an existing spec, it now introduces 4 new fields, deprecated 2 and relies on structured fields thus making the syntax of the new fields not compatible with the old ones :P

Sadly I still need some time to address each point separately.

from draft-dpop.

I have no doubt the Digest work has been frustrating.

I'm aiming to keep this draft moving forward by avoiding unneeded changes.

from draft-dpop.