GB2489419A

GB2489419A - Verification of an information source in multi-party information exchange and archiving

Info

Publication number: GB2489419A
Application number: GB1105048.1A
Authority: GB
Inventors: Keith Hartwell
Original assignee: Individual
Current assignee: Individual
Priority date: 2011-03-25
Filing date: 2011-03-25
Publication date: 2012-10-03
Also published as: WO2012131338A1; GB201105048D0

Abstract

A web server receives and stores data defining a subject domain pertaining to a subject party. A request is received from a provider party to upload information, such as an employment reference, relating to the subject party to the domain, and the server grants access to the domain. A unique identifier token is automatically assigned to the uploaded information indicative of the source of the information being the provider party. The server grants a referrer party access to the domain, to verify the source of the information by virtue of the associated unique identifier token. This may be used for employment references, especially high-level vetting of employees and where there is a significant employee churn. It enables a secure, centralised archive of an employee's employment history, with reference sources being easily verified. The providerâ s identifier may be defined using details such as their address, name, contact details, payment details such as bank account or card numbers, and similar.

Description

I

METHODS AND SYSTEMS FOR SHARING VERIFIED INFORMATION

Field of the Invention

The invention relates to methods and associated systems for sharing verified information. The invention is particularly suited to such methods and systems specifically for automated, centralised storage and retrieval of verified candidate references.

Background to the Invention

Typically, where a prospective employer needs to take up a reference on a candidate, obtaining the information requires the prospective employer to personally contact the referee by phone, mail or e-mail. To obtain a hard copy of a reference, verified as being bona fide, a mail or e-mail document will be obtained.

There exist a number of occupations (e.g. those working with vulnerable people, those working airside at airports) that require high level vetting including uninterrupted references over 5 or more years. In addition to the level of churn in these industries, some have a high reliance on locum/temporary workers engaged through agencies. Not only do these personnel move from role to role quite regularly, but they will likely also register with numerous agencies. Under Safeguarding Guidelines in the UK, every agency with whom a worker registers is required to obtain a reference for every role undertaken by the applicant in the last 5 years and verify any gaps in employment. It is understood that similar requirements exist in other jurisdictions.

Take the example of a locum Qualified Social Worker who is engaged in just 2 roles per year. If they then register with 5 agencies, each referee will be asked to complete 5 references and a total of 10 references will need to be issued for just one candidate. Over a 5 year "safeguarding period" that could mean an agency requesting 10 references and a total of 50 references being issued, for just one Qualified Social Worker. To take the UK as a specific example, estimates vary, but few people would argue with there being 4,000 Locum Social Workers. Conservatively, they generate a requirement for the issue of 40,000 references on a 5 year rolling cycle. Add to that a similar number of un-qualified Social Workers together with the 80,000 permanent Qualified Social Workers and one sector alone creates a substantial need for a streamlined system.

A similar situation exists with Teachers, Nurses, Doctors and those in security-sensitive occupations, such as those working airside at airports.

It is an objective of the present invention to overcome these burdens by providing a secure access, multi-partite, verified information sharing system.

Specific objectives addressed by the present invention include the provision of the following benefits to the parties involved in the information sharing (in the context of candidate references): For an employer (i.e. the person requested to supply a reference for a past employee): * only ever compose one reference per employee * compose whilst knowledge is fresh and records readily available * eliminated -repeated referral to HR-records to satisfy reference requests * eliminated -storage & retrieval time and costs * eliminated -risk of litigation For an employee: * a permanently maintained, comprehensive and immediately accessible professional history and reference portfolio.

* fully reconcilable CV and associated verification, making you the more professional and attractive candidate * freedom of movement between employers and agencies as not constrained by employer's/agency's need to satisfy vetting requirements For a recruiter (i.e. a prospective employer or an employment agency): * immediate access to a comprehensive reference and information portfolio * time (and money) saved, not having to apply for references * time (and money) saved, not having to chase references * time saved by early screening and avoiding unnecessary interviews * easy verification of CVs * relieved of the need to respond to subiect access requests from employees demanding copies of references.

These and other objectives are achieved by the provision of a methods and systems in accordance with the present invention.

By utilizing a fully automated system, the referee creates just one reference, the agency gathers all the references needed in one simple operation and the candidate has a readily available portfolio of references and job history verification.

Summary of the Invention

According to a first aspect of the invention, there is provided a computer -implemented method of sharing verifiable information, the method comprising: receiving and storing, using a computer, data defining a subject domain pertaining to a subject party; receiving, using a computer, a request from a provider party to upload information pertaining to the subject party directly or indirectly to the subject party domain; granting access to the subject domain by the provider party; automatically, using a computer, assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; and granting access to the subject domain by a referrer party; wherein the referrer party is able to view and/or download the information pertaining to the subject party and to verify the source of that information as being the provider party by virtue of the associated unique identifier token.

As discussed in the introductory portion, a typical application of the invention is in the field of the exchange of references, but is not limited thereto. Accordingly, the verifiable information pertaining to a subject party may be an employment reference for that subject party. The provider party may be a former employer, who is responsible for providing references for the subject party when requested by referrer parties such as recruitment agencies or prospective future employers of the subject party.

In this context, the invention addresses the objectives outlined above by: * enabling employers to upload a reference just once to a centralised secure store (the subject domain); * enabling employees to hold an ongoing portfolio of references, CV and qualifications; and * enabling recruiters to view the whole portfolio and to determine the provenance of the information (such as by checking that the unique identifier token associated with a reference belongs to the referee).

The source of the information held may be verified by the referrer party without human intervention.

The invention circumvents issues of Data Protection (from the perspective of employers and recruiters) because the relevant data is provided to the subiect party and subsequent access to that data is controlled by the subiect party.

Typically, the data defining the subject domain is input by the subject party.

However, it is envisaged that this data may alternatively be input by a third party.

The subject party may be prompted to input the data by a third party, such as a former employer (a provider party'), a recruitment agency or a prospective new employer (both referrer parties').

The method preferably includes a step of receiving and storing, using a computer, data defining a provider party account. At least some of the data used in the defining (creation) of that provider account can then be used to generate the unique identifier token. That data may include one or more of: a provider organisation name; a provider address, including post code; provider contact details; responsible person name and contact details; payment details, which may include bank account numbers and/or card numbers.

Preferably, granting access to the subject domain by the provider party includes the steps of: assigning a provider access password to the subject domain; and communicating the provider access password to the provider party. The provider access password may be valid for a limited period only. For example, the password may be valid for a set period of time (e.g. two weeks), or for a set number of accesses (e.g. one-time access), or a combination of those restrictions.

In this manner, access to the subject domain, and associated write permission, can be carefully controlled -typically by the subject party.

Similarly, granting access to the subject domain by the referrer party preferably includes the steps of: assigning a referrer access password to the subject domain; and communicating the referrer access password to the referrer party.

Again, access to the subject domain (and, e.g., read or download permissions) can be carefully controlled -typically by the subject party.

Optionally, a holding domain may be used as a bridge between the provider party and the subject domain. In such an embodiment, the step of granting access to the subject domain by the provider party in fact comprises granting access to the holding domain by the provider party; and the step of storing the verifiable information and the associated unique identifier token in the subject domain in fact comprises storing the verifiable information and the associated unique identifier token in the holding domain. The method according to this embodiment thus further includes a step of subsequent to a request relating to a subject domain, transferring the stored verifiable information and the associated unique identifier token from the holding domain to the subject domain.

A feature of this embodiment is that a provider party may upload a reference to a "holding domain" which may in turn be uploaded to the subject party's domain, at the behest of the subject party, at a later date. This provides more comprehensive functionality allowing the employer to upload a reference as a matter of course without the need first to obtain an invitation from the subject (employee) but still absolves them from further action in relation to that employee should they (or another) request a reference at a later date. In some embodiments, all material may pass through such a "holding domain".

According to a second aspect of the invention, there is provided a system for the sharing of verifiable information, the system comprising: a web server having programmed thereon code executable to initiate a series of steps including: creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; controlling access to the subject domain by a provider party; enabling the uploading of information pertaining to the subject party directly or indirectly to the subject party domain by the provider party; automatically assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; controlling access to the subject domain by a referrer party; enabling the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enabling the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.

According to a third aspect of the invention, there is provided a computer program product comprising code uploadable to a web server and executable on the web server to facilitate the sharing of verifiable information, wherein said code includes means to: enable creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; control access to the subject domain by a provider party; enable the uploading of information pertaining to the subject party directly or indirectly to the subject party domain by the provider party; automatically assign a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; store the verifiable information and the associated unique identifier token in the subject domain; control access to the subject domain by a referrer party; enable the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enable the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.

According to a fourth aspect of the invention, there is provided a web server having computer instructions for executing the steps of: creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; controlling access to the subject domain by a provider party; enabling the uploading of information pertaining to the subject party directly or indirectly to the subject party domain by the provider party; automatically assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; controlling access to the subject domain by a referrer party; enabling the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enabling the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.

The second, third and fourth aspects of the invention all share the inherent characteristics and benefits of the first aspect of the invention as discussed above. Furthermore, the preferred and optional features set out above in connection with the first aspect apply equally, mutatis mutandis, to the second, third and fourth aspects of the invention.

Brief Description of the Drawings

The invention will be described, by way of example, with reference to the accompanying drawings, in which: Fig.1 is a schematic overview of a system embodying the invention, showing the information flow between the parties; Fig. 2 is a flow diagram illustrative of steps taken to upload a reference to the system; Fig. 3 is a flow diagram illustrative of steps taken to view/download a reference in the system; Fig. 4 shows an exemplary home page for a website embodying the invention; Fig. 5 shows an exemplary subject domain page for the website of Fig 4; Fig. 6 shows an exemplary provider page for the website of Fig 4; Fig. 7 shows an exemplary referrer page for the website of Fig 4; and Fig. 8 is illustrative of one way in which to generate a provider verification code.

Detailed Description

The primary purpose of the invention is to allow a first party (the referrer party, A') to obtain information about a second party (the subject party, B') that has been provided by a third party (the provider party, C') and for the referrer party to be able to verify that the provider party is who they claim to be and to assess their credentials and gain access to their whereabouts. The system of verification is automated in both the collection of verification data and in the issue of the provider party's details.

More broadly speaking, however, the invention is a facility to enable the secure capture, storage and sharing with a referrer party information provided by a provider party, about a subject party, and enabling the provenance of the information to be verified in an automated manner.

As a multi-partite information sharing system, although the principle party is the subject (as this is to whom all the information relates) the process may be initiated by any of the three parties. For the sake of clarity, the system's function is described by use of an illustration that starts with a (former) employer in itiating the use of a service embodying the invention, and is given in the context of a service (called InfoBank') in which the relevant information includes employer references.

InfoBank is a computer-implemented service that may be provided in the form of a computer-readable medium carrying instructions to be executed by a computer. Alternatively, InfoBank may be provided through a web-based browser interface.

With reference to Fig 2, a reference is uploaded to the system in the following manner. In a first step, the provider party -the (former) employer of the subject party -sets up an account with the InfoBank service. This step is illustrated as being optional to this process because the provider party will typically, unless using the system for the first time, have a provider account in place.

When setting up a provider account, the provider will be prompted to provide data, which will typically include: the name of the provider organisation; their address, including post code; provider contact details, such as fax and phone numbers and an email address; the name of a person responsible for the provider account, such as the HR manager, and their contact details; and payment details, which may include bank account numbers and/or card numbers. The payment details are required where a fee is chargeable by the InfoBank service for the provider party's use of the system, but are also useful for use in identifying the provider party as the source of the reference (as explained in greater detail below).

The person responsible for the provider account will manage access to the provider account by setting up log-on details, including a password.

The subject party sets up a subject domain and in so doing inputs data identifying and relating to the subject party, such as: their name(s); address, including post code; date of birth; National Insurance number (or other unique identification reference); and payment details (as for the provider account). The subject party, in creating their account, will have a designated "tag" comprising (for example) their Date of Birth and NI Number, e.g. 19860723PL236870B.

The subject party will also set up log-on details, including a password. A person having those log-on details (typically just the subject party) will have write permissions for the subject domain and can edit the data therein and supplement with additional information, such as, for example, a CV or other personal biography.

The setting up of the subject domain can be done when the subject party is employed by the provider party (in anticipation of the subject party leaving the employ of the provider party), or can be done after the employee has left.

Either way, once a reference is required, the subject party will log in to the subject domain (see Fig 4) so as to grant temporary access to the (former) employer by setting up a provider access password and communicating it to the employer, for example by email. Typically, this step will be instigated by the subject party, for example by clicking on a Create Employer Access' button in the subject domain, but the actual generation and delivery of the access password will then be done automatically by the system. The provider access password will typically be valid for a limited period only. For example, the password may be valid for a set period of time (e.g. two weeks), or for a set number of accesses (e.g. one-time access), or a combination of those restrictions. In this way, the employer would not be able to alter the reference once the limited period has expired, so rendering the process secure. This has the benefit of ensuring that any references that are uploaded are as contemporaneous and as accurate as possible.

The relevant person at the employer, such as the employee's line manager (the referee) is then able to access the subject domain using the provider access password to upload the subject's reference. The reference could take the form of a non-standard document uploaded to the subject domain, but is more preferably a pro-forma document that may be completed online within the subject domain. An example is illustrated in Fig 6, which includes a number of fields for completion by the relevant person at the employer. Some of those fields are free text fields (such as those for inputting details relating to the position held by the employee, the employment location, the referee's name, a job role description, areas for commendation or for improvement, the reason for leaving, any further comments, whereas others are fixed fields, requiring a standard format response, such as the dates of employment, the employer's NI number, their date of birth. Other fields may be completed by selecting one of a few possible set answers, for example in a Yes/No or Excellent/Good/Satisfactory/Poor format, for fields relating to timekeeping, attendance, reliability, suitability for working with vulnerable people, etc. Once uploaded, the reference can optionally be verified by a more senior person at the employer (e.g. the person responsible for the provider account). Until the reference is verified, it will remain invisible in the subject domain. Once verified, the reference becomes visible (to those having access) in the subject domain.

Once visible, the reference can be checked by the employee and if they consider it to be inaccurate or unfair they can appeal to the employer. The reference would then be reviewed and possibly amended. If the employer refuses to amend the reference, then the employee has the option of hiding the content of the reference in the subject domain. However, the period of employment will be accounted for.

With reference to Fig 3, when the subject party seeks future employment, they can provide access to the subject domain to a referrer (a prospective employer or agency) by logging in to the subject domain so as to grant temporary access by setting up a referrer access password and communicating it to the referrer, for example by email. As with the provision of the provider access password, this step will typically be instigated by the subject party, for example by clicking on a Create Recruiter Access' button in the subject domain, but the actual generation and delivery of the access password will then be done automatically by the system. The referrer access password will typically be valid for a limited period only.

Before being able to access the subject domain, the referrer would have to create their own account with the system if they do not already have one. As with the provider account, the referrer will be prompted to provide data, which will typically include: the name of the referrer organisation; their address, including post code; referrer contact details, such as fax and phone numbers and an email address; the name of a person responsible for the referrer account, such as the HR manager, and their contact details; and payment details, which may include bank account numbers and/or card numbers. The payment details are required where a fee is chargeable by the InfoBank service for the referrer party's use of the system.

Once set up, the referrer can thus access the subject domain in order to check on the subject's employment history, references, qualifications, CRB certificate, etc). in a convenient, secure, centralised store.

Most conveniently, the sources of the information stored in the subject domain can be verified in an automated manner because when the data is uploaded it is automatically assigned with an identifier token (or verification code') that is unique to the party uploading the data.

One example of a way to generate a unique verification code for each provider party is shown in Fig 8. The verification code is here generated from components comprising the provider's post code, some dummy digits to standardise the length of the post code, the last four numbers of the provider's registered payment card, and a check digit. Those verification components are then scrambled, preferably with a pseudo-random algorithm, to generate a standard length verification code. That verification code will uniquely identify the associated provider.

Accordingly, when the provider uploads information to the subject domain, it is automatically and irreversibly stamped' with the verification code. Therefore, when a referrer looks that information up, they are given the verification code, which can be input into the system, either manually or automatically, in order to verify that the source of the information is indeed the provider, as asserted.

The verification code is visible only to the referrer party. The reason being that if the subject party could see and/or print it, they could detract from the value of the system by providing recruiters with a copy of the reference and the means of verification.

In the above example, the reference was uploaded by the provider party directly to the subject domain after receiving a request to do so from the subject party. It will be understood, however, that the reference may instead be uploaded to the subject domain indirectly, by first being hosted at a holding domain. This allows the employer to upload a reference as a matter of course without the need first to obtain an invitation from the employee.

In particular with such an indirect uploading route, when a reference is loaded to InfoBank, it will be "tagged" with the erstwhile employee's "tag". Thus, when a referrer party has logged in, they can conduct (or the system may automatically conduct) a search and locate any reference that has been "stored" by a former employer.

The following illustrative example will set the invention in a more specific context.

ILLUSTRATIVE EXAMPLE

The London Borough of Walton have elected to use InfoBank to deal with their References and Safeguarding.

Walton log in to InfoBank and create a Provider Account using their: Official Name Post Code (Main Address) Contact Name and declared Title (e.g. Head of HR) Payment Details At the same time creating a password.

Alice Springs is a Locum Social Worker engaged at the London Borough of Walton.

At the start of her assignment, Alice is asked to create a Subject Domain on InfoBank using her; Name NI Number

DOB

At the same time creating a personal access password.

The Subject Domain can also show Alice's professional qualifications, verifications, registrations, CRB Disclosure details and a shod personal

statement.

Sometime later, Alice's assignment at Walton reaches its end. As part of the exit procedure, Alice is requested to log into InfoBank and create a Provider Upload Access Password with an agreed lifespan (e.g. two weeks).

Alice's line manager (or other) is then able to log in to the Subject Domain (using the Provider Upload Access Password) and upload a Reference to Alice's Domain. To prevent abuse of the system, at this point the reference is "unconfirmed" so remains "invisible". A request is generated for HR (or other authorised officer of the provider) to validate the reference. This is done by the relevant party logging into the Subject Domain (again using the Provider Upload Access Password) and validating the reference using the Provider Account Contact & Password. The reference may now be viewed by third parties.

Alice may now view the reference and, if she considers it unfair, make an appeal to Walton. If they are unwilling to amend the reference, then Alice may "hide" the content, but the period of her employment at Walton will remain visible and verified, along with her qualifications, etc. Alice applies for a position at Newgay Council. She simply creates and supplies to Newgay her Subject Domain and a Referrer Access Password with an agreed lifespan (e.g. two weeks).

Newgay log in to InfoBank and create a Referrer Account using; Official Name Post Code (Main Address) Contact name (e.g. Head of HR) Payment Details At the same time creating a password.

Newgay then log in to Alice's Subject Domain and view the entire of Alice's available reference portfolio showing a minimum of: her Employer names and periods of employment and, where she has not exercised a "block", all references will be available to view together with qualifications, etc.

VERIFICATION

Each uploaded piece of information (a reference in the example above) will be "stamped" with the provider's "Verification Code". The Verification code may be entered into a box on the InfoBank site and details of the "Provider" will automatically be displayed. Accordingly, the Referrer will be able to verify that the information (reference in the example) has been provided by the named provider and, if felt necessary, make contact with the provider's offices to ensure they are bona-fide.

Verification information will be taken for example from the Provider's Post Code and Payment Details and scrambled to form the Verification Code. Thus, when the Verification Code is entered into the site, it will refer uniquely to that Provider.

Thus, fraudulent entries will be exposed, if not eliminated entirely, and a trail back to the originator of any fraudulent entries would be maintained.

BENEFITS

Using the Example, the principle Benefits are as follows.

The Subject * will have a permanently maintained comprehensive and immediately accessible work history and reference portfolio.

* will achieve greater freedom of movement between employers and agencies through the removal of vetting time constraints.

The Provider * will be able to compose just one reference that can be done whist the knowledge of the employer is fresh in their mind.

* will not have to concern themselves with the storage of that information.

* will not have to repeatedly refer to HR records to satisfy future reference requests.

* will be absolved from risk of litigation by ex-employees over reference issues.

The Referrer * will have immediate access to a comprehensive reference (and information portfolio) * will saving time not having to apply for (and chase) references * will be in a position to view references prior to interview and thus save time and effort.

* will be relieved of the need to respond to subject access requests from employees demanding copies of references.

Since any of the three parties benefits from the InfoBank system, any could be charged for the use of the service. Moreover, although the specific description and example above have been given in terms of being initiated by the provider (former employer), the process could equally be initiated by the referrer party (the prospective employer) or by the subject party (the employee). Of course, once the process has been done once, subsequent uses of the system would be simpler, not least because at least the parties who have previously used the system would not need to re-enter data to establish accounts.

Whilst the principle application is aimed at those in high-level vetting situations, with the advent of Web based recruitment, it would be a logical extension to link the invention with those sites to enable a one-stop-shop solution to recruiters, enabling them to gain access to candidates reference files -and hence some background information -before going through the time-consuming interview process.

Furthermore, with the course of time, the system could become a "must have" for professionals.

There may further be scope to adapt the system to accommodate the secure

sharing of information in other fields.

Claims

CLAIMS1. A computer-implemented method of sharing verifiable information, the method comprising: receiving and storing, using a computer, data defining a subject domain pertaining to a subject party; receiving, using a computer, a request from a provider party to upload information pertaining to the subject party directly or indirectly to the subject party domain; granting access to the subject domain by the provider party; automatically, using a computer, assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; and granting access to the subject domain by a referrer party; wherein the referrer party is able to view and/or download the information pertaining to the subject party and to verify the source of that information as being the provider party by virtue of the associated unique identifier token.
2. The method of claim 1, wherein the data defining the subject domain is input by the subject party.
3. The method of claim 2, wherein the subject party inputs the data in response to a request from the provider party.
4. The method of claim 2, wherein the subject party inputs the data in response to a request from the referrer party.
5. The method of any preceding claim, including the steps of: receiving and storing, using a computer, data defining a provider party account; and generating, using a computer, the unique identifier token from at least some of said data defining the provider party account.
6. The method of claim 5, wherein the data defining a provider party account includes one or more of: a provider organisation name; a provider address, including post code; provider contact details; responsible person name and contact details; payment details, which may include bank account numbers and/or card numbers.
7. The method of any preceding claim, wherein granting access to the subject domain by the provider party includes the steps of: assigning a provider access password to the subject domain; and communicating the provider access password to the provider party.
8. The method of claim 7, wherein the provider access password is valid for a limited period.
9. The method of any preceding claim, wherein granting access to the subject domain by the referrer party includes the steps of: assigning a referrer access password to the subject domain; and communicating the referrer access password to the referrer party.
10. The method of any preceding claim, wherein a holding domain is used as a bridge between the provider party and the subject domain, such that the step of granting access to the subject domain by the provider party in fact comprises granting access to the holding domain by the provider party; and the step of storing the verifiable information and the associated unique identifier token in the subject domain in fact comprises storing the verifiable information and the associated unique identifier token in the holding domain; the method further including a step of: subsequent to a request relating to a subject domain, transferring the stored verifiable information and the associated unique identifier token from the holding domain to the subject domain.
11. A system for the sharing of verifiable information, the system comprising: a web server having programmed thereon code executable to initiate a series of steps including: creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; controlling access to the subject domain by a provider party; enabling the uploading of information pertaining to the subject party to the subject party domain by the provider party; automatically assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; controlling access to the subject domain by a referrer party; enabling the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enabling the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.
12. A computer program product comprising code uploadable to a web server and executable on the web server to facilitate the sharing of verifiable information, wherein said code includes means to: enable creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; control access to the subject domain by a provider party; enable the uploading of information pertaining to the subject party to the subject party domain by the provider party; automatically assign a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; store the verifiable information and the associated unique identifier token in the subject domain; control access to the subject domain by a referrer party; enable the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enable the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.
13. A web server having computer instructions for executing the steps of: creation of a subject domain, hosted on the server, in which is stored data pertaining to a subject party; controlling access to the subject domain by a provider party; enabling the uploading of information pertaining to the subject party to the subject party domain by the provider party; automatically assigning a unique identifier token to the uploaded information, indicative of the source of the information being the provider party; storing the verifiable information and the associated unique identifier token in the subject domain; controlling access to the subject domain by a referrer party; enabling the viewing and/or downloading of the information pertaining to the subject party by the referrer; and enabling the referrer party to verify the source of that information as being the provider party by virtue of the associated unique identifier token.