Hi Folks,

Here is a summary of an alternative solution, that we discussed
yesterday and today with Nina, Pantelis, Luchesar and Tobias:

1) We propose to define a new “Publication policy” attribute, stored
in each OT resource. This attribute could take two values:

a) unrestricted (meaning that all users are allowed to perform a GET
request and retrieve the resource);

b) restricted (only some subset of users (not specified here) are
allowed to perform a GET request and retrieve the resource).

Please note that the publication policy is defined in the resource
itself and doesn’t require any changes in the AA service.

2) We propose to define a new “License” attribute for each OT
resource, initialized with a pointer (URI) to the human readable text
of the license of the corresponding resource. This attribute must be
initialized for all restricted resources and could be initialized
optionally for unrestricted resources as well.

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.

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.

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…

Kind regards,
Vedrin

On 5 January 2011 16:21, chung <chvng at mail.ntua.gr> wrote:
> Hi All,
>   I attach the message as pdf and doc.
>
> Best Regards,
> Pantelis
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>
>