Electronic Commerce Interoperability Standard

User Agent Central ECIS Mechanism

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

1. User(UA) send request payment to Shopping Mall
2. 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
3. UA redirect the request-token to Payment Processor
4. Payment processor response request-token to UA
   • Payment processor need to identity user but they are unable to identity user.
5. UA redirect the request-token of payment processor to Identity Provider
6. Identity Provider identify user
   • depends on ID providers
7. Identity Provider response result as XHTML or JSON format
   • the result can be signed by Identity Provider
8. UA redirect the result to Payment Processor
9. Payment Processor verify the result
   • normally XML Signature verification can be used
10. Payment Processor process payment with User
11. Payment Processor response payment result
    • the result can be signed by payment processor
    • the formats can be XHTML or JSON
12. UA redirect the result to Shopping Mall
13. Shopping Mall verify the result sent from Payment Processor
14. 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)