2009년 12월 22일 화요일

한국형 전자상거래 서비스 제공자간 상호연동 표준안(KECIS)

한국형 전자상거래 서비스 제공자간 상호연동 표준안

Korea Electronic Commerce Interoperability Standard

(분산환경에서 서비스 제공자들간의 상호 연계를 위한 데이터 송수신 표준 구조)




1. KECIS가 왜 필요한가?

- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "방법" 부재
- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "구조" 부재
- 위 "부재"로 인해 서비스 연동을 위한 중복된 Resource 소모, 복합적인 서비스 연계 불가

- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.


==> 각 공급자간의 표준 데이터 송수신 방법 부재

- 분산환경하의 결제서비스 공급자(Payment Service Provider)를 포함한 다수의 공급자들(Providers)이 자유롭게 결제및 인증 구조에 참여할 수 있는 표준화된 데이터 송수신 구조 확립이 필요

1.1 ECML을 이용한 구조 표준화

- XML Encryption으로 데이터 암복호화
- XML Signature으로 데이터 전자서명/서명검증
- 공인인증 인프라 이용

1.2 SAML이용하여 송수신 방법 표준화





2. KECIS는 누구에게 필요한가?

2.1 분산환경에서의 다양한 공급자들


다양한 형태의 서비스 공급자들이 인터넷 상이 존재한다.

- 쇼핑몰 서비스 공급자

- 신용카드 결제서비스 공급자

- 휴대폰 결제서비스 공급자

- 계좌이체 결제서비스 공급자

- 공인인증 인증서비스 공급자

- i-PIN 인증서비스 공급자

- OpenID 인증 서비스 공급자

- 배송서비스 공급자

- 문자발송서비스 공급자


이 공급자들은 나름의 방법으로 서비스를 유저에게 제공


3. KECIS에서는 공급자들간 무엇을 주고받는가?

3.1 K-ECML 포맷의 XML Message

3.1.1 ECML (Electronic Commerce Modeling Language)

- ECML v1 by RFC2706 at 1999
- ECML v1.1 by RFC3106 at 2001
- ECML v2.0 by RFC4112 at Jun/2005
- IETF에서 기술적인 개발 및 변경관리 수행

3.1.2 K-ECML as ECML addon

- 국내 카드사 코드 추가
- 국내 카드거래 종류 추가 (금액인증, ISP, 안심클릭 등)
- 국내 결제수단 추가 (계좌이체, 휴대폰 결제, 가상계좌 입금통지 등)

3.2 K-ECML Field List

4. KECIS에서는 공급자들간 어떻게 데이터를 주고받는가?

4.1 SAML 이용

- SAML의 데이터 송수신 구조 응용
- 유저 브라우저가 데이터 송수신의 라우터 역할을 함.

4.1.1 SAML Use Case Diagram


- Google Login with SAML

4.2 KECIS의 SAML 응용 데이터 흐름도


4.3 이용자와 다수의 공급자


각 공급자는 기존의 존재하는 자신만의 방식으로 그대로 서비스를 제공하면서
다른 서비스 제공자와 서비스 결과를 표준화된 방식으로 주고받을 수 있다면

하나의 공급자가 모든 서비스를 묶어서 힘들게 제공할 필요없이

자신이 가장 잘하는 서비스를 집중하여 유저에게 제공하며
자신이 보유하고 있지 않은 서비스를 해당 서비스 공급자에게 표준적인 방법으로 요청(*)하고
그 결과를 역시 표준적인 방법으로 응답받아 확인(*) 하고
다음 프로세스를 진행할 수 있다.




각 공급자간의 데이터 송수신은 XML Message를 기반으로 하며

공급자의 공인인증서로 상호 XML 전자서명 - 서명검증 하거나
XML 암호화 - 복호화 하여 데이터를 주고받으며
주고받는 데이터의 구조는 XML Schema 표준에 의하여 정의한다.

4.4 다수 공급자간의 Use Case Diagram









5. KECIS는 구현되어 있는가?

5.1 오픈소스로 공개되어 있음.


5.2 KECI Public Server

- java daemon
- 공인인증 Public Key만을 Handling
- XML Request Message에 대한 공인인증 공개키 암호화
- XML Response Message에 대한 공인 전자서명 검증
- Public Key에 대한 CRL checking

5.3 KECI Private Server

- java daemon
- 공인인증 Public & Private Key pair handling
- 공인인증 Private Key의 HSM 보관을 위한 Interface
- KECI Public Server의 모든 기능 포함
- XML Encryption / Decryption
- XML Signature / Verification

5.4 client Libraries

- JSP로 구현
- KECI Public Server와 TCP/IP Socket 통신
- K-ECML XML Message 생성 / 파싱
- DOM Communication을 위한 javascript library 포함

6. KECIS구조하의 상호연동 시나리오

6.1 2곳의 서비스 제공자간 상호연동 시나리오

6.1.1 상점과 결제대행사

머천트
    • 머천트는 고객이 상품선택을 완료하면
    • K-ECML formatXML Message 생성
    • KECI Public Server를 통해 결제대행사의 공인인증서로 요청정보 암호화
    • 유저 브라우저를 통해 해당 요청정보를 결제대행사로 전송

결제대행사
    • 결제대행사에서는 요청정보를 공인인증서의 개인키로 복호화
    • 고유한 프로세스로 결제처리
    • 결제결과를 KECI Private Server를 이용하여 전자서명
    • 서명된 메세지를 유저 브라우저를 이용하여 전송

머천트
    • 결제대행사에서 유저브라우저를 거처 전송해온 정보 수신
    • KECI Public Server를 이용하여 서명 검증
    • 결제가 완료된것을 확인한 머천트는 유저에게 상품 제공

6.1.2 상점과 은행

상점
    • 고객이 상점의 상품 선택
    • KECI client library를 이용하여 K-ECML XML Message 생성
    • 생성된 K-ECML Message를 KECI Public Server로 암호화
    • 암호화된 "요청" 메세지를 은행으로 전송

은행
    • 유저 브라우저를 거쳐 암호화된 메세지 수신
    • KECI Private Server를 통해 해당 메세지 복호화
    • 은행 웹사이트내에서 계좌이체 진행
    • 계좌이체 결과를 KECI Private Server로 전자서명
    • 서명된 메세지를 유저 브라우저를 통해 상점으로 전송

상점
    • 은행에서 유저 브라우저를 거쳐 전송되어온 서명된 메세지 수신
    • KECI Public Server통해 공인 전자서명 검증
    • 계좌이체가 완료된것을 확인후 유저에게 상품 제공

6.2 n개의 서비스 제공자간

6.2.1 상점, 은행, 공인인증기관

상점
    • 고객이 상품 선택
    • KECI Public Server로 요청정보 암호화
    • 유저브라우저 통해 은행으로 계좌이체 요청 전송

은행
    • 암호화 메세지 수신
    • KECI Private Server통해 정보 복호화
    • 계좌이체 시작
    • 본인확인을 위해 본인확인 요청 정보 KECI Public Server통해 암호화
    • 공인인증기관으로 전송

공인인증기관
    • 본인확인 요청 접수
    • 공인인증기관 웹사이트에서 유저와 본인확인 진행
    • 본인확인결과를 KECI Private Server로 전자서명
    • 은행으로 본인확인 결과 전달

은행
    • 전자서명된 본인확인 정보 수신
    • 계좌이체 처리
    • 계좌이체 처리완료 정보를 KECI Private Server로 전자서명
    • 유저브라우저를 통해 상점으로 이체결과 전송

상점
    • 계좌이체 결과 수신
    • KECI Public Server로 서명검증
    • 유저에게 상품제공

6.2.2 n개의 서비스 제공자들

  • 암호화된 요청정보 수신
  • KECI Private Server로 데이터 복호화
  • 서비스 제공자의 고유한 서비스 제공
  • 서비스 제공 결과를 KECI Private Server통해 전자서명
  • 전자서명된 결과를 원 요청자에게 응답

7. References

7.1 ECML


7.2 SAML

http://blog.sdnkorea.com/blog/501 : SAML을 이용한 SSO 구현

7.3 XML Encryption


7.4 XMLDSIG


8. 작성자

이동산 (Mountie Lee)
mountie@paygate.net

댓글 없음: