I want to get the discussion started about permission handling in the FediVerse. Unfortunately, I have little experience how to talk about permissions. So I want to start off with a simpler question:
What is the best format to specify permissions in?
The basic problem for me is the following, the average ActivityStreams object, i.e.
{
"@context": "https://www.w3.org/ns/activitystreams",
"attributedTo": "https://example.com/users/author",
"type": "Note",
"cc": "Public",
"name": "A Word of Warning",
"content": "Looks like it is going to rain today. Bring an umbrella!",
"to": "https://example.com/users/someone"
}
contains a lot of information, from which permission information can be interfered. This interfered information might look like
EDIT: https://example.com/users/author
INTERACT: https://example.com/users/someone
VIEW: Public
or something similar. So my simple question can now be stated as: What is a good format to talk about EDIT, INTERACT, VIEW and their values.
As permissions should be ubiquitous in the software world, I hope there to be standard answers. I know about groups, roles, permissions that are commonly used in web applications. The situation with ActivityPub seems to be more complicated than can be mapped to this.
Bonus question
Is there a good way to encode something like if “Public” is present in “to” or “cc”, make the object viewable to the Public? If something is viewable to “Public”, it is viewable to any actor?
you can’t infer “interact” permissions at all. anyone who has the id of an object can refer to it.
more generally, activitypub doesn’t even have a concept of “permissions” at all. the only remotely relevant assumption is that the attributedTo actor(s) is/are the owner(s) of the object, and thus has/have permission to Update and Delete. but even this framework fails to account for service-level moderation actions. you might consider making attributedTo an array of every actor authorized to update or delete, but this can complicate authorship information. there are other alternatives as well, but nothing really expressive enough to capture the idea of “this is the set of actors who can perform x action or have x level of access”. in practice, whoever controls the domain controls all objects on that domain.
for analogous cases, you may look to a similar question: what are the “permissions” of any random web page or web resource? bear in mind that activitystreams documents are just web resources when accessed via the (linked data) web.
if Public is in to/cc/audience, the object or activity “shall be accessible to all users, without authentication” (per ActivityPub 5.6 “Public Addressing”).
I currently don’t care about the content, just how it is presented. I’m just trying to figure out the answer to
talking about who should be allowed to do what comes afterwards.
Permissions are too messy to tackle the entire problem. So I’m trying to split it up into simpler parts. The first is: “How do we present them?” I don’t think I have a good answer to this question yet, unfortunately.
Not sure if we can talk about how to build Permissions without talking about who the permissions are for and why.
Normally permissions are custom and specific to each fedi app, which is how it works today. So standardizing on any kind of protocol for them would be difficult.
Reading things, like zcap-spec. I’ve come to another realization, where the problem with talking about permissions is.
Where are permissions stored?
The “standard answers” seem to take orthogonal approaches here. ACLs store permissions externally. Also what constitutes a “user” is poorly specified there.
As @silverpill mentioned, OCaps are the preferred solution anyway. In an OCap the “capability” is stored with the object. So one arrives at something of the form:
{
"object": {
"@context": "https://www.w3.org/ns/activitystreams",
"attributedTo": "https://example.com/users/author",
"type": "Note",
"cc": "Public",
"name": "A Word of Warning",
"content": "Looks like it is going to rain today. Bring an umbrella!",
"to": "https://example.com/users/someone"
},
"capabilities": {
"interact": "hash value or url or whatever",
},
"signature": {
"method": "Example",
"proof": "quod erat demonstrandum"
}
]
The important thing here, is that two things are added to the object:
A capabilities object that describes what kind of permissions the holder of the wrapped object has
A signature that verfies the integrity of the wrapped object.
I will now call this type of permission model intrinsic permissions, i.e. an object is always handed out with a verified list of permissions.
If one actually wants to implement all this, there are a list of cryptographic considerations like how to ensure that someone without the “interact” capability can check someone else has the “interact” capability. However, I’m confident that this can be achieved by reading specs / papers.
I think the permissions should be embedded in the object, but there should be no hard mechanism to enforce them, this is up to the codebase/user config ie. soft “social” trust not hard “coded” trust.
They are likely specified in an ACL for the codebase/user account, then added to the object etc. this flow should be transparent.
The more, I think about how to describe permissions, the more I realize how deep the flaw of the sharedInbox instead of the publicInbox is. With a publicInbox:
Determining an Activity is public is trivial. It is public if and only if, it was received by the publicInbox.
It is trivial to exclude someone from sending direct messages and still allow them to send public ones. Just don’t give them the inbox.
We should introduce ActivityPub 2.0 with the only change being “All activities send to the sharedInbox are henceforth considered public. The inbox is no longer necessary for an Actor (neither the outbox).”
I’m joking about AP2.0; one probably also wants something about detaching objects from urls and verification in there.
an Activity is public if to/cc/audience contains the Public magic collection. it is irrelevant which inbox receives it.
you don’t need a spec revision for this. you can provide a “dummy” inbox to whoever requests the actor, if you don’t intend them to be able to message you.
Anyway, thanks all. This has helped me clarify my mental model of how to talk about permissions. Maybe, I’ll try to write something down. Then people will realize, why I use the domain “mymath.rocks”.
It’s interesting that #AP has no way of defining traditional permissions - think this is a good thing, well done speck writers, I mean that in a good way.
Magic is another word for #openweb#4opens#OGB and the mythical #OMN am sure, what do we build from this thried? You guys have the shovels, lots of compost and there are some seeds out there.
the word “magic” in “magic collection” just means that it isn’t expected to resolve. you refer to it by the IRI https://www.w3.org/ns/activitystreams#Public. an activitystreams 2.0 parser with support for the activitypub extension should, upon encountering this IRI in the addressing properties, take this as a signal that the object is available without authentication. if the IRI is not present in the addressing properties, then you don’t know that. that’s all. at no point does the receiving inbox matter for anything whatsoever. if you receive an activity in your inbox, then you are one of the recipients – this is a tautology. there may or may not be a hint as to who else received it (via to or cc), and there may or may not be a hint as to who is intended to view it (via audience). but for your own purposes, all that matters is that you received it. requiring delivery to some “public” inbox makes no sense, and by its very definition, Public does not have an inbox.
I think this line hits the spot. If one equates permissions to something like “this user can do that”, one is already in a mindset that is hard to break out of. That’s why I am trying to limit myself to talking about “how to talk about permissions” in this thread.
This is a hard task!
I want to give both examples that might be familiar to people and share insights, I get related to the ActivityPub spec.
Anyway, going completely off-topic again to the publicInbox: Picture yourself two ActivityPub servers called Alice and Bob. They look like huge bears in my mind. I kind of want to picture the users as birds sitting on the bears. The bears are hugging it out:
Alice: Let’s be friends! Let’s federate. Bob: Here’s my publicInbox: https://bob/SjcX6CZXWRfmlMyJnUs94oX5ibLxgzBPQa7Md1Uaaoo Alice: Here’s mine: https://alice/QYdCfLjyODWjdgYVDHfNQJhFoYLmml7fzdyqo2CahkE Bob & Alice: Yay!!
Unfortunately, I’m too poor of an artist to draw an appropriate picture.
“this user can do that” is a capability. how does this differ from a permission in your mind? i’m really confused what the use-case is here.
likewise, i still don’t understand what the use-case is for having a publicInbox. since it’s not associated with any actor, who do you expect to be checking it and when?
Given that a “Capability Object” describes permissions, is there any essential difference between a “Capability Object” and a rights Policy or Rule as may be described using W3C ODRL? If these are simply different names for instances of the same class of things, then it seems reasonable to me that the same method should be used to describe both.
Would an ODRL Profile be a reasonable means to define the syntax and semantics for the “capabilities” element you suggest in your example?
I’ve split this up into first and second. You might care more about second.
First: Back to the word permission:
First, ODRL contains a circular definition of permission. Relevant parts only in the quote:
Rule: An abstract concept that represents the common characteristics of Permissions, Prohibitions, and Duties. Permission: The ability to exercise an Action over an Asset Asset: A resource or a collection of resources that are the subject of a Rule
So in order to understand a Rule, for which you need to understand a Permission, for which you need to understand an Asset, for which you need to understand a Rule, for which you need to understand a Permission, for which you need to understand an Asset, for which you need to understand a Rule, for which … Sanity asserts itself here and stops me form continuing.
As my main point in starting this thread was to properly get a handle on how to talk about permissions, this is relevant. Please understand that the above is not to say ODRL is bad, it is to say giving a clear definition of what we mean by permissions seems incredibly hard.
For people who have their doubts, I have a graduate degree in Mathematics. Thus I assign a very specific meaning to the word definition. For example circular definition is a studied phenomena that leads to all kinds of complications.
Second about the actual usage of ODRL
ODRL seems to be a format to encode “permission information”. This means I can store an ODRL object with my Asset and then can run an algorithm to determine if I’m allowed to perform the Action I want with that Asset. The result may well be that I need to pay for it.
The problem here is in the detail, that there are a lot of Is in the above. Basically, if Alice and Bob agree on using a form of ODRL to do permissions, etc. They will no longer be able to “federate” with Carol as she lacks the proper certification, that guarantees to Alice and Bob that their ODRL standard is respected.
@hamishcampbell would call this a #closedweb approach if I understand his writing correctly. I hope that at least the statement: “Currently, implementing ODRL correctly, is a non-trivial requirement” is non controversial.
Still second; Actual usage perspective in the Fediverse
The more I think about it, the more I like implicit permissions, i.e. permissions you don’t need to state. I’m back to doing examples that are hard to understand. So if you don’t understand what I wrote about publicInboxes, you can skip this.
Consider the difference between the two objects
A = {"content": "my message"}
B = {"content": "my message",
"proof": {"signature": "xxx", "verifier": "theAuthor"}}
A naive view might be that B is always preferable to A, as it contains more information. I want argue that A is better if you don’t want your content to be shared. Consider this Alice sends Bob the object B and Bob forwards it to Carol. Now, Carol is certain that Alice said “my message”, because Alice had signed the message. If instead Alice send A, Carol would need to either ask Alice if she send A or simply assume that Bob made up the message. Note: Bob still knows that A is from Alice as the request delivering it to him was signed. Just not the object.
So why I did I give this example: B never made explicit that it contained a permission “share”. It just gave you the ability to be shared by being signed. An explicit permission would look like
B = {"content": "my message",
"capabilities": ["share"],
"proof": {"signature": "xxx", "verifier": "theAuthor"}}
One probably needs to formalize all this better. Unfortunately, I don’t have the time. If anyone wants to pay me for three months to write the 200 page book “Permissions for Dummies aka Mathematicians turned Software Engineer”, please send a message. Also please make sure that the title does not infringe on any copyright.
Continuing the A, B example
Probably the paragraph
Servers performing delivery to the inbox or sharedInbox properties of actors on other servers MUST provide the object property in the activity: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo. Additionally, servers performing server to server delivery of the following activities MUST also provide the target property: Add, Remove.
While ODRL’s definition of Permission, etc. may appear circular to a mathematician or to someone seeking to “understand a Permission,” these definitions are NOT circular when read by a software engineer interested in syntax. Given that ODRL is a specification of syntax (language), the definitions you cite are a reasonable, high-level statement of the syntactical or structural relationships between instances of Permission, Rule, and Asset. These definitions tell me that:
A Rule object, which is an instance of either Permission, Prohibition, or Duty, has a reference to a subject which is an Asset.
You wrote, in the first version of your comment:
please send a message. Also please make sure that the title does not infringe on any copyright.
At least under US Law, copyright cannot be claimed for the title of a work. Although, in some circumstances, one may obtain a Trademark for a title. See Circular 33, which describes. for the USA, “Works Not Protected by Copyright.” Given that much effort has been spent on aligning international IPR regulation, I believe that most countries similarly limit copyright for titles. However, it may be that some countries do permit it.
The differences, and conflicts, between laws may be a reason why ODRL does not provide detailed semantic descriptions of Permissions, Prohibitions, and Duties. The precise meaning, or effectiveness, of such expressions varies according to local law. ODRL only shows how to express one’s intent, not the effect or meaning of such an expression within the context of any particular jurisdiction.
Nonetheless, in the legal analysis of intellectual property rights (IPR), one often distinguishes between “rights,” which are established by law, and “permissions,” which arise from contractual relations between actors subject to law. “Permissions” arise from the assignment, from an assignor to an assignee, of an ability to exercise some right(s) which would otherwise be reserved to the assignor. Although ODRL, the “Open Digital Rights Language,” uses the term “rights” in its name, it is actually concerned only with Permissions, Prohibitions, and Duties, not with the rights established by law.
This distinction between rights and permissions is important to understand since it constrains what an assignor may do. For instance, an effective permission can only be assigned for the exercise of rights reserved to the assignor. Thus, if the law establishes a right to Fair Use, a “Fair Use” permission has no effect. In this way, the law ensures some limited degree of “openness” by ensuring some minimal right to use content published by others (but not much…). Certainly, we usually wish it to be possible for others to do much more with content than the law requires that that may do.
In most jurisdictions today, almost all rights for the use of creative works are reserved. The use of any object for which permissions have not been assigned is restricted to only those uses established as rights by the law. (e.g. “Fair Use” may be permitted, but not the “sharing” or redistribution of an entire object.) But, because we want to ensure a more “open web” than that provided by the law, we need to define a means to allow, and even encourage, the expression of permissions to exercise otherwise reserved rights. For this, I think we need a Rights Expression Language such as ODRL.
Not really. Any ODRL embedded within an object is limited in its ability to impose a “need to pay.” The mere act of exercising your right to read legally obtained content can’t and doesn’t create an obligation or duty.
One can’t say: “If you read this, you owe me money.” However, it is quite possible and often reasonable to say: “If you wish to be assigned permissions, you must pay for them.” While reading something you’ve received can’t be prevented, one can require payment for redistribution, the creation of derivative works, or perhaps for access to a decryption key that will allow reading some encrypted text. But, since things for which permissions are necessary are inherently reserved, it should be seen as a good thing to provide a means to discover what must be done in order to receive needed permissions.
Your claim is incorrect. Carol can still participate in the federated system. Whether or not ODRL is present, Carol still has the rights to some minimal use of whatever Alice and Bob publish. If Carol receives a copy of a post from Alice, she has a right to read it and to do whatever copying, storage, etc. may be necessary to facilitate her reading. She can also exercise “fair use” by quoting the post. Also, if Carol has a system that understands only a subset of ODRL, she would still be comfortable relying on it when processing ODRL that it understands. If Bob and Alice want to be “open,” they would be well advised to limit the complexity of their ORDL use to that which is commonly understood by their audience. (Unfortunately, this may require that they grant fewer permissions than they might like to.)
Carol’s ability to “federate” is only limited in that, without being able to understand the permissions described by some ODRL, she might not be sure if she’s permitted to share the post with others, create derivative works based on it, etc. Given such uncertainty, Carol would be wise to assume that she has no permission to do things for which she has no right under the law. Carol can still read what she receives, post her own messages, and otherwise participate in the federated system, but her participation is limited to less than that of Carol or Bob. (It would be wise for Carol to switch to a system that more fully supports ODRL and thus allows her more open sharing and use of content!)
Yes, that’s non-controversial. However, one of the benefits of open software is that once someone implements a complex system, it becomes easier for everyone else to benefit. Our capabilities accumulate. Consider the complexity of modern Web Browsers: if someone had written up a specification for Chrome in 1990, they would have been considered insane. But, today, even children are able to use Chrome, or similar browsers.
I suggest that the SocialWeb community should define a “Profile” for the use of ODRL to ensure that implementors are aware of a minimal set of expressive capabilities that should be commonly assumed.
Perhaps you don’t need to state permissions, but unless they are rights, someone needs to state them. It would be most effective to state them in a protocol’s specification. If the specification says: “The server SHALL distribute copies to all who are addressed in the TO: field” then anyone who publishes data using that protocol should understand that this form of redistribution is implicitly permitted. (In fact,the spec might also say that one can’t use a Rights Expression Language like ODRL to withhold the right to distribute to someone in the TO: field…)
However, I object to your apparent suggestion that a signature might implicitly assign a right to share or redistribute. A signature is merely a means to asset the integrity of a message if it is shared. Its presence implies nothing about a right to redistribute – although the protocol specification might. For instance, I should be free to send you a signed, private message without assigning you the right to share or redistribute it to others.
i have no real opinion on the ODRL stuff, but i’m seeing a lot of stuff that isn’t addressed here – how do we talk about permissions when we haven’t even defined what a permission is? the thread started with “edit / interact / view” but these don’t seem like something that can be expressed cleanly – and “view” is completely redundant, as if you can’t view the object, you can’t view the permissions either. i once again have to ask: what is the use-case here? what do you expect to communicate or signal to others, and why?
because, yes, we do have “implicit” permissions, but only insofar as they are a natural consequence of how information is shared. the example you provide with proofs doesn’t really have anything to do with permissions, but rather to do with verifiability. of course if the document isn’t directly fetchable or isn’t otherwise signed, then you can’t verify its authenticity. but you could also choose not to verify at all, and simply take it at face value. this would lead to a network partition between softwares which verify and softwares which do not.
and again, why would the spec be rewritten? you highlighted a specific paragraph that amounts to basically saying that activities should represent grammatically complete statements. even in the context of inbox forwarding, what would you need to “disregard” specifically? what does it mean to send someone a Create with no object? what does it mean to Add an object without also specifying the target to which it is being added? there’s a general incoherence to this discussion that i’m struggling to cut through, and a lot of statements regarding the activitypub specification that are being made with seemingly no reasoning or justification.
if you want to express some machine-parseable set of processing expectations, then perhaps ODRL could be helpful there (assuming you care to respect DRM at all); if you want to limit who can perform some action, then you might find some interest in object capabilities and their accompanying literature. but i don’t think we can have a productive conversation until we define the use-cases that are motivating such a discussion.
