[Ace] AIF extending models vs. composite scopes

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

Hello AIF experts and ACE group,

looking into AIF (in particular the REST-specific model) for use on
embedded (RIOT OS based) systems, there are properties I'd like to
express additional properties in a token, eg:

a. "When responses are sent to a client authorized with this token, the
   server may place non-confidential but possibly attack relevant data in
   problem-details."

   (Like, stack traces with program counters and/or line numbers, not the
   content of the stack).

b. "Under memory load, evict state from this token last."

   (In particular, a server may have an LRU cache of OSCORE/EDHOC
   contexts, but this context will only be evicted from there by another
   context established from a token with the same authorization).

There are two approaches I see that would still retain usability with
AIF:

1. Wrap the AIF and some indicators for the extra data in some kind of
   "bag" structure.

2. Extend AIF such that a structure like this is permissible:

   [["/s/temp", 1/GET/], ["/a/led", 5/GET|PUT/],
    [CPA12345(null)/access error details/, true]]

3. Make up resources that represent the permissions. This is kind of
   viable for the error case (when assigning error instances a la
   /err/0001, permission to read through the indirection can imply
   permission to get it served directly), but I wouldn't know how to
   explain this for use case b.

All have in common that an AS that is unaware of the extra features can
still deal out the regular authorizations; 3 is even easy to add to any
AS that supports regular AIF.

Is any of those patterns already established, or has been explored in
parts?

Thanks
Christian

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