Hi all,

> 3) When a user action results in the creation of some new resource(s),
> the following rules are applied regarding their associated  policies:
>
> a) if all the input resources have unrestricted publication policy,
> then a policy where everyone can perform GET and only the user running
> the action can perform PUT/DELETE on the newly created resource(s) is
> submitted to the AA service;
>
> b) if one or more of the input resources have restricted publication
> policy, then a policy where only the user running the action can
> perform GET, PUT or DELETE on the newly created resource(s) is
> submitted to the AA service.

This dichotomy into two base classes seems like a good idea to me, 
because it helps in unifying the access rights architecture.
It will still have to prove its potential in actual use cases, though. 
On the one hand, it might be too conservative to be of any actual help, 
on the other hand it seems to me there is in general not much auxiliary 
information available. The automatic incorporation of restrictions of 
input components to the output component is in general hindered by the 
fact that the creator might not be the owner of an input resource URI 
and thus in general can not inspect the input component's policy...

> 4) Users can change the AA service policies they own. In particular
> they can grant GET access to some restricted resource, created by
> themselves, to more users. When they perform this action, they should
> confirm that they are aware of the license of the restricted resource
> and that the modified AA policy would be in compliance with this
> license, thus bearing the full responsibility for this access grant.
>
> We’ve also identified the following additional issues to be further
> discussed and decided upon:
>
> i) From security perspective it would be preferable to allow only
> hosting services to request policy creation or modification for
> resources they host. This would require some additions to the API in
> order to support scenarios like the one mentioned in point (4), where
> a client would ask the hosting service to modify an existing policy in
> the AA service on his behalf. In addition, the AA service should
> enforce the restriction that only a hosting service is allowed to
> create/modify policies for the resources it hosts, provided that it
> presents a valid token. The hosting service would take care to
> maintain the resource publication policy and the associated AA policy
> in sync.

That would boil down to IP checks, I guess? Unfortunately, it is not 
trivial for me since the SSO machine resides in a private subnet 
accessed by NAT and thus can not see the policy service accessing 
machines IP. I might however discuss with Christoph to change that, if 
necessary.

> ii) There are various means to attempt ensuring that the user has seen
> the license agreement and confirmed that he is granting access to a
> given resource in compliance with the involved license(s) – e.g. some
> challenge/response, e-mail confirmation, electronic signature, etc. In
> the case of a user behind a web browser it is relatively easy to
> present the license text and a confirmation button. In all other cases
> the solution would be rather more complicated and inherently insecure
> if it doesn’t rely on electronic signatures. However, introducing
> electronic signatures for this purpose might be perceived as
> undesirable complication…

This might be used to address the first issue described above- the task 
of transferring input restrictions would be up to the human end user. A 
good idea IMHO.

Kind regards
Andreas

-- 
http://www.maunz.de

       They told me to install Windows ME or better, so I installed Linux.