"Diego R. Lopez" wrote:

> ...The sizes seems quite reasonable to be included in the elements we use,
> either by the GET parameters or by SAML queries/responses, as we are defining
> for PAPI version 2. I assume that Policy ACs, in a PERMIS-PAPI model, should
> be loaded once at the (G)PoAs.

That is correct. The Policy AC is loaded at the resource end.


> The idea of using the API internal
> representation can certainly help in saving space/bandwidth.

(and reuse a lot of code to implement a non-AC based authorisation system)


> ...Things are changing, and we are now studying how we can implement trust
> relationshipd among PoAs, GPoAs and AS when we allow for dynamic attribute
> evaluation at the (G)PoA. This dynamic evaluation means a (G)PoA being
> able to ask an AS about certain attributes of the requesting user, so the
> AS must identify the (G)PoA and decide whether it is acceptable to answer
> its queries.

Yes, a non-disclosure policy is a very interesting topic. However, the PERMIS
policy has been primarily designed for Target Access Control. Of course, you could
view the AS as a target when attributes are requested, but then there is no escape
from the loop, unless someone pushes the ACs without using any policy (is not
afraid of disclosure).


> ...This said, the idea of using extensions (I'm just thinking in them like some
> kind of interfaces together with some factory methods returning actual
> implementations

That's correct. Though, certain things are linked too tight (I think, the Policy
Parser is linked to the AC parser directly).


> - pardon me if this sounds too Java-minded) is really
> appealing to make the system as much open and able to interoperate as we
> can.

Can you please enlighten me about the purpose of regularly changing Hcook and
Lcook? Is it because you want to restrict the session length?


Sassa