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
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
