Hi all,
   Let me mention that we can use the DC property dc:rights (see
http://dublincore.org/documents/usageguide/elements.shtml#rights ) to
include human readable information regarding licenses (plain text or a
URI) related to the resource.

Best regards,
Pantelis

On Fri, 2011-01-07 at 18:45 +0200, Vedrin Jeliazkov wrote:

> 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:
> y



> 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
> >
> >
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>