New Page 1

JPass is a web service for web services. Confused? This document will enlighten you on what is meant. The JPass web service deviates from what is commonly understood about web services. It however is a web service, because it is defined and accessible using open web services technologies. One of the differences is however, that the JPass web service is only accessed when the user authorize access by means of a master password. Another difference is that the web service is running on the Users PC (At home or work) and is maintained by the user. No external instance, will manage your valuable information. When subscribing to a web service. the jpass web-service will create a new web-service profile and attach a web-service pseudonym to it.

Like me, you probably registered on a zillion websites, and perhaps have no idea when and where you you did it. JPass keeps track for you, you can do it manually or you can do it automatically if the web service supports the JPass Client. For each website/service a new web-service profile is created. Attached to the web service profile is the web-service pseudonym. This can be your real identity or some identity you made up. This might seem controversial functionality, but hey.... everybody fakes identities on the web and NOway M$ is going to manage my real identity right? When accessing the service you will log-on using a web service profile (WSP) which has been created (automatically) for this service. JPass will keep a log on, when you created the web service profile and when you logged on.

That's what I have been asking myself as well and my conclusion sofar is big YES. Why? it's simple, JPass compatible websites/services will offer additional ease of use. The user will be able to register and logon quickly, and manage the registration during the use of the service. The user will even be able to un-register. Many countries have laws on privacy and user should be offered the possibilities to un-register to a service and ask to remove personal information. So why not automate this process?

The service provider will receive the Web Service pseudonym return from the JPass Server. The interaction between the JPass Client and the JPass web service is the JPass client API. The JPass Client API is described further on.

// Need to look at security issues when the JPass client is embedded in the Web service. This could be solved by encrypting the // password with a private key by the client. The JPass server having the public key, will be able to decrypt and authenticate // the user. (similiar to how ssh works). Secure SOAP could perhaps also take care of this. This would prevent the web-service // from hijacking the JPass session and capturing the Master password.

The JPass services are offered using web services technologies SOAP, XML and WSDL. The SOAP protocol is the messaging method which calls/activates jpass services deployed on a JPass server. XML is used within SOAP to transfer JPass data and in the clients and servers to store and manipulate the data. WSDL is used to describe the JPass Service and make it available to public web services registries.

The JPass Data contains information about websites/services and registration details. The principle data structure is called a "web service Profile". The complete web service Profile data structure is defined in the XML Schema:

Web service profiles or components can be added, modified, retrieved etc..... In order to manipulate the web service profiles, several methods have been defined on the JPass Server.

Accessing the WSP database is done by the user and no one else, and can there for only be accessed with a master User & password.

Additional security options like, Authentication are being considered. (Signatures and Certificates).

As JPass uses SOAP to activate methods, each method will have a predefined SOAP message. procedures for registration of new webservices an logon to a webservice will use the one or more methods below. The SOAP messages correspond to the JPass Service methods.

The methods on the server can be defined as SOAP message calls or RPC calls. The SOAP messages are send to a user defined server in the JPass client.

JPass SOAP method	JPass object		SOAP Envelope schema	Description
	Send	Result
getWSPlist	jpassUser.xsd, wsData.xsd	wsProfileList.xsd	getWSPlist.xsd	Request a list of WSP's from the JPass server.
findWSP*	jpassUser.xsd, wsProfile.xsd	wsProfile.xsd, null	findWSP.xsd	search for a WSP in the WSP list in the JPass server
getWSP	jpassUser.xsd, wsProfile.xsd	wsProfile.xsd	getWSP.xsd	Request a specific WSP using a WSP index from the JPass server.
addWSP	jpassUser.xsd, wsData.xsd	wsProfile.xsd	addWSP.xsd	Add a WSP to the list of this user
deleteWSP	jpassUser.xsd, wsProfile.xsd	-	deleteWSP.xsd	delete a WSP to the list of this user
logWSP	jpassUser.xsd, wsLog.xsd	-	logWSP.xsd	log a webservice entry in the WSP
setStatusWSP	jpassUser.xsd	-	setStatus.xsd	Change the WSP status to active/de-active

<?xml version='1.0'?>
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://jpass.sourceforge.net"
            xmlns="http://jpass.sourceforge.net"
            elementFormDefault="qualified">
    <xsd:element name="getWSPlist">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element ref="Master_User" />
                <xsd:element ref="Master_Password" />
                <xsd:element ref="wsData" />
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>

    <xsd:element name="Master_User" type="xsd:string"/>
    <xsd:element name="Master_Password" type="xsd:string"/>

    <xsd:element name="wsData">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element ref="URL"/>
                <xsd:element ref="ServiceCharge"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>

    <xsd:element name="URL" type="xsd:anyURI"/>
    <xsd:element name="ServiceCharge" type="xsd:string"/>

Validation of SOAP message XML. The SOAP messages can be validated against their respective message schema. Validation by the client prior befor sending is advised (Is it?)

Further development will include un-register from a webservice. This actually doesn't remove the WSP, but changes the status to passive.

When visiting a website/service for the first time, the user will often be access to register. The registration process with jpass will invoke the following SOAP messages:

Check if the User has already registered on the website (Always OK to do right?) If no WSP is found the user gets the option to create a new WSP. if , there is a WSP. The webservice will use the method getWSP and check if it's active.

Before addind the newWSP, the User get the option to get or register a new WSPpseudnyme

The added WSP is logged, the Webservice will provide the wsData object which contains information about the web service like URL, Category , Keywords, Country etc.....The wsData object is defined earlier.

The flowdiagram below describes the interaction between the Jpass client, the Web Service and the JPass Server.

When accessing a website/service the User will be asked to enter a valid Master UserID and Password an JPass Server.

the WSP is matched against the users collection of WSP's (WSPList). if the WSP is found the JPass server returns the WSP index to the calling web service. The WSP contains the WSP pseudonym which will be used to login to the web service.

If the webservice accepts the user, a log entry will be sent to the JPass Server.