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
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
