[Ace] oauth-authz: Introspection endpoint method

[Christian Amsüss <[e-mail]>]

Hello ACE-OAuth authors, authors of revoked-token-notifcation, and ACE
group in general,

while trying to understand the necessity for revoked-token-notification,
I was looking into the introspection parts of ACE
(draft-ietf-ace-oauth-authz-35 Section 5.7.1) and was confused at the
method used there:


Given the introspection endpoint is used for querying, why is it using
the POST method? This indicates that the request may not be safe (in
REST terminology), which seems not the case.


This would have the nice properties of indicating its safeness to the
rest of the stack (ie. the CoAP library can forego request
deduplication). Also, it'd keep the door open for caching (where
obviously `exi` would be inapplicable, but `Max-Age: ...` would be used
instead), and observing a particular introspection would be possible.
This sure wouldn't make revoked- obsolete, but I think it'd make the
path there smoother, and help sharpen what the TRL adds.

If there's no particular reason to keep POST and it's early enough for
such a change, the change to the document would be minimal, and unless
any implementation is built on a CoAP stack without support for RFC8132,
changes there should be trivial.

Best regards
Christian


Bycatch: The example in figure 13/14, the Uri-Path should probably be in
Figure 14 instead, along with the inner code (which is suggested to
change above). Given figure 15 is shown as the full protected message,
the same format may work well for a single figure 13/14 as well (with
just a note that this is an encrypted exchange).

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom