Electronic Commerce Interoperability Standard

ECIS stands for E-Commerce Interoperability Standard. an interoperability standard between service providers in decentralized web environment
What is ECIS?
- stands for Electronic Commerce Interoperability Standard
- it organize multiple e-commerce services with user agent centric mechanisms
- multiple service providers has their own service mechanism as an island
- user agent is the central point for multiple connectivities and inter-operations between service providers
- ECIS make connectivity to each service providers
- adding standard way to initiate e-commerce service request
- adding standard way to get response from service provider
Why ECIS is required?
- no standard method to exchange data between multiple service providers on the web
- no standard framework to exchange data between multiple service providers on the web
- because of above absent, current E-Commerce interoperation need complex integration and more resources.
- when user access shopping service provider(merchant)
- merchant provide their service on their own way
- merchant integrate their backend service providers internally
- no standard to inter-operate/exchange services between multiple providers.
- a new standard is required
- de-centralized
- interoperabilitable
- between multiple service providers including payment and identity service providers.
Who is Service Provider
- Banking Web Service
- Mobile App
- Identity Web Service
- Delivery Web Service
- Currency Exchange Web Service
- Shopping Web Service
Data Formats for ECIS
- JSON/XML messages can be used for ECIS
- example) IETF ECML (http://tools.ietf.org/html/rfc4112)
Protocols with ECIS
- Any protocols which is handling message based data are available
- HTTP Request/Response
- Custom URI Scheme
ECIS Sequence Diagram
- User(UA) send request payment to Shopping Mall
- shopping mall response request-token as XHTML/JSON format
- the request-token can be signed by merchant
- the token data can be formatted by ECML or JSON Web Token or others
- UA redirect the request-token to Payment Processor
- Payment processor response request-token to UA
- Payment processor need to identity user but they are unable to identity user.
- UA redirect the request-token of payment processor to Identity Provider
- Identity Provider identify user
- depends on ID providers
- Identity Provider response result as XHTML or JSON format
- the result can be signed by Identity Provider
- UA redirect the result to Payment Processor
- Payment Processor verify the result
- normally XML Signature verification can be used
- Payment Processor process payment with User
- Payment Processor response payment result
- the result can be signed by payment processor
- the formats can be XHTML or JSON
- UA redirect the result to Shopping Mall
- Shopping Mall verify the result sent from Payment Processor
- Shopping Mall deliver product/service to User
Centralized by User Agent
- between multiple service providers, the mechanism is de-centralized
- but it is User Central
- User Agent is the central point organizing decentralized operations
Considerations
- Timeouts
- Shopping Mall can not wait too much time
- but user know what is under processing
- Trust-Anchor between service providers
- Trust Each Other
- Use PKI
References
- ECML : http://tools.ietf.org/html/rfc4112
- SAML : http://en.wikipedia.org/wiki/SAML
- XML Encryption : http://en.wikipedia.org/wiki/XML_Encryption
- SAML : http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
- OpenID : http://en.wikipedia.org/wiki/OpenID
- OAuth : http://en.wikipedia.org/wiki/OAuth
Author
Mountie Lee (talk) 12:44, 27 October 2014 (UTC) PayGate (www.paygate.net)