The Signed 2.2.1 module allows users to generate signed signatures for identification using various identity fields that are stored and verified. It includes an API for signing documents and verifying signatures. The module needs to be translated into other languages before final release. Translators should replace the English language files.

1. Signed 2.2.1 Final Candidate
Translation Project
XOOPS Project ~ Modules
by Simon A Roberts (wishcraft)
wishcraft@users.sourceforge.net
simon@staff.labs.coop
Table of Contents
Function of Module..................................................................................................................................2
Signing API Functions.........................................................................................................................3
Signing API Fields..........................................................................................................................3
Download XOOPS Module......................................................................................................................4
XOOPS Module - Signed.........................................................................................................................5
Signed Features...................................................................................................................................5
Signed Description..............................................................................................................................6
Signed Module - Translation Project........................................................................................................7
Folders to be Translated......................................................................................................................7
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 wishcraft@users.sourceforge.net

2. Translation Project: Signed 2.2RC
Function of Module
The module signed 2.2RC is an identification card presenter and signer; what it does
is allow your users in XOOPS (Or Adapted Platforms) to generated a signed
signature based on their government and organisation identification and
serialisation.
It will go through a process for the individual or organisation which will allow for a
system of identity documents, expiry dates and serial numbers to be uploaded and
catalogues as well with all the options included, verified email addresses as well as
mobile numbers (Uses www.cardboardfish.com for SMS Gateway); also with a slight
adjustment the messaging system on internal office phones with voip numbers in
the same services.
Once the signature is all generated and all the identity is verified as well as details,
the signer will send the LABSCOOP-DS 1.03 signature certificate (*.crt) as well as
their 3x3 code and the identify signature serial number via verified email.
Once they have this detail any website using signed to verify a psuedo-legal binding;
where normally sites will ask for Intials, Full Name and Date.. But this isn't a correct
legally binding signature online, it needs the signature to be on the peer any signing
requires peer reviewing.
When a site instead needs too have something signed online; so these sites would
instead ask for the URL where the signature is store' it this would be for example:
https://network.ringwould.com.au and then they would be asked for a prompt
which is called: Class One, and a second text-box that is for Class One/Two which
uses the following API Call: Signing API Functions ~
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop

3. Translation Project: Signed 2.2RC
Signing API Functions
To use the Signing API functions the API works with a typical API REST
system with either form POST/GET variables, the URL for the signing
functions on the API is:~ https://network.ringwould.com.au/signing/sign/
Signing API Fields
The required fields to use the signing API function are the following, they must be included and not empty:~
{"docid":"your­documents­unique­session­id:string","doctitle":"your­
document­title:string"}
Class one of the identity fields for signing API function are the following if you are only using identity class
one, you only need two or more of these if you are only using this basis to identify with class one, any less
than two will flag an error:~
{"serial­number":"serial­number­from­signature­
xml:string","code":"signature­3x3­from­
email:string","certificate":"signature­certificate­from­
email:string"}
Class two of the identity fields you can use with one of class one and one of these fields for signing API
function as class two, you can only use these if you specify one of the previously mention fields as in: serial-
number, code, certificate. These fields are dynamic they allow you to enter one of any of that field type
recorded in the signature, you need one of these in identity class two and one from identity class one:~
{"any­name":"personal­or­entity­name:string","any­email":"any­email­
in­signature:string","any­date":"dob­or­dor­in­signature:yyyy­mm­dd"}
These fields are for signing API callback functions, you will need to specify all the fields if your going to use it or
obmit it if your system doesn't require notice of expired signature or updates to identification:~
{"callback­url":"your­url­for­the­api­to­call:string","signature­
package­field":"field­for­the­api­to­put­signature­package­
in:string","doc­identity­field":"field­for­the­api­to­put­document­
identity­in","signature­updated­field":"field­for­the­api­to­put­
updated­boolean­flag­in:string","signature­expiry­field":"field­for­
the­api­to­put­expired­boolean­flag­in:string"}
Once they have provided a detailed call for the API Function listed above, the
signer will provide all the identification documents and images (randomly
watermarked) from the signature where the site if they are auditing there is
functions on the API called: Signature Data or Image Update Requests API
Functions which will use the call-back which is on some of the functions and
temporarily unsigned anything they have signed if any of the documents look
false or are a random image etc.
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop

4. Translation Project: Signed 2.2RC
Until the signee with the signature signing the document updates their
identification on the signature if it has expired or is the wrong image; anything
they have signed which is on call-back would have temporarily unsigned, which
is good for governments as it means if someone is for example deceased and
you wanted to extend it you could use the call-back API to unsigned everything
they have signed in life-time but for the moment this is only when they need
data or image update on a signature using the serial number the first API
function called: Signing API Function also provides on a document signature
confirmation call result set of the API.
There is a whole series of API functions on the API you can for example see
these at: https://network.ringwould.com.au/signing there is also where if
another peer needed for legal argument confirm something is definitely signed
on your site like a chamber or auditor; they will be able use the signature
confirmation hash and the document id provided on signature to verify the state
of a signed document.
There is so many signatures in the world; they can not be stored by any one
source or site; companies for example may have several per person as well as
other types of signature certificates. This is the provider of the need for peer-to-
peer reviewing of signatures; that is a third party that is a composite signature
provider in signing a document in-law with international and nation like a
witness to a conventional signature on a contract!
Download XOOPS Module
To download the module use on of the link for the file varients below:-
~~~::[ *.7z ! *.rar ! *.tar.gz ! *.tar.bz2 ! *.zip ! *.iso ! *.exe ! *.war ! *.ear ]::~~~
XOOPS SVN: https://sourceforge.net/p/xoops/svn/HEAD/tree/XoopsModules/signed/
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop

5. Translation Project: Signed 2.2RC
XOOPS Module - Signed
XOOPS signed 2.2RC ~ Final Major Release Candidate
Pseudo~legal Document Binding Online - With Discoverable API!
Demo: https://signed.ringwould.com.au
~ Release forum thread for updates and reviews and contributions ~
http://xoops.org/modules/newbb/viewtopic.php?post_id=359530
Signed Features
These are just a few of the numerous unmentioned features of this module which comes
around 5Mb archived of PHP Source code as a XOOPS Module some of the features
include:-
• Revolving File Key Store
• Identification Storage and Capture
• Full Right to view Suffix and Prefix names
• Individual Signatures
• Organisational Signatures
• Transposition File Store - No Database
• Discoverable API
• Multi-lingual (Translation Required)
• Unsigning/Resigning Call-back API
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop

6. Translation Project: Signed 2.2RC
Signed Description
Time and time again I come by these websites that require an online authentication
like identification of you as an individual or business this is also true of SSL Signing.
The only thing is they only seem to verify email addresses, never ask you for any
identification and rarely have any versification system. Self signed is based on the
protomodel – https://signed.ringwould.com.au but for XOOPS 2.5. This comes with
an API that allows for a class one only or class one and class two self identification
on the API then provides to them in the format they require (JSON, Serialisation or
XML) your full signature.
This could be from your 3x3 code with an email address or a date it contains, it also
comes with a root certificate much like an SSL certificate. The receptacle of the
Signature data, has method and a call back to be notified when the signature if it
does expire or someone else has checked the attached identification that the signee
has scanned in and loaded into your environment and flag it for renew or
incorrectly uploaded which temporarily if not on a time delay ends the ability for
that signature to be valid.
I see this as a clear path too something like httpx:// a self signed with peer-
reviewing communication method that is completely open and true law based
pseudo-sciences no like the like current SSL which only seems to check and email
address and has a master key as well, self signing is the way of the future and
explicative to the environment of open renderment of open source and the
communities with software and network layer dependencies in our object
orientated world and people.
This includes an API that allows for signature bases to be unsigned if someone's
identification fails check standards; through call-backs and API which is part of the
system!
Yes we have heard of people with signed generating other
certificate sequences just with the I­Ching XCP Checksum laid as
so as the code is now just in the length it is and it
dilettantes+divinates the lock for the certificate... yes yes
that all true dsh country­by­country license to kill certificate!
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop

7. Translation Project: Signed 2.2RC
Signed Module - Translation Project
This module is to be translated in the supporting groups for final candidate
packaging for the XOOPS SVN, once you have done the translation the translated
signature files as well as the language files have to be package and sent to
simon@staff.labs.coop with any comments or changes that needed to happen
outside any core language folded file-base.
You can connect to the Author of the module with Skype on the account:
antony.cipher – this is if you have any question or comments for the module!
Please notify either by email and wait for confirmation as a translator, as you will
eventually once final packaging being done noted in the code stamp as one of the
authors; which you can also do in the resource files.
Folders to be Translated
The following folders are the ones for the 'english' language type; you will need to
translate these into the language folder descriptor found in the signed 2.2RC
archive:-
xoops2.5_signed_2.2RC
+ modules
| + signed
| + language
| + english (translate folder)
+ xoops_lib
+ modules
+ signed
+ processes
+ english (translate folder)
Signature Typals + Language for Final Packaging Simon Antony Roberts ~ Chronolabs
04/11/15 18:30:21 simon@staff.labs.coop