|
ARPA2 Common Libraries
2.6.2
|
Pseudonyms are alternative identities that a user may choose to use. Whether this is permitted depends on a Policy Rule that indicates who may use the pseudonym. Normally, that is just one person.
Pseudonyms are a form of Actor Identity; they allow a user to switch to another identity after login. This can be beneficial for privacy, as well as for separation of the communincations around online activity patterns. Furthermore, remote users can be brought into a system by offering them the use of a pseudonym.
Pseudonyms are quite different from an anonymous "identity", in that they can be traced to the user who has acquired this alternative name. This makes it possible to come back to a remote service and continue actions that were previously initiated.
Since a pseudonym is tied to one (or a few) users with another login, it is possible to assume that the user/s behave responsibly under their login. This may indeed be part of the acquisition process of a pseudonym.
Aside from privacy aliases and perhaps company identities, pseudonyms are also useful to assign roles, especially when they may later shift to others. Examples of this are an admin for a domain or its postmaster, webmaster and financially responsible person/s.
Pseudonyms differ from groups. A pseudonym is defined by the first word before any + character in the local-part, and any other words work like aliases, just like in a primary username. At least in the foreseeable future, a group could support subgroups, and only the last label would then be used to add a member identity. Also, groups tend to be managed more dynamically and perhaps even frivolously, whereas the assignment of a pseudonym feels like adminsitrator-level action.
Another difference between pseudonyms and groups is that there is no bidirectional communication planned. Pseudonyms can be used during login, to change to an authorisation identity. Any communication ends with that identity, and is not transferred to the login identity.
Aliases are so simple that they are usually resolved in the places where they are useful. Among these places is the access_actor() call.
Pseudonyms bring a little more complication, and it is normally used as part of the access_actor() call. However, to be able to evaluate the presence of the ACCESS_ADMIN or A Access Right, there is an additional access_actor_pseudonym() call that delivers the Access Right according to the Pseudonym' policy.
Groups add much more conceptual strength, including iteration with filters, the Access Rights for group members and delivery to others. These do have their own API calls, some of which is integrated into access_actor() and others which may be accessed directly.
Because of this, pseudonyms are not explicitly visible in the API but there is an internal function access_actor_pseudonym() whose only use is to test alongside other Actor Identity checks in the public access_actor() function.
The access_actor() function admits the differences between groups and pseudonyms (and their grammar and related processing in the Rules DB) by distinguishing the optional service keys or rulesets that can be supplied for each form (and deriving the corresponding default service keys in the simplest form of the call).
Only a fully defined ARPA2 Identity with no + characters in the local-part can be used as a pseudonym. Being a (case-insensitive) ARPA2 Identity without signature part, it will be completely in lower case. Services are deliberately excluded from having a pseudonym or acquiring a pseudonym. There are no aliases (or "sub-pseudonyms") implemented as part of the Policy Rules.
To lookup a pseudonym in the Rules DB, the service key is further developed into a request key. This uses the canonical form of the pseudonym identity as a string for the Access Name, and it uses the current identity, also with lower case domain name, as (Remote) Selector, which implies that the user name part may hold upper case letters.
The rules are looked up in the Rules DB under their own rules type, different from groups, to avoid clashes with other uses that may use similar textual formatting.
It is possible to bypass the Rules DB and supply a literal ruleset, but this is not advised because it leads to decentralised management which often is more error-prone. But you do have this option.
Policy rules for a pseudonym include RIGHTS to grant rights, the most important one being T or ACCESS_OPERATE which allows the entry into the pseudonym, and A or ACCESS_ADMIN which allows changes to the policy rules.
The management of these rules is usually done via a2rule(1). The use is similar to the operations for a group, but with different constraints, mostly syntactical. There is no a2rule pseudo add operation though; only sub-commands set, get and del are supported. The commands use alterego for the pseudonym to request and loginid for the current identity. Inasfar as the loginid is (known to be) an ARPA2 Identity, it should not be setup for service identities. In general, it is not advised to use any + character in the user name part of the loginid, because this is not usually the form used during login, but it is not forbidden.
The ARPA2 Actor Access framework involves a call that validates the switch of an identity:
More details about this API are defined under Actor Identities after Access Control. This call also permits changes to a group member and aliases.
When switching to a pseudonym, the first label is considered and any additional +words are considered aliases on the pseudony, which are permissible.
There is another call which is mostly needed to evaluate the right to change the Pseudonym policy (its administrative rights):
1.9.1