Rights Expression Language (REL) for Activity/Streams/Pub?

I believe that a number of frequently discussed issues with AS2 could be
resolved by supporting a Rights Expression Language (REL) such as the W3C's
ODRL. (see: ODRL's Data Model <https://www.w3.org/TR/odrl-model/> and
Vocabulary <https://www.w3.org/TR/odrl-vocab/>) Some of these oft-mentioned
issues include:

   - Granting permissions for use (e.g. Creative Commons or inclusion in
   search-engine results)
   - Preventing replies to posts
   - Delegating account activity rights to others. (i.e. on-behalf-of,
   shared-moderation, etc.)

Note: Some, on reading what follows, will complain that what I'm suggesting
is burdensome. I suggest a simple rule: *If some software receives an
object containing rights language that it doesn't understand, it should
simply assume that it has no rights other than those provided by law.* The
intent here is to support granting rights that would otherwise be withheld,
since, in most jurisdictions, *all rights are reserved* to the content
creator.

Also, my intent here is not to make a concrete proposal, but rather to
spark conversation that, if folk are interested, might eventually lead to
an actual draft proposal. Similar, but more focused issues are being
discussed individually in each of FEP-5624
<https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/32>
re:
Per-object reply control policies, FEP-c118
<https://socialhub.activitypub.rocks/t/fep-c118-content-licensing-support/2903>
re:
Content licensing support], and FEP-8c3f
<https://socialhub.activitypub.rocks/t/fep-8c3f-web-monetization/2719> re:
Web Monetization.

Granting Permissions

Some people will want their content to be entirely in the public domain,
others won't. Some will want to restrict the use of their content to
non-commercial purposes, others would be willing to allow some, but not all
commercial use. Some will require attribution when granted rights are used.

While individual content creators must be the ultimate authorities on what
rights they grant to others, expressing rights can be a pain and won't be
something that everyone wants to spend much time doing. Additionally, it is
likely that some instance operators will want to declare that the content
they host is open, by default, while other operators will prefer more less
generous defaults. (Federation allows not only diversity of
instance-specific moderation, but also diversity of instance-specific
default rights.) But, even if an instance's default rights are restrictive,
individual creators using that instance should be able to override the
defaults and grant more generous rights. Thus, it is probably necessary and
appropriate that rights expressions should be capable of being attached to
any of, at least:

   - An entire instance (as instance-wide defaults)
   - Any collection served by the instance (Outbox, Local TimeLine, etc.)
   - Any individual object (Note, Question, etc.)
   - A specific copy of an object (i.e. To allow granting rights to
   specific individuals -- such as the right to reproduce an image in a named
   publication after having received a royalty or other payment.)

Given the considerations above, a Note with associated permissions might
look like the following if a profile drawing from ODRL and Creative Commons
was included in the @context. In this case, the intent of the author is to
leverage the existing, and well-known, Creative Commons
Attribution-ShareAlike 4.0 International License. (I expect that most users
will be happy with referencing such pre-defined bundles of rights.)

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "http://example.com/ns/profile.jsonld"
  ],
  "type": "Note",
  "id": "https://example.com/8affd0ff50ffc6bc9669c31",
  "content": "This is a short note.",
  "permission": [
    {
      "action": ["cc-by-sa/4.0/"]
    }
  ]}

Of course, some authors will want more fine-grained control over their
grants. A common need will be to indicate the desired form of attribution
rather than leaving others to guess what might be correct. Some authors may
also wish to provide links to the legal text (code) of the license and some
"professional" authors will want to link to a resource that describes some
out-of-band process for obtaining more than the initially granted rights.
And, finally, some who like most of what's in some pre-bundled license will
still want to amend it by withholding some rights otherwise granted by that
bundle. (e.g. The rights for long-term Archiving or for inclusion full-text
search services are often mentioned by existing users.)

Given these considerations, a more detailed rights expression, drawing on
both Creative Commons and ODRL, might look like the following:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               "http://example.com/ns/profile.jsonld",],
   "type": "Note",
   "id": "https://example.com/8affd06cf9e9ff50ffc6bc9669c31",
   "content": "This is a short note.",
   "permission": [{
        "action" : ["cc-by-sa/4.0/"],
        "attribution": {
            "cc:attributionName": "Bob Wyman",
            "cc:attributionURL": "https://example.com/bob",
            "dct:title": "A note from Bob"
          },
         "cc:legalCode": "http://creativecommons.org/licenses/by-sa/4.0/",
         "cc:morePermissions": "https//example.com/more",
    }],
    "prohibition": [{
        "action": ["Archive", "Index"],
    }]},

Clearly, this second example is more complicated than the first, but that
complexity seems necessary in order to express the author's intent.
Nonetheless, some limits on complexity are probable necessary. So, it would
be good to develop a profile of ODRL that carefully selects those features
whose general specification makes sense. My assumption is that 100% of what
is supported by Creative Commons should also be supported here.
Limiting the Right to Reply

Just as a REL can be used to describe what may be done with copies of an
object, that same language can be used to grant, or withhold, the right to
perform AS2 actions that would modify the object or its presentation. For
instance, one can argue that in many systems replies modify a Note's
presentation. As such, it can be further argued that an author should have
the right to permit, or not permit, others' ability to modify content's
presentation by replying. It would also be reasonable to be able to allow
some, but not all others, to reply. (e.g. Permit only one's followers to
reply.)

A simple use of REL to say "No Replies" might thus look like this:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               "http://example.com/ns/profile.jsonld",],
   "type": "Note",
   "id": "https://example.com/8affd06cf9e9ff50ffc6bc9669c31",
   "content": "Don't reply to this!",
    "prohibition": [{
        "action": ["Reply"],
    }]},

An assignment to one's followers of an exclusive right to reply might look
like this:

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               "http://example.com/ns/profile.jsonld",],
   "type": "Note",
   "id": "https://example.com/8affd06cf9e9ff50ffc6bc9669c31",
   "content": "Only my followers can reply to this.",
    "permission": [{
        "action": ["Reply"],
        "assignee": "Followers",
    }]},

Delegation of Account Activities to others

Sometimes, people go on vacation, to hospital, to prison, or wherever, and
yet they wish for their social account(s) to be monitored and otherwise
maintained while they are out-of-action. Sometimes, an organization will
have an "official" account which is managed by a changing set of
individuals.

Ideally, one would be able to delegate at least some account operation
capabilities to others either permanently or temporarily. But, the best
solution provided by most systems today is a requirement to share one's
account password with one's delegates. For reasons too obvious to
enumerate, that is a *really* bad idea. A preferred solution would be to
leverage a Rights Expression Language to express an either complete or
partial delegation of capabilities. It would be somewhat like the use of
REL to control other's ability to Reply.

If we assume that one can temporarily delegate to others the right to
perform some or all ActivityPub "Activities," one expression of a
capability delegation might look something like the following: (Note:
Appropriate cryptographic proofs, signatures, etc, have been omitted for
brevity. Also, the time-limitation syntax is from ODRL. It is kinda ugly,
but easily processed.)

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               "http://example.com/ns/profile.jsonld",],
   "type": "Delegation",
   "id": "https://example.com/8affd06cf9e9ff50ffc6bc966",
   "content": "Please take care of it while I'm out...",
    "permission": [{
        "target": "acct:corporate@example.com",
        "action": ["Create", "Delete", "Follow", "View", "Like"],
        "assigner": "acct:corporate@example.com",
        "assignee": ["acct:bob@example.com",
                     "acct:alice@example.com",],
         "constraint": [{
           "leftOperand": "dateTime",
           "operator": "lteq",
           "rightOperand": { "@value": "2023-04-30", "@type": "xsd:date" }
       }],
    }],},

Ideally, if this delegation were used, any performed activity would include
an indication of who had created it. Thus, we might see a Note which was
signed "By Bob, on behalf of Corporate."
Conclusion

I've tried above to demonstrate how use of a Rights Expression Language
could address several frequently discussed issues with AS2 applications.
Hopefully, the examples made sense and will spark some useful discussion.
I'm sure that folk will propose either that this is "not a problem" or that
simpler syntax should be used. However, I am convinced, after listening for
a long time to a wide range of user issues, that the need for something
like this, if not precisely this, will eventually be broadly recognized. My
hope is that we'll be able to reduce the implementation and specification
burden by having one facility that can address a wide range of otherwise
disjoint problems.


bob wyman