Subject: [Ace] oauth-authz: Introspection endpoint method

From: Christian Amsüss <[email-masked]>
Date: Mon, 16 Nov 2020 08:59:15 +0100

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

---

From: Seitz Ludwig <[email-masked]>
Date: Mon, 16 Nov 2020 12:33:54 +0000

Hi Christian,

The short answer is:

We aligned as close as possible with OAuth 2.0, and there Introspection uses POST.

/Ludwig

> -----Original Message-----
> From: Christian Amsüss <[email-masked]>
> Sent: den 16 november 2020 08:59
> To: [email-masked]; draft-tiloca-ace-revoked-token-
> [email-masked]; [email-masked]
> Subject: [EXTERNAL] oauth-authz: Introspection endpoint method
> 
> 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).
> 
> --