"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
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 you please enlighten me about the purpose of regularly changing Hcook and
Lcook? Is it because you want to restrict the session length?