Collaboration diagram for Communication Access Rights:

Modules
	Communication Access Operations

access_type	access_type_comm
	Access Types for Communication, as registered on http://uuid.arpa2.org.

#define	ACCESS_COMM_WHITELIST ACCESS_WRITE
	Access Rights for Communication. More...

#define	ACCESS_COMM_GRAYLIST ACCESS_CREATE
	An alias for ACCES_COMM_GREYLIST.

#define	ACCESS_COMM_GREYLIST ACCESS_CREATE
	Marks communication that should be subjected to an extra check. More...

#define	ACCESS_COMM_BLACKLIST ACCESS_VISITOR
	This marks refused communication. More...

#define	ACCESS_COMM_HONEYPOT ACCESS_KNOW
	This marks communication for side-tracking to a honeypot or other active form of suppression or investigation. More...

#define	ACCESS_COMM_WHITELIST_UP ACCESS_WRITE_UP

#define	ACCESS_COMM_GRAYLIST_UP ACCESS_CREATE_UP

#define	ACCESS_COMM_GREYLIST_UP ACCESS_CREATE_UP

#define	ACCESS_COMM_BLACKLIST_UP ACCESS_VISITOR_UP

#define	ACCESS_COMM_HONEYPOT_UP ACCESS_KNOW_UP

#define	ACCESS_COMM_WHITELIST_DOWN ACCESS_WRITE_DOWN

#define	ACCESS_COMM_GRAYLIST_DOWN ACCESS_CREATE_DOWN

#define	ACCESS_COMM_GREYLIST_DOWN ACCESS_CREATE_DOWN

#define	ACCESS_COMM_BLACKLIST_DOWN ACCESS_VISITOR_DOWN

#define	ACCESS_COMM_HONEYPOT_DOWN ACCESS_KNOW_DOWN

#define	ACCESS_COMM_ALIAS RULES_VARINDEX ('a')
	Attributes for Communication. More...

#define	ACCESS_COMM_ARGS RULES_VARINDEX ('a')

#define	ACCESS_COMM_NEWALIAS RULES_VARINDEX ('o')

#define	ACCESS_COMM_NEWARGS RULES_VARINDEX ('o')

#define	ACCESS_COMM_SIGFLAGS RULES_VARINDEX ('s')

#define	ACCESS_COMM_NEWUSER RULES_VARINDEX ('n')

#define	ACCESS_COMM_NEWSERVICE RULES_VARINDEX ('n')

#define	ACCESS_COMM_ACTOR RULES_VARINDEX ('g')

Detailed Description

Communication Access defines a number of Access Rights. They are based on the general Access Rights, though with a somewhat technically-driven interpretation.

The ARPA2 Identity to which Communication Access is applied is the Remote Identity; the attempted contact is to a Local Identity, from which the Access Domain is derived.

The Access Key is the userid part of the Local Identity if it is a user, or the +service if it is a service. Aliases and signatures are not included in the Access Key, because they are too variable for database lookups.

Attributes (Rule Variables) are used to constrain and override aliases or service arguments, and to impose minimum requirements on the signatures flags.

Macro Definition Documentation

◆ ACCESS_COMM_ALIAS

#define ACCESS_COMM_ALIAS RULES_VARINDEX ('a')

Attributes for Communication.

Communication does not only define rights, but keeps variables as well, to provide alongside callbacks sharing these rights with the application. These variables are declared as part of the ACL text, in which they occur as single-letter assignments.

ACCESS_COMM_ALIAS or ACCESS_COMM_ARGS can be used to match the existence and value of user alias and/or service arguments. The value is matched for a given userid or service name, so which applies is known when this is declared. The text does not start with a '+' but it may cover multiple levels by haing internal '+' separators. The local identity that is being addressed may add more alias words after this one, by adding even more '+' separators in the aliases field.

ACCESS_COMM_NEWALIAS or ACCESS_COMM_NEWARGS can be used to overwrite the alias and/or service args. This can be used to redirect traffic to a sub-user or sub-service that is better suited to the request. The original aliases or args vanish.

ACCESS_COMM_SIGFLAGS can be used to require minimal support of certain signature flags, as well as to demand that a signature is actually present in the addressed local identity. The check is on the presence of flags alone; the signature validation should independently be made, using the routine that silently skips over missing signatures; the combination with this check is useful to nonetheless enforce a signature, and require it to be good (and even personalised). The format of this field is decimal, 0x-prefixed hexadecimal or 0-prefixed octal and its value is a bitwise-OR of required A2ID_SIGFLAG_ values.

◆ ACCESS_COMM_BLACKLIST

#define ACCESS_COMM_BLACKLIST ACCESS_VISITOR

This marks refused communication.

 This tends
 to be the cautious default.  Users who welcome general
 communication may set the selector "@." to pass anyone,
 and still be able to add rejection for more specific
 askers.
 (This maps to ACCESS_VISITOR, a rather useless right.)

◆ ACCESS_COMM_GREYLIST

#define ACCESS_COMM_GREYLIST ACCESS_CREATE

Marks communication that should be subjected to an extra check.

 Think of the
 grey-listing by temporarily refusing to accept email,
 in a manner that is protocol-specific and only as an
 suggested approach.  It is up to the actual protocol
 to decide how to handle gray-listing.
 (This maps to ACCESS_CREATE -- as it can create a new
  access privilege.)

◆ ACCESS_COMM_HONEYPOT

#define ACCESS_COMM_HONEYPOT ACCESS_KNOW

This marks communication for side-tracking to a honeypot or other active form of suppression or investigation.

This may be used for remotes who are known offensive and are ideally side-tracked into a trap, or a honeypot or other structure in support of observation. This may not be possible everywhere, in which case it may be treated just like ACCESS_COMM_BLACKLIST. (This maps to ACCESS_KNOW – the hosted identity would be shown to the remote party.)

◆ ACCESS_COMM_WHITELIST

#define ACCESS_COMM_WHITELIST ACCESS_WRITE

Access Rights for Communication.

The access rights for communication each specify a level that the remote party should land it. This may be any combination of white, black and grey list and there is even a definition that suggests landing the remote in a honeypot, which might be useful in attack situations.

Normally, a request would be interpreted as being on any one of these levels, and indeed, the highest available can be selected in these cases.

Marks accepted communication

 Just like
 the other communication rights, this is agnostic to
 the communication protocol being used, so whitelist
 entries for email and chat are all the same.  This
 is thought to make sense and minimise the burden of
 contact management on the communication ACL.
 (This maps to ACCESS_WRITE.)