Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Selector Architecture Harmonization"

(Authentication Process)
(Synchronizing Card Store (Component Set))
 
(62 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
Since Selectors use most of the Higgins Components, work on harmonizing the Higgins selectors into a single architecture would be a huge step towards overall Higgins architecture harmonization/convergence.  
 
Since Selectors use most of the Higgins Components, work on harmonizing the Higgins selectors into a single architecture would be a huge step towards overall Higgins architecture harmonization/convergence.  
  
A good first step in converging the selectors is start by harmonizing the [[GTK and Cocoa Selector]] and the [[AIR Client and Server]]. Aside from UI differences, the former performs all processing locally, whereas the latter presents a local UI but relies on a hosted server. The latter has the advantage of supporting roaming of cards as well as multiple simultaneous clients. The former has performance advantages. We'd like to get the best of both worlds by having a converged architecture which synchronizes cards between the client and the server. The common code would be in a local "selector service" component that alternative UI layers can use.
+
The initial step involves harmonizing the architecture of [[GTK and Cocoa Selector 1.0]] with the architecture of [[AIR Selector 1.1-Win]] and initially implement this new harmonized architecture in [[GTK Selector 1.1-Win]].  
  
===Top Level Diagram===
+
=== Overview ===
As you can see we formalize the separation of presentation from core services:
+
 
 +
Aside from UI differences, the [[GTK Selector 1.1-Win]] performs all processing locally, whereas the [[AIR Selector 1.1-Win]] presents a local UI but relies on a hosted server. The latter has the advantage of supporting roaming of cards as well as multiple simultaneous clients. The former has performance advantages. We'd like to get the best of both worlds by having a converged architecture which synchronizes cards between the client and the server. The common code would be in a "local i-card selector service" (LICS) component that alternative selector UI layers can use. A new [[CardSync API]] would be added to the Higgins server.
 +
 
 +
==Open Issues==
 +
This is the place to capture open design issues in this project.
 +
 
 +
# In the long run if the selector UI runs in a separate process then it needs to authenticate itself to the [[Local I-Card Service]] envisioned below. We haven't yet decided how to do this.
 +
# In the long run browser plugins need to authenticate themselves to the [[Local I-Card Service]] envisioned below. We don't yet know how to do this.
 +
 
 +
== Top Level Architecture==
 +
As you can see we have formalized the separation of presentation from core services:
  
 
[[Image:Unified-selector-1.1.116.png]]
 
[[Image:Unified-selector-1.1.116.png]]
Line 17: Line 27:
 
* The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying [[Local I-Card Service]] would be common.
 
* The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying [[Local I-Card Service]] would be common.
  
==Phase 1==
 
Phased approach to implementation.
 
  
===First Steps===
 
  
The first objective is to perfectly align the existing [[Components]] with the above diagram.
+
==Local I-Card Service ==
# Jeesmon: Split the shared tcpserver project into multiple projects to align with above. Suggestions for new names:
+
#* org.eclipse.higgins.hss for http://wiki.eclipse.org/Components#Higgins_Selector_Selector_.28HSS.29
+
#* org.eclipse.higgins.hss.manager for http://wiki.eclipse.org/Components#HSS_Manager
+
#* org.eclipse.higgins.hss.launcher for http://wiki.eclipse.org/Components#Higgins_Launcher
+
#* org.eclipse.higgins.hbx.ie (NOT hbxie! (taken)) for http://wiki.eclipse.org/Components#Higgins_Browser_Extension_.28HBX.29
+
# Jeesmon: Merge the currently separate HSS connectors into .higgins.hss per the following ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258504 258504]
+
# Jeesmon: Split the AIR Selector code (org.eclipse.higgins.air ) into two project files
+
#* org.eclipse.higgins.selector.ui.air - selector UI in AIR/Flex
+
#* org.eclipse.higgins.selector.client.air (will eventually be replaced with a common .higgins.lics [[Local I-Card Service]] in C++) - selector services in AIR/Flex
+
# Split GTK/Cocoa Selector component into smaller pieces. Here's the first split:
+
#* Leave "org.eclipse.higgins.cbselector" project as-is (for Higgins 1.0 use)
+
#* Copy just the GTK-based user interface portion of .cbselector (shown in a box [http://wiki.eclipse.org/GTK_and_Cocoa_Selector#Architecture here]) into a new project .higgins.selector.ui.gtk as the first alternative implementation project within the new [http://wiki.eclipse.org/Components#Selector_UI Selector UI] component shown above.
+
#* Copy the rest of the .cbselector project into a new .higgins.lics ([[Local I-Card Service]]) component
+
# Change GTK-based Selector to use standard Higgins [http://wiki.eclipse.org/Components#Higgins_Browser_Extension_.28HBX.29 HBX]
+
 
+
== Phase 2 ==
+
 
+
 
+
 
+
===Local I-Card Service ===
+
The client side of phase 2 involves creating the .higgins.lics project by copying the "Identity Selector Service" from the .cbselector and replacing the its i-card store with an i-card cache
+
  
 
Overview:
 
Overview:
  
[[Image:Lics-1.1.121.png]]
+
[[Image:Lics-v.1.1.123.png]]
  
===I-Card Cache (Component Set)===
+
==Synchronizing Card Store ==
One possible way to implement the I-Card Cache:
+
Current design:
  
[[Image:Card-cache-1.1.117.png]]
+
[[Image:Sync-card-store.1.1.120.png]]
  
===Server Modifications===
+
== Server ==
  
A new, RESTful binding [[I-Card Sync Web App]] component would be layered over an enhanced [[I-Card Service]].
+
Implement the new [[CardSync API]] in the [[I-Card Sync Web App]] component. See below:
  
 
[[Image:Server-mods-v4.png]]
 
[[Image:Server-mods-v4.png]]
 
=== Card Sync Protocol ===
 
 
Our latest thinking is to create a new RESTful binding over the [[I-Card Service]] using JAX-RS. We have to decide on an implementation of JAX-RS. Perhaps Jersey?
 
 
[[Category:CardSyncProtocol]]
 
 
==== Data Transfer objects ====
 
 
[[Image:Org.eclipse.higgins.rpps.sync.ClassDiagram.jpg|800x400px]]
 
 
 
=====AccessTokenTO=====
 
public class AccessTokenTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br>
 
<br>
 
 
AccessToken transfer object. See [[Selector_Architecture_Harmonization#Authentication]]
 
 
private  java.lang.String id          Represents token identifier.
 
private  java.util.Date issuedTime  Represents issued date time.
 
private  java.lang.Integer maxIdleTime Represents max idle time in seconds.
 
 
=====BaseTO=====
 
 
public class BaseTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br>
 
<br>
 
Base transfer object. All resources should extend it. <br><br>
 
 
private  java.lang.String id          Represents unique resource server identifier.<br>
 
private  RevisionTO         revision    Represents revision information.<br>
 
 
===== RevisionTO =====
 
public class RevisionTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Resource revision transfer object. <br>
 
 
private  java.util.Date modifiedTime          Represents last modified date.<br>
 
private  java.lang.Long number                Represents revision number.<br>
 
 
===== CardTO =====
 
public class CardTO
 
extends BaseTO
 
implements java.io.Serializable
 
 
Card transfer object. <br>
 
 
private  java.lang.String cardId          Represents card identifier.<br>
 
private  ClaimTO[]         claims          Card claims.<br>
 
private  java.util.Date expiredTime    Card expired date.<br>
 
private  CardExtensionTO[] extensions      Card extensions.<br>
 
private  byte[]         hashSalt        Card hash salt.<br>
 
private  byte[]         image          Card image.<br>
 
private  java.lang.String imageType      Card image mime type.<br>
 
private  java.util.Date issuedTime      Issued(created) time.
 
private  java.lang.String issuer          Card issuer name.<br>
 
private  byte[]         issuerID        Card issuer identifier.<br>
 
private  java.lang.String issuerName      Human friendly card issuer name.<br>
 
private  java.util.Date lastUpdatedTime Last card updated date.<br>
 
private  byte[]         masterKey      Card master key.<br>
 
private  java.lang.String name            Human friendly card name.<br>
 
private  java.lang.Boolean selfIssued      Is card self issued.<br>
 
private  ClaimTypeTO[]         supportedClaimTypes  Represents array of all possible types of claim that are supported.<br>
 
private  java.lang.String[] supportedTokenTypes  Represents arrays of token types which can be provided for this card.<br>
 
private  java.lang.String version        Card version.<br>
 
 
===== MCardTO =====
 
public class MCardTO<br>v
 
extends CardTO<br>
 
implements java.io.Serializable<br><br>
 
 
Managed card transfer object. <br>
 
 
private  java.lang.String ic07IssuerInformation          Represents /ic07:IssuerInformation extension element<br>
 
private  java.lang.Boolean requireAppliesTo                Represents requireAppliesTo card element.<br>
 
private  java.lang.Boolean strongRecipientIdentityRequired Represents /ic07:RequireStrongRecipientIdentity extension element If true than Selector MUST only allow the card to be used at a Relying Party that presents a cryptographically protected identity X.509v3 certificate.<br>
 
private  StsPrivacyPolicyTO stsPrivacyPolicyTO              STS/IdP privacy policy<br>
 
private  TokenServiceTO[] tokenServices                  Represents array of security token services.<br>
 
 
===== PCardTO =====
 
public class PCardTO<br>
 
extends CardTO<br>
 
implements java.io.Serializable<br><br>
 
 
Personal card transfer object. <br>
 
 
private  byte[] pinDigest          Contains the base64 encoded bytes of the SHA1 hash of the pin code<br>
 
 
===== ClaimTO =====
 
public class ClaimTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Card claim transfer object. <br>
 
 
private  ClaimTO[]         claims              Contains sub-claims if claim is complex claim.<br>
 
private  ClaimTypeTO         claimType          Represents claim type<br>
 
private  ClaimUiDescriptor claimUiDescriptor  Represents meta information for building user friendly claim editor.<br>
 
private  java.lang.String[] values              Represents claim values.<br>
 
 
===== ClaimUiDescriptor =====
 
public class ClaimUiDescriptor<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Claim user interface descriptor transfer object. Has meta information for building user friendly claim editor. <br>
 
 
private  java.lang.String inputMask          Might contain input mask for formating claim value on client side.<br>
 
private  java.lang.String[] optionalValues    Should contain possible optional values If type equal 4 (TYPE_COMBOBOX ).<br>
 
private  java.lang.String pattern            Might contain regular express for validating user input on client side.<br>
 
private  java.lang.String type              Defines claim editor type. 
 
<ul>
 
<li>TextField GUI component type TYPE_TEXTFILED = 0;</li>
 
<li>TextArea GUI component type TYPE_TEXTAREA = 1;</li>
 
<li>FileChooser GUI component type TYPE_FILE = 2;</li>
 
<li>CheckField GUI component type TYPE_CHECKBOX = 3;</li>
 
<li>ComboBox GUI component type TYPE_COMBOBOX = 4;</li>
 
<li>Date(time) GUI component type TYPE_DATETIME = 5.</li>
 
</ul>
 
<br>
 
 
===== ClaimTypeTO=====
 
public class ClaimTypeTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
ClaimType transfer object. <br>
 
 
private  java.lang.String description          Represents description.<br>
 
private  java.lang.String displayName          Represents the human friendly name.<br>
 
private  java.lang.Boolean isSimple            Determines whether corresponding IClaim is simple or complex.<br>
 
private  java.lang.String type                Represents type URI.<br>
 
 
===== CardExtensionTO =====
 
public class CardExtensionTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
CardExtension transfer object. <br>
 
 
private  java.lang.Boolean enabled                      Is extension enabled.<br>
 
private  java.lang.String extensionXmlElement          Represents extension element data.<br>
 
 
===== StsPrivacyPolicyTO =====
 
public class StsPrivacyPolicyTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
STS/IdP privacy policy transfer object.<br>
 
 
private  java.lang.String url          STS/IdP privacy policy url.<br>
 
private  java.lang.String version      STS/IdP privacy policy version.<br>
 
 
===== TokenServiceTO =====
 
public class TokenServiceTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Token service transfer object. <br>
 
 
private  EndpointReferenceTO         endpointReference  Represents Token Service endpoint.<br>
 
private  CredentialDescriptorTO userCredential    Represents Token Service credential.<br>
 
 
===== CredentialDescriptorTO =====
 
public class CredentialDescriptorTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Token service credential descriptor transfer object. <br>
 
 
private  java.lang.String credentialXmlElement          Represent xml element.<br>
 
private  java.lang.String displayCredentialHint        Represent user friendly credential hint.<br>
 
private  java.lang.String type                          Represent credential type.
 
<ul>
 
<li>SelfIssuedCredential;</li>
 
<li>X509V3Credential</li>
 
<li>KerberosV5Credential</li>
 
<li>UsernamePasswordCredential</li>
 
</ul><br>
 
 
===== EndpointReferenceTO =====
 
public class EndpointReferenceTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Token service Endpoint reference transfer object. <br>
 
 
private  java.net.URI         address          Represents address.<br>
 
private  java.lang.String identityXml      Represents Identity element of TokenService.<br>
 
private  java.net.URI         metadataAddress  Represents Metadata Address URI if Metadata contains it.<br>
 
private  java.lang.String metadataXml      Represents Metadata element of TokenService.<br>
 
 
===== CardHistoryTO =====
 
public class CardHistoryTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
Card history transfer object. <br>
 
 
private  java.util.Date   date          Represents date time of card usage.<br>
 
private  WebFormTO         form          Represents html web form elements.<br>
 
 
===== WebFormTO =====
 
public class WebFormTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Web form transfer object. <br>
 
 
private  java.lang.String formAction          Represents html form action element.<br>
 
private  java.lang.String formId              Represents html form id element.<br>
 
private  java.lang.String formName            Represents html form name element.<br>
 
private  java.net.URI         url                Represents web page URL.<br>
 
 
===== CardCategoryTO =====
 
public class CardCategoryTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
Card category transfer object. <br>
 
 
private  java.lang.String[] cuids          Represents associated card id array.<br>
 
private  int                 idx            Represents category index.<br>
 
private  java.lang.String name          Represents category name.<br>
 
private  java.lang.String parentId      Represents parent category identifier.<br>
 
private  java.lang.String type          Represents category type.<br>
 
 
===== UserProfileTO =====
 
public class UserProfileTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
User profile transfer object. <br>
 
 
private  java.util.Date createdTime          Represents user account created date.<br>
 
private  java.lang.String email                Represents user email address.<br>
 
private  java.lang.String firstName            Represents user first name.<br>
 
private  java.lang.String lastName            Represents user last name.<br>
 
private  java.lang.String loginName            Represents user login name.<br>
 
private  java.lang.String mobile              Represents user mobile number.<br>
 
private  java.util.Date modifiedTime        Represents last updated date.<br>
 
 
===== CardCredentialTO =====
 
public class CardCredentialTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
Card credential transfer object. <br>
 
private  java.lang.String credentialType          Represent credential type.<br>
 
 
===== UsernamePasswordCredentialTO =====
 
public class UsernamePasswordCredentialTO<br>
 
extends CardCredentialTO<br>
 
implements java.io.Serializable<br><br>
 
 
UsernamePasswordCredential credential transfer object. It needs for supporting auto-login. <br>
 
 
private  java.net.URI         tsAddress          Represents STS/IdP addres.<br>
 
private  java.net.URI      tsMetadataAddress  Represents STS/IdP meta address<br>
 
private  java.lang.String username          Represents username.<br>
 
 
===== PinCredentialTO =====
 
public class PinCredentialTO<br>
 
extends CardCredentialTO<br>
 
implements java.io.Serializable<br><br>
 
 
PinCredential transfer object. <br>
 
 
private  byte[] pinCode          Represents pinCode.<br>
 
 
===== UseAlwaysTO =====
 
public class UseAlwaysTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
UseAlways transfer object. It needs for supporting auto-login. <br>
 
 
private  WebFormTO form          Represents html web form elements.<br>
 
 
===== CaptchaTO =====
 
public class CaptchaTO<br>
 
extends BaseTO<br>
 
implements java.io.Serializable<br><br>
 
 
Captcha transfer object. It needs for password-reset workflow.
 
 
private  byte[] image          Captcha image.<br>
 
 
===== OperationTO =====
 
public class OperationTO<br>
 
extends java.lang.Object<br>
 
implements java.io.Serializable<br><br>
 
 
Log operation transfer object.
 
 
private  java.lang.String name              Represents operation/command name. It will be one of the following constants:<ul>
 
<li>Persist</li>
 
<li>Delete</li>
 
<li>DeleteAll</li></ul>
 
private  BaseTO         resource          Represents resource. It might be null for "Delete".
 
private  java.lang.String resourceId        Represents server resource identifier. It might be null for "DeleteAll".
 
private  java.lang.String resourceType      Represents resource type.
 
 
==== Exceptions ====
 
it'll be soon.
 
 
==== Authentication ====
 
Almost all Card Sync Web App methods requres user authentication (excepts addUserProfile, getPasswordResetCode etc).
 
These diagrams  illustrate the sequence of interactions between Local ICard Selector and Card Sync Web App.
 
[[Image:AuthenticationUSD.jpg|790x400px]]
 
[[Image:AuthenticationULD.jpg|790x400px]]
 
 
=====Authentication Process=====
 
1. Get Access Token (Sign on). See [[Selector_Architecture_Harmonization#AccessTokenTO]]<br>
 
1.1 Local ICard Selector contacts the Card Sync Web App, asking for AccessTokenTO by using username/password credential getAccessToken(userIdentifier,password).<br>
 
1.2 Card Sync Web App invokes authenticate(userIdentifier, password) Card Sync Service method. <br>
 
1.3 Card Sync Service delegate authentication to ILoginService (JAAS).<br>
 
1.4 if ILoginService may  authenticate user it return UserAccout instance (it needs for accessing protection data).<br>
 
1.5 Card Sync Web App  invokes  buildAccessToken(userAccount) Card Sync Service method for generating  AccessToken.<br>
 
1.6 Card Sync Service builds and stores AccessToken.<br>
 
1.7 Card Sync Web App return AccessTokenTO to Local ICard Selector.<br>
 
<br><br>
 
2. Get user protected data.<br>
 
2.1  Local ICard Selector asking  Card Sync Web App for protected data by using Access Token Identifier (AccessTokenTO.id).<br>
 
2.2  Card Sync Web App delegate validation of  Access Token Identifier to Card Sync Service  checkAccessToken(AccessTokenTO.id).<br>
 
2.3 if  Access Token Identifier is valid Card Sync Service return AccessToken.<br>
 
2.4 Card Sync Web App retrieve protected data by using  AccessToken.<br>
 
2.5 Card Sync Web App return  protected data to Local ICard Selector.<br>
 
<br>
 
3. Delete Access Token (Sign out).<br>
 
3.1  Local ICard Selector has to invoke deleteAccessToken(AccessTokenTO.id) Card Sync Web App method.<br>
 
3.2 Card Sync Web App delegates it to Card Sync Service by using  deleteAccessToken(id) method.<br>
 
 
----
 
 
=====Pass Access Token Identifier with HTTP header "access_token"=====
 
We're going to support Rest API for synchronizing user cards. It assumes to use http GET requests for retrieving protection data, so it has to include  Access Token Identifier to request url. if we  pass  Access Token Identifier  by using http header, it may be more protected way (with https). 
 
 
Both Rest and Soap web services would read access token from http headers.
 
 
=====Encrypt/Decrypt  Access Token Identifier=====
 
We would encrypt Access Token Identifier  by using public user key (on server side) and public server key (on client side) for prevent unauthorized access.
 
 
=====Access Token max idle time=====
 
if Access Token wasn't used  more than max idle time, it will be deleted automatically.
 
 
=====Single sign on =====
 
We would support single sign-on/sign-out workflow. it makes sense by secure reason ( and it may be useful for r-card solution).
 
 
===== Authentication with OpenId, X509Certificate, ...=====
 
For supporting new authentication type we have to add just one method getAccessToken( credential data ).
 
 
==== JAX-RS API ====
 
it's in progress.
 
===== Resources =====
 
it's in progress.
 
 
====== MCard ======
 
====== PCard ======
 
====== CardHistory ======
 
====== CardCategory ======
 
====== CardCredential ======
 
====== UseAlways ======
 
====== UserProfile ======
 
 
=====  WADL =====
 
===== Serializable formats =====
 
 
====== XML(application/xml) ======
 
====== JSON(application/json) ======
 
 
====== Google protobuf (application/x-protobuf) ======
 
http://code.google.com/p/protobuf/
 
====== X3 (application/x3) ======
 
 
==== JAX-WS API ====
 
it'll be soon.
 
===== WSDL =====
 
===== Serializable formats =====
 
====== SOAP (application/soap+xml) ======
 
 
====Sequences ====
 
===== Synchronize card=====
 
===== Synchronize card history =====
 
===== Synchronize card category =====
 
===== Synchronize user profile =====
 
 
 
 
 
[[Synchronized Card Store]]
 
 
== Phase 3 ==
 
This phase is about adapting the [[AIR Selector]] to the new architecture.
 

Latest revision as of 10:20, 6 July 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Since Selectors use most of the Higgins Components, work on harmonizing the Higgins selectors into a single architecture would be a huge step towards overall Higgins architecture harmonization/convergence.

The initial step involves harmonizing the architecture of GTK and Cocoa Selector 1.0 with the architecture of AIR Selector 1.1-Win and initially implement this new harmonized architecture in GTK Selector 1.1-Win.

Overview

Aside from UI differences, the GTK Selector 1.1-Win performs all processing locally, whereas the AIR Selector 1.1-Win presents a local UI but relies on a hosted server. The latter has the advantage of supporting roaming of cards as well as multiple simultaneous clients. The former has performance advantages. We'd like to get the best of both worlds by having a converged architecture which synchronizes cards between the client and the server. The common code would be in a "local i-card selector service" (LICS) component that alternative selector UI layers can use. A new CardSync API would be added to the Higgins server.

Open Issues

This is the place to capture open design issues in this project.

  1. In the long run if the selector UI runs in a separate process then it needs to authenticate itself to the Local I-Card Service envisioned below. We haven't yet decided how to do this.
  2. In the long run browser plugins need to authenticate themselves to the Local I-Card Service envisioned below. We don't yet know how to do this.

Top Level Architecture

As you can see we have formalized the separation of presentation from core services:

Unified-selector-1.1.116.png

Notes:

  • We introduce the notion of a "Component Set" -- a set of components
  • This architecture would run on Windows, Mac OSX, Linux and (with further work) potentially smart phones
  • The "Selector UI" component would be either GTK, Cocoa or AIR-based, but the underlying Local I-Card Service would be common.


Local I-Card Service

Overview:

Lics-v.1.1.123.png

Synchronizing Card Store

Current design:

Sync-card-store.1.1.120.png

Server

Implement the new CardSync API in the I-Card Sync Web App component. See below:

Server-mods-v4.png

Back to the top