Defining Contributors

Compliance expert with documents and identification badge.
Click HERE to discuss this topic in our forum! Small rectangle with word 'community' in red letters in center and a speech bubble rising from the 'y'.

The world of Compliance as Code offers us all a chance to contribute. Federated contribution systems include those provided by Unified Compliance, Open Skills Network, the National Institute of Standards and Technology and others. Every organization that has a documented schema in the realm of Compliance as Code (listed HERE) identifies various forms of contributors to their content. These contributors are listed as anything from primary authors, through editors, through “commentators” of contributed content to their various repositories of information. Thus we will simply call this collective group Contributors.

Knowing who contributors are is essential for attribution; the ascribing of a contribution to a particular author. Attribution ties actions by people to the person that took the action. Attribution for many of our actions on websites is being tracked continually through such projects as Google Attribution1, C3Metrics2, Bizible3, and Full Circle Insights4, and others. In fact, there is a lot known about us publicly, that we might not even be aware of. Organizations such as ClearBit5, FullContact6, BigPicture7, Powrbot8, Crunchbase9, ID.me10, all focus on business-to-business marketing, and as such, can form a pretty solid depiction of a person’s public persona using just their name and organizational e-mail as a starting point.

What do we need to know about a Contributor?

We need to be able to disambiguate people from other people, and from agents (computers in any capacity). We need to

  1. first and foremost ensure Joe Smith isn’t an agent, then
  2. disambiguate the user so that we know Joe Smith is that Joe Smith and not some other Joe Smith, and
  3. allow those disambiguating characteristics to be persisted between systems so that as factoids change (name, address, email, etc.) the disambiguated Joe Smith remains that Joe Smith instead of some other Joe Smith.

Persons versus agents

As Dan Brickley and Libbey Miller (co-authors of the FOAF (Friend of a Friend) Project) stated11, people as well as bots can have e-mail addresses, chat addresses, etc. Distinguishing Joe Smith from a Joe Smith bot can’t be done by just checking an email address. Therefore, personal identity disambiguation must begin with disambiguating people from things. Until one passes the Turing test, a computer, which manages bots and various software agents, will remain an antonym of a person. Therefore, throughout the rest of this discussion, we will use the following terms and definitions (the term is a linked item to the ComplianceDictionary.com’s entry for the term):

Term Definition
agent A program acting on behalf of a person or organization.
bot A robot; A piece of software designed to complete a minor but repetitive task automatically and on command.
natural person A living human being. Legal systems can attach rights and duties to natural persons without their express consent.

Because a bot is a type of agent, we will refer to all computerized processes that communicate agents.

Disambiguating a person from an agent

The world is inundated with fake accounts on social media platforms run by bots of various types and for various reasons. Merely having an e-mail address or social media address isn’t enough to disambiguate a person from an agent. A shibboleth of sorts is necessary to distinguish the two12.

In 2015 DARPA initiated a Twitter Bot challenge to determine person or agent13. At that time, they came up with five criteria (user profile, syntax, semantics, behavior, network features) to disambiguate between person and agent. Since that time, Google’s Duplex14 and IBM’s Watson and Project Debator15 have made huge leaps in their capabilities to use syntax, semantics, and even linguistic behaviors. This leaves two characteristics still in play as a potential shibboleth:

  1. User Profile – links to other accounts, biography, etc.
  2. Network features – how distinct the person’s “network” is, i.e., where they work and others they connect to.

We will save the discussion of the various objects that should be tracked in a person’s profile for later, for now, we’ll just call this collection of objects a person’s information.

Since the DARPA challenge, a great deal of research and practical application has been put into place in order to disambiguate natural persons from agents as well as personal name disambiguation (once you know Joe Smith isn’t an agent, knowing Joe Smith is that Joe Smith versus an-other one)16. So much so, that there are several methodologies for extracting information about both people and organizations from given information such as URLs and email addresses. We will cover each below as the information that can be collected from each source is different.

Extracting disambiguating public information

Various organizations have developed full-blown APIs for providing in-depth information about people, usually for marketing purposes, using their email addresses and domain names.

First and foremost, personal email addresses, such as those from Hotmail, Apple, Google, Yahoo, etc. cannot be used for extracting personal information. They just can’t. Any personal information extracted must be extracted from organizational email because the applications, such as ClearBit, FullContact, BigPicture, Powrbot, Crunchbase, ID.me, etc. (as mentioned already) all focus on business-to-business marketing, and as such, organizational e-mails. We will call these disambiguating APIs.

It is our postulation that there is enough publicly available information found within amalgamating the findings from a couple of the disambiguating APIs to put together a public personal profile that is both disambiguating and persistent in nature without the need for a personal UUID for coherency.

A natural person’s public profile can be disambiguated with persisting information when de-scribed in JSON-LD format using an amalgam of information found using disambiguating APIs.

Failing that, given a person’s organizational email, coupled with at least two addresses from Twitter, Facebook, Instagram, or LinkedIn, and tracking a person’s contributions to federated data systems (such as articles with DOI addresses17, UCF or OSN18 contributions, etc.), we can achieve the same results.

Converting a user in an online account to a Contributor

What follows is a methodology we propose to use any software (in our example we have created a bubble.io no-code template to demonstrate this capability) to take a user’s record and add the additional information necessary to allow that user to become a Contributor to content in any of the known federated systems.

Dataflow for converting a User to a known Contributor

The Compliance as Code federated system uses a couple of API calls to convert an Account’s User to a known Person so that the person can contribute content.

Abbreviated Flow
Abbreviated Flow

Let’s walk through the process.

The process to convert a user to a known Person begins within the User’s Profile when the user clicks the Contributor checkbox (1) in the screen below:

Contributor button
Contributor button

Before we convert the User to a Person, the user must first accept what we call the TLP (Terms of Service, License, and Privacy Policy).

Accepting the Terms of Service, License, and Privacy Policy

It all begins with walking the user through the Terms of Service, License Agreement, and Privacy Policy.

No-Code TLP process
No-Code TLP process

Terms of Service

The No-Code application must make the call to get the current Terms of Service.

API Call: GET /ToS;

To which the gateway will return those terms.

API Return: ToS;

Once the data is returned, the application must notify the user that he or she must accept the Terms of Service prior to moving forward.

Prompt User: "You must accept the terms of service.”

A window is then displayed with the current Terms of Service in it, as shown below.

TLP Acknowledgement
TLP Acknowledgement
  1. If the text is longer than fits within the window, the window must display a scrolling field.
  2. Both the Decline and Accept buttons are initially disabled if the scroll bar is activated. Scrolling to the end of the text is what activates both buttons.

If the user accepts the Terms of Service, they can continue.

If the user does not accept the Terms of Service, the application must display a prompt that the process will be canceled.

Prompt User: "You cannot continue without acknowledging the Terms of Service."

Privacy Policy

The No-Code application makes an API call to get the Privacy Policy.

API Call: GET /PrivacyPolicy;

To which the gateway will return the current version of the Privacy Policy.

API Return: PrivacyPolicy;

Once the data is returned, the application must notify the user that he or she must accept the Privacy Policy prior to moving forward.

Prompt User: "You must accept the Privacy Policy.”

A window is then displayed with the current Privacy Policy in it that acts the same as the one for the Terms of Service above.

If the user accepts the Privacy Policy, they can continue.

If the user does not accept the Privacy Policy, the application must display a prompt that the process will be canceled.

Prompt User: "You cannot continue without acknowledging the Privacy Policy.”

License Agreement

The No-Code application makes an API call to get the License Agreement.

API Call: GET /License;

To which the gateway will return the current version of the License Agreement.

API Return: License;

Once the data is returned, the application must notify the user that he or she must accept the License Agreement prior to moving forward.

Prompt User: "You must accept the License Agreement.”

A window is then displayed with the current License Agreement in it that acts the same as the one for the Terms of Service above.

If the user accepts the License Agreement, they can continue.

If the user does not accept the License Agreement, the application must display a prompt that the process will be canceled.

Prompt User: "You cannot continue without acknowledging the License Agreement.”

Begin Validate Person

The dataflow diagram for this process is shown below:

Person Validation flow
Person Validation flow

Once the user has accepted the three agreements, the Person Validation process begins.

Initial API Call

This kicks off with the API call to find out what we know about this user based on his or her email address.

API Call: GET /PersonByEmail;

On the server side

On the server side, one of three things is going to happen. Either

  1. the request is going to be queued (meaning it is taking a bit of time to gather the information),
  2. it is going to return whatever it found, or
  3. it won’t find anything about the user.

Request queued

API Response: Error = Request Queued;

If the request is queued you’ll need to present the user with some form of dialog, informing them that they’ll need to retry the request again at least after 5 minutes.

Prompt: Your request is queued. Please wait 5 min and click Validate Public Person again."

Invalid response

An invalid response can be returned if no information was found for any person using that email address.

API Response: Error = Unknown person

There are a lot of reasons that the API might not find a user, too many to go into here. At this point what is required by the user is that the user provides the minimum information the industry has agreed on to disambiguate this person from that person. For now, that means that the user has to add at least two social addresses (LinkedIn, Twitter, Facebook) and an office address.

Prompt User: "There is not enough social information to disambiguate you. You must submit two Social Addresses and an Office Address."

Once the user has contributed at least that much information, they can continue.

Valid response

If a person has been found that matches the email address given, the API will return a valid response with some or all of the data fields specified in the Person schema.

API Response: Person Information

At that point, the No-Code application needs to write the contents of the response into the local system, and it also needs to set the validated field’s boolean value to true.

Write: "validated" boolean value of "true" in User Profile;

If the No-Code application is storing User information in the same structure as Person information, the information returned from the API can be stored in that table. If not, the User’s information must be linked to a new record in the Person table.

Write: available data to user/person table, updating User Profile visually;

Continuing with the validation process

After that’s been done, the user will have to still validate all of the data that’s been returned by the API. The user should be given some form of visual notification that each profile segment has to be validated individually prior to submission.

Prompt User: "Validate each section of your profile"

Trapping for section saves

Each conversion from User to Person requires several sections of data (basic info, addresses, etc.). Before the user can submit the conversion each and every one of these sections has to be reviewed by the user. Therefore, the No-Code application will need to trap for the user saving each of those.

Submitting the Person

Once each of the sections has been checked the No-Code application needs to submit the data via the API call when the user clicks the Submit Public Person button via whatever dialog is to be displayed.

Prompt User: Select Submit Public Person

When the button is clicked, the No-Code application sends off the following API call:

API Call: Patch /Person

Receiving the data and checking it

On the server side, we will be writing that person’s data to our table and will then add some CoreMetaData you’ll need to write back into the No-Code system; the Person’s ID, date created & modified, etc.

API Response: Person Data

After you submit the Patch for the Person, the system will return the same information with the additional CoreMetadata. This will need to be written into that record’s Person table.

Write: Person Information

Footnotes

  1. “Powering Ads and Analytics Innovations with Machine Learning.” n.d. Inside AdWords (blog). Accessed November 12, 2021. https://adwords.googleblog.com/2017/05/powering-ads-and-analytics-innovations.html. ↩︎

  2. https://c3metrics.com/ ↩︎

  3. https://www.marketo.com/bizible/ ↩︎

  4. https://fullcircleinsights.com/ ↩︎

  5. https://clearbit.com/ ↩︎

  6. https://www.fullcontact.com/ ↩︎

  7. https://bigpicture.io/ ↩︎

  8. https://powrbot.com/ ↩︎

  9. https://www.crunchbase.com/ ↩︎

  10. https://www.id.me/ ↩︎

  11. http://xmlns.com/foaf/spec/#term_Agent ↩︎

  12. A shibboleth is a way the old Isrealite army used to detect imposters from their own by manner of dialect. The term was featured in a great episode of the television show WestWing wherein the President had to determine if a person was trying to lie about something important. You can see that part of the episode HERE. ↩︎

  13. Subrahmanian, V.S., Amos Azaria, Skylar Durst, Vadim Kagan, Aram Galstyan, Kristina Lerman, Linhong Zhu, Emilio Ferrara, Alessandro Flammini, and Filippo Menczer. 2016. “The DARPA Twitter Bot Challenge.” Computer 49 (6): 38–46. https://doi.org/10.1109/MC.2016.183. ↩︎

  14. “Google Demos Duplex, Its AI That Sounds Exactly like a Very Weird, Nice Human.” n.d. MIT Technology Review. Accessed April 20, 2020. https://www.technologyreview.com/2018/06/27/141823/google-demos-duplex-its-ai-that-sounds-exactly-like-a-very-weird-nice-human/.

    “Google Duplex: An AI System for Accomplishing Real-World Tasks Over the Phone.” n.d. Google AI Blog (blog). Accessed April 20, 2020. http://ai.googleblog.com/2018/05/duplex-ai-system-for-natural-conversation.html.

    “Google’s Duplex Uses A.I. to Mimic Humans (Sometimes) - The New York Times.” n.d. Accessed April 20, 2020. https://www.nytimes.com/2019/05/22/technology/personaltech/ai-google-duplex.html. ↩︎

  15. Fan, Shelly. 2019. “IBM’s ‘Project Debater’ AI Lost to a Human—But Put Up Quite a Fight.” Singularity Hub (blog). February 25, 2019. https://singularityhub.com/2019/02/25/ibms-project-debater-ai-lost-to-a-human-but-put-up-quite-a-fight/. ↩︎

  16. Vu, Quang Minh, Atsuhiro Takasu, and Jun Adachi. 2008. “Improving the Performance of Personal Name Disambiguation Using Web Directories.” Information Processing & Management 44 (4): 1546–61. https://doi.org/10.1016/j.ipm.2007.11.001. ↩︎

  17. Paskin, N. 1999. “Toward Unique Identifiers.” Proceedings of the IEEE 87 (7): 1208–27. https://doi.org/10.1109/5.771073. ↩︎

  18. “OSMT.” n.d. Open Skills Network. Accessed November 12, 2021. https://www.openskillsnetwork.org/osmt. ↩︎

Topics