한국형 전자상거래 서비스 제공자간 상호연동 표준안
Korea Electronic Commerce Interoperability Standard
(분산환경에서 서비스 제공자들간의 상호 연계를 위한 데이터 송수신 표준 구조)
1. KECIS가 왜 필요한가?
- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "방법" 부재
- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "구조" 부재
- 위 "부재"로 인해 서비스 연동을 위한 중복된 Resource 소모, 복합적인 서비스 연계 불가
- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.
![]()

==> 각 공급자간의 표준 데이터 송수신 방법 부재
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.
==> 각 공급자간의 표준 데이터 송수신 방법 부재
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
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 format의 XML 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
댓글 없음:
댓글 쓰기