KR20010070373A

KR20010070373A - 기업내의 롤을 근간으로 하는 허가 방법

Info

Publication number: KR20010070373A
Application number: KR1020000084142A
Authority: KR
Inventors: 루드비히헤이코에이치; 오코너루크제이
Original assignee: 포만 제프리 엘; 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2000-01-07
Filing date: 2000-12-28
Publication date: 2001-07-25
Also published as: KR100497022B1; JP2001229336A; US7222107B2; JP3871300B2; CN1304104A; AU7186300A; AU782518B2; US20010021928A1

Abstract

복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 거래 허가(권한 부여, 인증) 방법에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 프로세스 흐름의 활동 중 적어도 하나를 실행하는 거래 허가 방법에 있어서, 허가와 관련된 적어도 하나의 유형의 롤(역할) 인증서(role certificate)가 정본인지를 추출하여 확인하는 검증 가능한 방식으로 거래의 전자적 허가(권한 부여,인증)를 어셈블하는 것을 특징으로 하는 거래 허가 방법이 개시된다. 상기 방법은 롤에 기초한 허가 구조(authorization structure)를 제공함으로써 거래에 대한 각 서명과 모든 서명을 개별적으로 허가하는 필요성을 배제하고, 이러한 구조는 거래가 허가되는 검증을 위한 공동 네트워크에 엑세스 가능하다.

Description

기업내의 롤을 근간으로 하는 허가 방법{A METHOD FOR INTER-ENTERPRISE ROLE-BASED AUTHORIZATION}

본 발명은 e-커머스(전자 상거래)에 관한 것으로서, 특히 공동 네트워크 및 사설 네트워크를 통해 기업간 거래를 허가하고 그 허가(권한 부여, 인증)를 증명하는 방법에 관한 것이다.

공동 네트워크를 통한 각종 기업간 e-커머스 솔루션의 대규모 사용은 세심한 보안 문제의 고려를 필요로 한다. 이것은 일례를 통해 잘 설명된다.

두 회사, 즉 A 회사와 B 회사는 청약(오퍼)이나, 주문이나, 취소와 같은 비즈니스 거래를 위한 공식적인 합의(즉, 사람 또는 조직간 법적 이행 조치)를 갖는다. A 및 B간의 가능한 거래 유형의 집합은 예컨대 T∈T(A,B)를 뜻하는 경우, T(A,B)={T1,T2,...,Tn}으로 표시될 수 있다.

T→"단위당 P 가격으로 Y 제품을 X 단위로 구입"

집합 T(A,B)로 표시되는 거래 유형은 일반적인 거래의 유형이라고 가정할 수 있으며, 특정 거래가 발생하는 실제 시각에서 T(A,B)의 거래 설명에서 주어지는 범위를 벗어난 추가적인 세부 사항이 제공되어야 만 한다. 예컨대, 거래 T를 위해 요구자는 시간에 따른 변화가 예측되는 X,Y,P에 대한 값들을 공급하여야 할 것이다.

T(A,B)의 집합을 명시하고, 어떻게 거래를 수행하며, 어떻게 데이터를 교환할 것인가의 문제는 http://www.r3.ch/standards/edifact/index/html에서 이용 가능한 ISO 9735와 같은 전자 자료 교환(EDI)을 이용하여 해결될 수 있다. 더 나아가 이러한 회사들은 집합 T(A,B)에서 규정된 바와 같은 일반적인 거래를 수행하기 위해 인터넷을 통해 협동해야 만 한다.

전형적인 상황은 A 회사의 유저 UA가 B 회사의 통제하에 있음을 표방하는 유저 UB로부터 유형 T∈T(A,B)의 거래를 수신하는 것이다. UA에게는 A 회사가 단위당 P=$1 가격으로 Y 제품의 X=1000 단위를 준비하도록 A 회사에 대한 B 회사로부터의 요구가 제시된다. 요구가 공동 네트워크로부터 발원하므로, UA가 고려해야 하는 적어도 3가지 보안 문제가 있다. 즉, (1)거래의 세부사항들(X,Y,P,UA,UB)을 기밀로하고 무결성(integrity)을 위해 인코딩되어야 하는가? (2)거래를 요구하는 유저 UB가 사실상 B 회사에 의해서 통제되는 지를 어떻게 입증할 것인가? (3)거래를 요구하는 유저 UB가 B 회사에 고용되어 있다 하더라도, X,Y,P의 소정값에 대한 거래를 요구하도록 하는 권한을 사실상 UB가 위임받았는지를 어떻게 입증할 것인가 하는 명확하지 않은 문제가 있다.

먼저 1996년 CRC 출판사가 발간한 A.Menezes, P.van Oorschot, S. Vanstone 등의 Handbook of Applied Cryptography에서 기술하고 있는 바와 같은 표준 프로토콜과 암호화 알고리즘을 이용하는 두 관점이 설명될 수 있다. 특히, 공개키 암호문과 함께, 각 유저에게는 전자 서명에 의해 신원을 증명하는데 사용될 수 있는 하나 또는 수개의 인증서(ISO/IEC 9594에서 기술되는 인증서 등, 정보 기술-오픈 시스템 인터커넥션(OSI)-디렉토리:허가 프레임워크, 1993)가 발행될 수 있다.

UA 및 UB가 개인적으로 친분이 있다면, 기존의 신용 관계 UA가 권한 위임된 UB로부터의 요구를 받아들이는데 충분할 수 있는데, 이것은 현재 기업내 거래에서 많이 행해지고 있다. 이 경우, UA 및 UB는 어떤 신용 관계, 즉 장래 거래를 할 목적을 위한 신용 관계 또는 신용이 성공적인 이전 거래에 의해서 얻어진 신용 관계를 수립하고 있다. 그러나, 일반적인 e-커머스는 이전 비즈니스 또는 신용 관계가 없는 사람과 회사를 맺어줄 것이므로, 거래는 어떻게든 자동 허가(self-authorizing)되어야만 한다. 데이터, 애플리케이션, 자원, 또는 보다 일반적인 단순 오브젝트에 대한 전통적인 허가는 일정 형태의 엑세스 제어를 이용하여 관리된다. 1982년 Wesley Publishing Company 사 발행의 D.E. Denning 저의"Cryptography and Data Security를 참조. 가장 일반적인 양식에 있어서, 거기에는 각 오브젝트 O와 관련하여 각 유저가 갖는 엑세스권을 명시적으로 열거하는 엑세스 제어 매트릭스가 존재한다. 거기에는 많은 유저 Ui 및 오브젝트 Oj가 있을 수 있으므로, 엑세스 제어 매트릭스 M는 관리하기 어려울 수 있다.

아마도 대부분의 가장 일반적인 유형의 허가는 거래 T를 기술하는 일반 기록 문서/양식이며, 몇몇 세부사항은 요구자에 의해 요구 시 제공되며, 요구자는 적절한 거래 또는 거래 T의 요구를 승인할 수 있는 하나 또는 여러 사람으로부터 서류 양식에 손으로 기록한 서명 세트를 수집하는 것이 필요하다. 예컨대, T는 제공될 목적지, 체류 기간, 예상 코스트, 수송 방법을 필요로 하는 여행 요구 양식일 수 있다. 요구자는 이러한 세부사항을 채우고, 요구에 서명한 다음, 양식에 제공된 적절한 위치에 상관에 대한 서명을 작성한다. 통상, 서명을 필요로 하는 양식의 위치는 관리자나, 부서장이나, CEO와 같은 서명을 필요로 하는 사람의 롤(역할)(role)이 표시되어 있다.

이러한 허가 양식을 양식 서명 모델(form-signature model) 또는 공동 서명에 의한 허가, 또는 공동 사인 데이터라 한다. 예컨대, 여행 요구 거래(T="여행 요구")는 요구자, 요구자의 관리자, 다음에 요구자의 부서장의 서명을 필요로 할 수 있다. 일단 필요로 하는 서명을 수집한 다음에, 요구자는 여행 대행사에게 비행기 또는 호텔을 예약시키는 거래를 허가하는데 서명된 문서를 이용한다. 통상, 여행 대행사는 귀환일이 출발일의 이후 인가 혹은 코스트의 한계가 초과되지 않았는지에 관한 일반적인 체크 사항 이외의 여행 요구의 세부 사항을 확인하는 것과는관련이 없다. 여행 대행사에게 있어 가장 중요한 것은 요구를 수반하는 서명 세트와 그 서명이 나타내는 롤이다. 상당량의 자금을 내포하지 않은 대부분의 사무 작업의 경우, 작업 허가를 부여하기 위한 양식 서명 모델이 적합하다. 그러나, 상당량의 자금 또는 자원이 거래에 의해서 수반되는 경우, 각 서명이 진짜이며, 서명의 집합이 사실상 회사를 구속하는 것인지 확실히 하는 것이 중요하게 된다. 이 경우, 낮은 직위의 종업원이 거래를 허가하기 위한 권한을 가졌는지 확인하기 위해 기업 당사자(즉, 회장, 통제자, 또는 다른 관리자와 같은 거래 관리자)로부터 모든 거래에 대한 직접적인 승인을 얻는 것이 필요하다.

e-커머스에 대한 양식 서명 모델은 다음을 포함한다. (1)작업(일자, 코스트, 이름)을 수행하는데 필요한 정보 및 작업의 전자적 표현 (2)서명 메카니즘 (3) 전자적 작업 데이터를 수반하는 서명을 작업에 대한 허가를 부여하는 특권에 관련시키는 메카니즘. 일반적으로 (1)과 (2)는 현재의 방법 및 기술을 이용하여 바로 해결되나, (3)은 아직까지 적절하게 해결되지 않고 있다. (1) 및 (2)와 관련하여, 서류에 기초한 양식은 HTML 또는 워드프로세서 문서로서 전자적으로 표현 가능하며, 작업 T에 대해 D(T)를 작업 T의 전자 양식/템플릿을 나타낸다고 하자. T가 '여행 요구'이면, 예컨대 D(T)는 여행의 세부사항을 요구하는 HTML 문서일 수 있으며, 이 롤을 행하는 유저가 여행 요구 세부사항을 서명하여야 하는 경우 롤의 리스트가 있을 것이다. RSA 또는 DSS와 같은 전자 서명을 제공하는 수 개의 방법이 있고, e-커머스에서 양식 서명을 구현하기 위한 기본적인 도구가 이용 가능하다. e-커머스 양식 서명 모델에서 가장 어려운 부분은 수집된 서명 세트가 작업에 대한 허가를 내포하고 있음을 결정하거나 검증하는 것이다.

유저 U가 디지탈적으로 데이터를 서명하면, 유저 U는 공개 키 Pub(U)와 개인키(비밀키) Pri(U)를 가지게 되며 Pub(U)는 인증서에 저장되고, 그것을 Cert(U)라고 표시한다. 인증서 Cert(U)는 공동 데이터베이스 또는 디렉토리에 저장되므로, 누구라도 그것을 검색하여 U에 의한 서명을 Pri(U) 검증할 수 있다. 인증서 Cert(U)는 하나 또는 수 개의 U에 대한 이름/식별자를 포함하고 있어, U는 서명을 행한 유저로서 식별 가능하다. 그러나, 또 다른 유저가 D(T)에 서명 세트를 조사하여 요구 거래의 또 다른 유저를 검증하는 지를 고려하는데 있어, 중요한 형태는 각 서명을 행한 사람이 아니라 서명자가 T를 허가하기 위한 허가권을 가졌는가이다.

그러므로, 필요한 것은 비보안 공동 네트워크를 통해 표준 암호 또는 암호화 프로토콜을 이용하여 모든 거래를 검증하는 것으로부터 기업 기관을 자유롭게 하고 e-커머스 계약의 허가 검증 및 효율적인 허가를 가능하게 하는 방법이다. 필요로 하는 또 다른 것은 개개의 회사의 결정 구조에 대한 최소의 정보를 드러내는 기업간 허가(inter-enterprise authorization)를 행하기 위한 방법이다.

복수의 상호 연결된 컴퓨터 및 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 거래 허가 방법(a transaction authorization method)이 제공되며, 각각의 컴퓨터는 프로세서, 메모리. 입출력 장치를 포함하며, 각각의 자원은 적어도 하나의 컴퓨터에 동작 가능하게 연결되어 프로세스 흐름의 활동들 중 적어도 하나를 실행한다. 거래 허가 방법은 롤(역할)에 기초한 허가 구조를 제공함으로써 개별적으로 거래에 대한 각각의 구조 및 모든 구조를 허가할 필요성을 배제한다.

상기 방법은 익명의 롤 인증서로 표현되는 롤에 의거한 익명의 허가 결정을 행하기 때문에 기업내(intra-enterprise)와 기업간(inter-enterprise) 환경에서 적용 가능하다. 이런 방식으로 종업원의 신원 ID은 거래 허가를 검증할 때 누설될 필요가 없다.

또한, 상기 방법은 롤의 조합이 그 유형의 거래를 허가할 수 있다는 것을 결정하는 특정 거래에 대한 허가 트리를 이용한다.

기업간 허가를 포함하는 또 다른 특징으로, 허가 트리의 해쉬 버전(hashed version)이 이용됨에 따라 회사의 승인 구조에 대한 최소 정보를 드러내면서 거래를 수행하도록하는 권한을 소정 유저가 위임받았다는 증명을 제공한다. 이런 방식으로, 상기 방법은 승인 구조의 세부사항이 드러나지 않는 방식으로 회사의 결정 구조의 검증을 가능하게 한다.

본 발명의 목적은 거래가 적합하게 허가되어 시행 가능함을 보장하는 편리한 컴퓨터 처리 수단을 제공함으로써 e-커머스를 촉진하는 것이다.

본 발명이 또 다른 목적은 해쉬 테이블이 사용되는 경우, 거래를 허가하면서 허가 트리에서 공간 요건을 감소하고 결정 절차 정보를 드러내지 않게 하는 것이다. 따라서, 본 방법은 기업간 거래에 특히 유용하다.

도 1은 본 발명의 컴퓨터 시스템의 블록도,

도 2는 본 발명의 방법으로 인코딩된 네트워크의 개략도,

도 3은 거래의 개략도,

도 4는 본 발명의 방법의 세부 사항 흐름도,

도 5는 본 발명의 검증 보조 방법의 흐름도,

도 6은 본 발명의 방법에서 사용된 여행 요구 문서의 개략도,

도 7은 본 발명의 방법의 거래 기관(transaction authority)을 보여주는 블록도,

도 8은 본 발명의 방법의 허가 구조(authorization structure)를 보여주는 블록도,

도 9는 여행 요구에 대한 허가 트리를 도시하는 도면,

도 10은 롤 인증서에 대한 본 발명의 방법의 상호 작용을 보여주는 블록도,

도 11은 본 발명의 방법에서 각종 데이터베이스에 대한 TAM의 상호 작용을 도시하는 블록도,

도 12는 완료된 여행 요구의 개략도,

도 13은 여행 요구 시 롤 인증서를 도시하는 개략도,

도 14는 요구를 검증자로 전송하는 것을 보여주는 개략도,

도 15는 도 9의 트리의 해쉬(hash)를 도시하는 도면.

도면의 주요 부분에 대한 부호의 설명

2 : TAM 프로그램 26 : 키보드 입력

30 : 주기억 장치 32 : 보조 기억 장치

36 : CPU 41 : 인터페이스

46 : 실행 시간 시스템

도 1과 관련해서, 거래 허가 방법(《TAM》)(2)은 계약의 유효성이 손쉽게 검증될 수 있는 방식으로 계약을 구성함으로써 e-커머스의 계약(4)의 유효성을 보장하는 수단을 제공한다.

TAM(2)은 분산된 작업 흐름 관리 시스템(6)내에서 동작하는 메시지 교환 메카니즘을 갖는다. TAM(2)은 (1)요구(10)를 허가하기 위해 유저(8)에 의해 엑세스 가능하며, (2)수 개의 데이터베이스(70, 또는 82, 또는 96, 또는 202)(도 11에 도시됨)에 엑세스 가능하며, (3)유저를 요구 서명(18)에 접촉시키는 속성을 가진다.

TAM(2)은 복수의 상호 연결된 컴퓨터(22)와 복수의 자원(23)을 포함하는 컴퓨터 네트워크(25 및/또는 31)를 통해 분산 시스템(21)의 컴퓨터 시스템(20)상에서 동작한다. TAM(2)은 컴퓨터 판독 가능한 매체에서 인코딩되어 컴퓨터 시스템(20)상에서 및/또는 컴퓨터 시스템 및 인터넷(25 또는 31)상에서 하나 이상의 서버(54a 또는 54b) 사이에서 동작한다.

컴퓨터 시스템(20)은 통상 컴퓨터(22), 디스플레이 장치(24), 키보드와 같은 입력 장치(26), 주 기억 장치(30), 보조 기억 장치(32)를 포함한다. 인터넷 익스플로어 5.0과 같은 브라우저를 통해 서버(25 또는 54)에 엑세스 할 시 혹은 엑세스한 후 본 발명의 TAM(2)으로 인코딩된 소프트웨어를 로딩한 후, 경우에 따라 디스플레이 장치(24)는 TAM과 관련된 텍스트 및 그래픽의 표시를 유저에게 수월하게 하는 그래픽 유저 인터페이스(GUI)(34)를 디스플레이한다. 디스플레이 장치(24)는 CRT, LED 디스플레이, LCD, 플랫 스크린, 스크린폰, 프로젝터와 같은 컴퓨터 디스플레이스크린과 프린터를 포함한다. 입력 장치(26)는 다수이며 좌측 마우스 버튼(28)과 우측 마우스 버튼(29)을 가진 마우스(27), 트랙볼, 라이트펜, 섬휠, 디지트 태블릿, 음성 인식 소프트웨어를 이용한 마이크론폰, 터치 스크린, 패드와 같은 포인팅 장치와 키보드를 포함한다.

각 자원(23)은 컴퓨터(22)의 적어도 하나에 동작 가능하게 연결되며 TAM(2)의 프로세스 흐름의 활동 중 적어도 하나를 실행한다. 자원(23)은 프린터, 데이터베이스, 특정 용도의 서버, 보안 장치, 모뎀 등을 포함한다.

GUI(34)는 데이터 입력용 필드와 TAM(2)의 제어부와 작업 흐름 시스템의 관리 및 동작을 용이하게 하는 상태 및 정보의 디스플레이용 출력 윈도우를 제공한다. TAM(2)은 이후 세부 사항을 설명하는 바와 같이 거래와 관련된 정보를 포함하는 데이터베이스(33)에 엑세스한다.

컴퓨터(22)는 당업자게 친숙한 CPU(36)와 다른 구성요소를 포함한다. 이러한 구성요소와 상호 작용에 대한 세부사항 설명에 대해서는 여기서 참조문헌으로 결합되는 미국 특허 제5,787,254호를 참조하라. 보조 기억 장치(32)는 TAM(2), 양호하게는 HTTP에 따르는 TAM과 다수의 인터넷 엑세스 도구를 지원한다. CPU(36)는 버스(42)에 연결된 입출력 서브시스템과 같은 인터페이스(41)를 통해 주 기억 장치(30)로부터 컴퓨터 명령을 인출한다. 컴퓨터(22)는 뉴욕 아몬크 소재의 IBM사의 제품인 "IBM APTIVA" 컴퓨터 또는 인텔사의 X86 또는 펜티엄(상표명) 시리즈 프로세서 또는 호환 프로세서에 기초한 IBM PC 컴퓨터 시스템과 호환 가능한 컴퓨터 또는 다른 적절한 컴퓨터일 수 있으며, 이들에 제한되지는 않는다. CPU(36)는 사용된 하드웨어에 따라 DOS, 윈도우 3.X, "윈도우 XXXX", "NT" "OS/X", "LINUX" 일 수 있는 운영 체제 또는 다른 적절한 운영 체제를 이용한다. CPU(36)는 인출된 컴퓨터 명령을 실행한다. 이러한 명령의 실행에 의해 CPU(36)는 데이터를 검색하거나 데이터를 주 기억 장치(30)에 기록하거나, TAM(2)의 통계적 디스플레이와 같은 정보를 하나 이상의 디스플레이 장치(24)에 표시하거나, 하나 이상의 입력 장치(26)로부터 명령 신호를 수신하거나, 데이터를 컴퓨터 네트워크(25)(도 2에서 도시)를 집합적으로 형성하는 다른 컴퓨터 시스템 또는 보조 기억 장치(32)로 전달한다. 당업자라면 주 기억 장치(30)와 보조 기억 장치(32)는 RAM, ROM, ASIC, CD-ROM과 같은 자기 및 광학 기억 매체를 포함하는 기억 장치를 포함하는 컴퓨터 기억 장치의 유형을 포함함을 알 수 있을 것이다.

도 3과 관련하여, e-커머스를 행하는 과정에서 온라인 실행될 많은 클래스의 거래가 있다. 이와 관련하여 각 거래(40)는 요구자(42)와 검증자/값 제공자(44) 사이에서 발생한다. 요구자(42)는 제품 또는 서비스(46)를 원하며 값 제공자(44)는 요구자의 요구(52)을 기초로 하는 e-문서(50)가 적절히 허가되길 원한다. 그러므로, 값 제공자(44)는 문서(50)의 진위를 검증하기 원한다. 요구자(42)와 값 검증자(44)는 동일 회사에 고용될 수도 있고 되지 않을 수도 있다.

예컨대, 요구(52)와 관련한 문서(50)는 여행 소요 자금이 가용한지를 결정하기 위해 요구 회사의 종업원으로부터 회사의 여행 대행사로 또는 종업원으로부터 동일 회사의 재정 관리자로 보내는 여행 요구 문서(52)(도 6에서 도시)와 같은 제품 또는 서비스에 대한 계약일 수 있다.

방법에 대한 보다 상세한 흐름도가 도시되는 도 4와 관련하여, TAM(2)은 다음 단계를 실행한다. 단계(60)에서, 종업원(62)은 TAM(2)으로부터 거래(40)를 요구한다. 단계(62)에서, TAM(2)은 전자 문서 데이터베이스(70)(도 7에서 도시)로부터 거래(40)에 대한 상세한 HTML 양식(64)을 요구한다. 단계(72)에서 전자 문서 데이터베이스(70)는 거래 세부사항(66)의 HTML 양식(64)을 TAM(2)으로 복귀한다. 단계(74)에서, TAM(2)은 (이후 상세히 설명되는) TA(80)의 롤 인증서를 포함하는 익명의 롤 인증서(익명성이란 유저의 이름이 인증서에 포함되지 않는다는 것을 의미한다.)로 구성된 롤 인증서 데이터베이스(82)로부터 TA(80)의 롤 인증서(76)를 요구한다. 단계(84)에서 롤 인증서 데이터베이스(82)는 TA(80)의 인증서(76)를 복귀하고 TAM(2)은 전자 문서 데이터베이스(70)로부터 복귀된 거래 요구 세부사항(60)의 HTML 양식(64)에서 TA의 서명(126)을 검증한다. 단계(86)에서, TAM(2)은 HTML 거래 세부사항(66)을 요구자(42)로 복귀한다. 단계(90)에서, 요구자(42)는 HTML 양식(64)을 살펴보고, 명시된 세부사항(예, 이름, 목적지, 비용 등)을 완성하며, 완성된 HTML 양식(64)에 사인하고, 임의의 나머지 서명(106)을 수집하기 위해 사인된 HTML 양식을 TAM(2)으로 복귀한다. 단계(92)에서, TAM(2)은 허가 구조 데이터베이스(96)로부터 거래에 대한 AS(94)를 요구한다. 복귀된 AS(94)는 TA(80)에 의해서 사전 사인되고 그 서명은 TAM(2)에 의해서 검증된다. TAM(2)은 롤 명(role name:102)의 허용 세트(100)(a permission set)와 롤 명으로 사인 계약할 유저의 집합을 선택한다. 단계(104)에서, TAM(2)은 정규 종업원 요구자(42) 서명(106)의 거래 요구(52)의 세부사항(66)을 선택된 허용 세트(100)에 대응하는 역할을 하는 다른 요구자로 전달하고 허용 세트(100)에 지시된 각 롤의 서명을 수집한다. 예컨대, 관리자 및 부서 관리자가 그의 각 롤에서 문서(64)를 사인한 서명이 수집된다. 단계(110)에서 TAM(2)은 허용 세트(100)의 각 멤버에 대한 롤 인증서와 각 서명을 요구한다. 단계(112)에서, TAM(2)은 서명(106)과 롤 인증서(76)를 포함하는 문서(54)를 요구자(42)로 전송한다. 그러므로, 거래(40)의 유효성을 확인하는데 필요한 모든 허가 세부사항(66)을 포함하는 전자 문서(114)가 작성된다. 단계(116)에서, 선택적으로 TAM(2)은 사인된 문서(114)를 검증한다.

도 9와 관련해서, TAM(2)에서 익명 롤 인증서(76)는 서명 검증키(a signature verification key:120)와 롤(122)간의 관계이다. 이것은 서명(106) 검증키(120)와 이름(도시 안됨) 사이의 관계인 ITU-T X.509(1997 E)(이후, X509라 함)에서 기술하고 있는 표준 인증서와는 다르다. 보다 정확하게 기술하자면, X509는 공개키와 이름 사이의 관계이며, 공개 키는 암호 및 서명 검증에 대해서 사용 가능하다. 그러나, 본 발명의 TAM(2)은 롤(122)의 자격으로 암호화를 수행하는 유저와 관련이 있지 않고, 롤의 자격으로 서명(106)을 행하는 유저와 관련이 있다. 인증서(76)는 인증서의 소유자와 어떤 연결 정보를 갖지 않는 익명성이다. 인증서 Cert의 소유자는 인증서에 수록된 공개키에 대응하는 개인키를 갖는 유저로서 명시적으로 정의된다.

롤 인증서(76)는 TAM(2)에서 중요한 역할을 한다. 어느 C 회사에는 일련의 잘 정의된 롤 RC={R1,R2,...Rm}이 있고 C 회사의 각 유저 U는 하나 또는 수개의 롤 UR⊆RC이 지정된다. TAM(2)을 위해 각 유저는 어느 로컬 허가 기관 CA이 사인한 이름, 공개키, 다른 필드를 포함하는 X.509 공개키 인증서 CertCA(U)를 갖는다고 추정된다. X.509가 e-메일 어드레스, 대체 이름, 정책 정보와 같은 일반적인 정보에 대한 확장 필드를 담고 있으면, 지정된 롤(122)은 확장 필드로서 포함될 수가 있다. 그러나, 롤(122) 및 인증서의 소유자는 인증서가 이름 필드를 담고 있기 때문에 명시적으로 링크된다. IETF 작업 그룹은 또한 롤(122), 그룹 멤버쉽, 이름에 대한 보안 클리어런스(security clearance)와 같은 속성들을 바인딩하는 속성 인증서(AC)(1998년 8월 20일 발표된 S. Farrell의 An Internet Attribute Certificate Profile for Authorization을 참조)의 개념을 현재 개발중이다. 그러나, 속성 인증서는 공개키를 포함하고 있지 않으며, AC에 규정된 이름은 기존의 X.509 CertCA(U)에서 명명된 개개의 U와 관련된 보충 정보를 제공하는 것을 의미한다. 인증서 보유자의 이름이 AC에 포함되므로, 이름과 롤이 직접적으로 링크된다. TAM(2)을 위해 인증서(76)와 AC는 허용 가능한데, 이는 TAM이 활동을 허가하기 위한 롤을 포함하는 인증서를 사용하고 있기 때문이며, TAM에서 유저와 직접적으로 관련되지 않은 롤이 할당되는 것이 바람직하다.

그러므로, TAM(2)은 다음과 같은 변화를 갖는 X.509v3 인증서인 유저용 익명 롤 인증서 76(CertCA(U,R)을 이용한다. (1)이름 필드가 가공의 유저를 나타낸다. (2)U에 대한 롤(122)을 포함하는 확장 필드가 있다. (3) Cert(U)에서 Cert(U,R)로의 전송 기준을 포함하는 확장 필드가 있다.

예컨대, 전송 기준은 C'회사의 공개 키 또는 로컬 CA의 공개키에 의한 패스워드와 U를 연결하는 공개키 암호화를 가리키는 E(C, U, 패스워드)의 형태를 취할수 있다. 전송 기준은 회사가 롤 인증서의 소유자를 식별하는 것이 가능한 단순 메카니즘이며, 본 발명의 방법에 대한 다른 중요성을 갖지 않는다. U가 수 개의 롤을 가지면, 거기에는 각 롤에 대한 롤 인증서(76)가 있을 것이다. 각 롤 인증서는 유저가 그 롤 자격으로 서명을 행할 수 있도록 공개적인 대응의 개인키를 갖는 것에 주목해야 한다. 그러므로 각 유저는 유저의 이름을 공개키에 바인딩하는 적어도 두 인증서인 표준 X.509v3 인증서 CertCA(U)를 가진 다음, 유저의 롤을 공개키에 바인딩하는 익명의 롤 인증서 76(CertCA(U,R)를 가질 것이다. CertCA(U)는 전송 기준에 의해 CertCA(U,R)에 링크되나 CertCA(U,R)이 주어지면 U의 ID 또는 CertCA(U,A)를 결정하는 분명한 방법은 없다. TAM(2)을 위해 롤 인증서 76 CertCA(U,R)와 연관된 개인키(124)에 의해서 생성된 서명(106)은 롤 서명(126)으로 정의된다.

그러므로, 유저가 거래(40)에 서명(126)을 하였다면, 검증자(130)는 유저가 관리자 인지 혹은 부서장인지, 그리고 이 롤이 소정 작업과 어떻게 관련이 있는 지와 같은 회사에서 유저가 갖는 롤(122)에 관심이 있다. 유저의 ID 또는 이름은 사실상 중요하지 않은데, 작업이 허가되었는 지를 검증하는데 있어 유저가 취한 롤(122) 만이 관심사이기 때문이다.

도 5와 관련하여, 검증 작업을 수행하기 위해, TAM(2)은 작성되어 서명된 문서(114)의 검증을 가능하게 하는 검증 보조 방법(a verification submethod:116)을 포함한다. 제1 단계(132)에서, 롤 서명(126)은 문서(114)상에서 체크된다. 제2 단계(134)에서, 거래 유형 자체가 체크되어 그것이 허가된 거래임을 보증한다. 제2 단계(134)의 보조 단계(136)에서, 롤 이름(122)이 롤 인증서(76)로부터 추출된다.제2 단계(134)의 제2 보조 단계(142)에서 거래(40)의 계산된 해쉬값은 AS 94에서 수신된 거래(40)의 값과 같은지 확실히 하기 위해 체크된다. 제2 단계(134)의 제4 보조 단계(144)에서 거래(40)에 대한 TA(80)의 서명(126)이 체크되어 서명의 정확성을 보증한다. 서명이 정확하다면, 거래(40)는 검증되고, 이 사실의 통지가 요구자(42)로 보내진다.

그러므로, 검증은 단순히 서명 체크 과정이며, 검증자(130)는 거래(40)의 세부사항(66)과 관련이 없다. 서명자가 거래(40)의 세부사항(66)을 체크하였고, 이 세부사항이 소정 유형의 T의 거래에 대한 회사 정책과 동떨어졌으면 서명(106)을 보류할 것이다. 이러한 가정은 다시 양식 서명 모델에서는 고유한 것이며, 검증자(130)는 통상 서명된 양식의 세부사항에 반대하되는 것으로서 제공된 서명과 보다 관심이 있다.

나머지 상세한 설명에 있어서, 여행 요구 거래는 TAM(2)의 단계들을 설명하기 위해 사용된다.

도 6과 관련해서, 도 6에는 IBM 여행 요구 문서(54)의 구조가 도시되고 있다. 전통적으로 서류 문서는 각종 거래를 위해 사용되어 왔다. 특히, 여행 요구를 허가 하기 위해 사용되어 왔다. 그것은 문서 양식을 전자 문서(64)(바람직하게는 HTML 형태, 비록 수개의 가능한 포맷이 있을 지라도)로 변환하기 위한 거래 기관(80)(《TA》)(도 7에 도시됨)의 작업이다. 각 양식에 대해, TA(80)는 거래 세부사항(66)으로서 고려될 수 있는 것과 허가 정보(146)로서 고려될 수 있는 것을 분리한다. 여행 요구 문서(54)에 대해, 거래 세부사항(66)은 요구자 이름, 목적지,여행 경비, 사무실로부터의 출발일 등을 포함한다. 서류 양식과 서류 양식으로 구성된 HTML 문서(64) 상에서 대부분의 거래 세부사항(66)은 단순히 요구자(42)에 의해 공급되는 정보에 대한 롤 보유자이다.

허가 세부사항(146)은 일반적으로 거래(40)를 조인트 허가하기 위해 필요로 하는 사람의 롤(122) 리스트로 이루어진다. 서류 양식은 보통 그것을 사인하는 것을 의미하며 HTML 문서(64)의 경우, 허가 세부사항(66)은 거래(40)를 허가할 수 있는 롤을 담당하는 사람이 누구인지를 표시할 것이다. 여행 요구 문서(54)의 경우, 여행 요구를 허가하는 허용 세트(100)에 대응하는 허가 세부사항(66)은 요구자(165)의 전자 서명(106), 관리자(167), 부서 관리자(169)(도 9에 도시)로 이루어져 있다. 이것은 요구자(42), 관리자 롤(122)을 행하는 사람, 부서 관리자의 롤(122)을 하는 사람은 허가 고려될 허가 세부사항에 대해 HTML 양식(64)을 전자적으로 사인하여야만 한다는 것을 의미한다.

도 7과 관련하여, 여행 요구 문서(64)에 대해, TA(80)는 HTML로 여행 거래 세부사항(66)을 작성하고, 이 세부사항을 사인하며, 사인된 문서를 전자 문서 데이터베이스(70)에 저장한다. 그러므로, A(80)의 롤을 관련 서명 검증키(120)를 포함하는 TA 롤 인증서 76(도 8에 도시됨)을 발행받은 사람에게 할당하는 것이 필요하다. TA(80)는 매칭 사인 키(150)와 별도로 발행 가능하다. TA(80) 서명키(150)로 행한 서명은 TA 롤 인증서 76(도 10에 도시됨)에서 검증키(120)로 검증된다.

TA(80)는 여행 요구 문서(64)에 대한 허가 서명(94)을 행하고, 문서를 사인한 다음, 그것을 허가 구조 데이터베이스(96)에 저장한다. 허가 구조(94)는거래(40)를 허가하기 위해 사용될 수 있는 롤의 표시이다.

전자 문서 데이터베이스(70)와 허가 구조 데이터베이스(96)내의 정보는 보안을 필요로 하지 않는다. 그러나, 보호될 정보는 무결성을 필요로 한다. 이러한 이유로 TA(80)는 그러한 문서를 서명하여야 한다.

도 8과 관련해서, 어떻게 허가 구조 98(AS)가 사회적, 전략적 관리에 따라서 생성되는지에 관한 세부사항은 발명의 주제는 아니다. AS(98)의 주 특성은 그 구성이 허용 세트(100)의 개념에 따른다는 것이다. 허용 세트(100)가 의미하는 것을 설명하기 위해, 세트 PT,1={U,M,DH}를 거래에 대한 허용 세트라고 한다. 이 예에서, 거래 T는 단지 하나의 허용 세트이나 일반적으로 하나의 거래는 PT, 1, PT, 2, ... ,PT, I로 표시되는 수 개의 허용 세트를 가질 수 있다. 각 허용 세트(100)는 일련의 롤(122)(즉, PT,i⊆R, 잠재적으로는 멀티 세트)로 이루어지는데, 어느 유저 U가 T의 어떤 허용 세트 PT,i={R1,R2, ... ,Rm)에 대해 롤 R1,R2, ... , Rm의 m 유저가 각각의 롤 인증서를 이용하여 D(T,U) 사인하면 D(T,U)로 표현되는 거래에 대해서 허가를 받는다는 것을 의미한다.

허용 세트(100), (PT,i)는 조인트 기관(joint authority)이 유형 T의 거래(40)를 허가하기 충분하다고 여겨지는 일련의 롤(122)을 나타낸다. 트리(154)(도 9에 도시됨)는 거래 T의 허용 세트(100) PT={PT,1,PT,2, ... , PT,k}를 표현하기 위해 사용된다. 양식 서명 모델과 관련하여, PT는 유형 T의 거래를 허가하기 위한 결정 절차를 기술한다. 여기서 참조 문헌으로 결합되고 있는 Merkle의 미국 특허 제4,309,569호는 이러한 트리(154)의 일반적인 용도를 기술하고 있다.

도 9와 관련하여, 각 거래 유형 T에 대해, 허가 트리(154) AT는 거래 유형 T에 대한 k 허용 세트(100) PT={PT,1,PT,2, ... , PT, I)에 대응하는 루트(162)로부터 제1 레벨에서 k 노드(156)가 있도록 생성된다. 제2 레벨(164)에서 노드는 레벨(166)이며, 각 허용 세트(100)의 롤(122)을 표시한다.

T에 대한 허용 세트(100)가 PT,1={R1,R2}, PT,2={R3,R4,R5}, PT,3={R6}이고, AT(154)가 제1 레벨(160)이 3개의 노드를 갖는 PT,1,PT,2,PT,3을 표시하는 경우 2개의 레벨을 가지며, 각 PT,i(100)는 그의 허용 세트에서 롤이 있을 때 동일한 리브(leave)(166) 수를 가진다. 그래서 예컨대, PT, 1(100)는 도 10에 도시된 바와 같이 R1,R2를 표시하는 2개의 결과(두 리브(166))를 가질 것이다.

거래(40)가 허가된 것이라고 여겨지기 때문에, 적어도 하나의 허용 세트(100)에 대해 PT,i 서명이 PT,i에서 각 롤(122)에 대해 얻어지면, PT,i를 나타내는 노드(156)는 "AND" 노드(170)로서, AT(154)의 루트(162)는 "OR" 노드로서 고려될 수 있다. AND 노드(170)SMS 노드의 모든 결과가 요구 D(T,U)에 동의하여야만 하고(허용 세트(100)의 모든 롤(122)이 사인하여야만 한다.), OR 노드(172)는 요구 D(T,U)에 동의하여야만 한다(적어도 하나의 허용 세트는 조인트 사인하여야 한다)는 것을 의미한다. 대안으로, AT(80)는 거래(40)를 허가할 수 있는 롤(122)의 선언 표시로서 해석될 수 있다.

도 8과 관련해서, 여행 요구 문서(64)와 함께 허용 세트(100)는 요구자(42), 관리자, 부서 관리자로 이루어져 있다. 이에 대해서는 나중에 상세히 설명하기로 한다.

도 10과 관련해서, AS(98)는 허용 세트(100)에 기초하고, 이 세트는 명명된 롤(122)로 이루어지므로, 각 유저에게는 롤 명이 표시된 하나 이상의 롤이 발행될 것이다.유저는 소정 롤명(122) 하에서 그의 능력안에서 사인하는 것이 필요하므로, 유저에게는 롤 인증서(76)가 발행된다. 롤 인증서(76)는 롤명(122), 서명 검증키(120), 롤 인증서(76)상의 롤 관리자 서명(106), 다른 관리 정보(롤 인증서가 만료할 때 롤 인증서가 발행되는 시간 등)로 이루어져 있다. 한 유저에게 롤 인증서(76)가 주어지면, 롤 인증서의 검증키(120)를 매칭하는 대응 서명키(150)가 또한 주어진다. 사실상 유저는 대응 사인키(150)를 보유함으로써 소정의 롤 인증서(76)를 자신이 보유하고 있음을 증명해 보인다. 따라서, 사인키(150)는 발행될 유저에 의해서 보안 유지되어야 한다. 각 사인된 롤 인증서(76)는 또한 롤 인증서 데이터베이스(82)(RCD)에 저장된다.

상기한 내용은 본 발명의 TAM(2)의 초기화를 완료하는 것이다. 요컨대, 초기화는 서류 양식의 전자 문서(64)로의 변환, 거래 기관(80)에 의한 사인을 포함한다. 더 나아가 TA(80)는 또한 각 거래(40)에 대한 허가 구조(98)(AS)를 결정하고 이 AS를 서명한다. AS(98)의 정보는 명명된 롤에 기초하고 있고, 롤 기관(180)은 하나 이상의 롤 인증서(76)를 각 유저에게 발행한다. 롤 허가 기관(80)이 발행한 일련의 명명된 롤(122)은 AS(98)의 구성에서 TA(80)에 의해 사용되었다.

도 11과 관련하여, 여행 요구(64)을 허가하는 일례가 고려된다. 유저가 여행 요구를 원하며 그것을 허가한다고 가정하자. 여행 허가의 요구자(42)인 유저는 TAM(2)의 도움을 통해 이를 달성할 것이다. 양호한 실시예에서 TAM(2)은 회사 인터넷(25)상에서 서버 어플리케이션이며, 브라우저와 같은 웹 인터페이스를 거쳐서 연결 가능하다. 이처럼, 유저는 그의 URL을 통해 TAM(2)과 접촉할 수가 있고 유저는 여행 요구(64)를 원함을 표시한다. 여기서, 여행 요구 요구자(42)는 정규 종업원의 롤(122)을 행하고 있다.

제1 단계(182)에서, 유저/종업원(42)은 TAM(2)으로부터 여행 요구 거래(40)를 요구한다. TAM(2)은 유저(42)로부터 여행 요구(52)를 받아들여 이러한 거래(40) 클래스에 대한 거래 세부사항(66)의 카피를 얻기 위해 전자 문서 데이터베이스(70)와 접촉한다. 전자 문서 데이터베이스(70)는 HTML로 표시되는 세부사항(66)을 TAM(2)으로 복귀한다. HTML은 거래 기관(TA)(80)에 의해서 사전에 서명되었다.

제2 단계(184)에서, TAM(2)은 전자 문서 데이터베이스(70)로부터 거래 세부사항(66)의 HTML 양식(64)을 요구한다. HTML 세부사항이 정확한지를 체크하기 위해, TAM(2)은 롤 허가 데이터베이스(82)로부터 TA(80)의 롤 인증서 76(정규직 종업원(165), 관리자(67), 부서 관리자, 종업원의 다른 롤, 회사내에의 상이한 레벨에서의 관리의 롤 인증서를 포함)을 요구한 다음 서명(106)을 검증한다. 서명(106)이 정확하면, TAM(20)은 진행한다.

제3 단계(186)에서, 전자 문서 데이터베이스(70)는 여행 요구 거래 세부사항(66)의 HTML 양식(64)을 복귀한다.

제4 단계(190)에서, TAM(2)은 롤 인증서 데이터베이스(82)로부터 TA(80)의 롤 인증서(76)를 요구한다. 제5 단계에서, 롤 인증서 데이터베이스(82)는 TA(80)의 인증서(76)를 복귀하고 TAM(2)은 전자 문서 데이터베이스(70)로부터 복귀한 거래요구 세부사항(66)의 HTML 양식(64)에서 TA의 서명(106)을 검증한다.

제6 단계(194)에서, TAM(2)은 HTML 거래 세부사항(66)을 요구자(42)로 복귀하고, 요구자의 브라우저는 입력을 요구중 이라는 것을 HTML 양식(64)으로서 세부사항을 표시한다. 요구된 입력은 여행 요구(54)에 대한 거래 세부사항(66)을 구성한다. 제7 단계(196)에서, 요구자(42)는 HTML 양식(64)을 검토하고, 브라우저를 통해 규정된 세부사항(66)(예, 이름, 목적지, 가격 등)을 완료하고, 완료된 HTML 양식(64)에 사인한다. 유저/요구자(42)는 롤 정규직 종업원을 지시하는 롤 인증서(76)로 사인한다. 요구자(42)는 사인된 HTML 양식(64)을 TAM(2)으로 복귀하여 나머지 서명(106)을 수집한다.

제8 단계(200)에서, TAM(2)은 유저(42)로부터 사인된 요구자 입력(즉, 사이된 HTML 양식)을 수령한 다음, 허가 구조 데이터베이스(96)와 접촉하여 여행 요구 거래(40)에 대한 허가 구조(98)를 얻는다. TAM(2)은 데이터베이스(96)로부터 허가 구조(98)를 수신하여 그 구조상의 TA(80)의 서명(106)을 체크한다. 허가 구조(98)로부터, TAM(2)은 롤명(122)의 허용 세트(100)와 유저의 집합을 추출하여 롤명에 사인하기 위해 접촉한다. 이 경우, 정규직 종업원/요구자(42), 관리자, 부서 관리자인 오직 하나가 있다.

이 때, TAM(2)의 오브젝트는 조인트 롤(122)이 허용 세트(100)를 구성하는 사람으로부터의 서명(106)의 집합을 얻는 것이다. 요구자(42)는 롤 《정규직 종업원》에 대한 서명(106)을 이미 제공받았으며, TAM(2)은 롤 《관리자》(167)와 《부서 관리자》의 두 서명을 얻어야만 한다.

TAM(2)은 유저 및 그의 롤(122)을 열거하고 예컨대 하나의 서명(106)에 대한 롤 관리자로서 유저 《존 브라운》을, 다른 서명에 대한 롤 《부서 관리자》로서 《슈 스미스》를 선택한다.

제9 단계에서, TAM(2)은 정규직 종업원 요구자(42)의 서명(106)과 함께 거래 요구 세부사항(66)을 요구자 관리자인 존 브라운에게 전송한다. 존 브라운의 브라우저는 요구자의 거래 세부사항(66)으로 채워진 HTML 여행 양식(64)과 요구자(42)가 제공한 서명(106)이 정확하다는 표시를 디스플레이한다. 다음에 존 브라운은 여행 요구(54)를 허가할 것인지를 결정한다. 허가가 부여되면, 존 브라운은 여행 요구(54)의 HTML과 TAM(2)으로 복귀된 요구자(42)가 제공한 여행 세부사항(66)을 사인한다.

제10 단계에서, TAM(2)은 여행 요구(54)의 세부사항(66)과 요구상의 이전 서명 세트(이 경우 요구자와 존 브라운의 서명)와 함께 제공된 부서 관리자 슈 스미스로 서명(106)과 함께 거래 요구 문서(64)를 전송한다. 모든 것이 적절하다면, 슈 스미스는 담당 관리자로서 자기 롤에서 수신한 모든 정보를 사인하고 이를 다시 TAM(2)로 보낸다.

제11 단계에서, TAM(2)은 허용세트(100)를 구성할 것을 표명하는 일련의 서명(106)을 수신한다. 이것은 그러한 경우인지를 체크하기 위해, TAM(2)은 관리자로서의 존 브라운, 부서 관리자로서의 슈 스미스를 요구자(42)에 대해 롤 인증서를 검색한 다음, 서명과 롤 인증서(76)를 포함하는 문서(64)를 요구자로 전송한다. 그러므로, 도 12에 도시한 전자 문서(14)는 거래(40)의 정당성을 확인하는데 필요한모든 허가 세부사항(66)을 포함하여 작성된다. 이제 요구자(42)는 거래(40)의 클래스에 대한 허용 세트(100)를 구성하는 여행 요구에 서명 세트(106)를 보유한다. 이 정보는 요구자(42)가 사실상 여행 요구(54)를 행하도록 허가받은 검증자(130)로서 표시된 또 다른 유저를 납득시키는데 이용될 것이다.

도 12와 관련해서, 완료된 거래(40)는 (1)TA(80)가 서명한 거래 세부사항의 HTML, (2)요구자(42)가 서명한 유저 공급 입력, (3)관리자가 서명한 정보, 부서 관리자가 서명한 모든 것을 포함하여 요구자(42)가 보유한 서명(106)과 거래 세부사항(66)을 갖는 것으로 묘사된다.

도 13과 관련해서, 도 13에는 요구자(42)가 보유한 롤 인증서(76)와 허가 구조(98)가 도시되고 있다.

도 14와 관련해서, 도 14에는 거래 처리를 위해 요구자(42)가 여행 요구(54)를 검증자(130)에게로 전송하는 것을 포함하는 단계가 기술되고 있다. 이 방법을 검증 보조 방법(116)이라고 한다.

이러한 검증 방법을 양호하게 이해하기 위해서는, 허가 구조(98)가 어떻게 구성되는 가에 대한 세부사항을 이해하는 것이 중요하다. 검증 보조 방법(116)은 16 또는 20 바이트의 고정 길이 출력으로 임의 스트링을 매핑하는 암호화 해쉬 함수를 이용한다. 여행 요구(54)의 경우, 허가 구조(98)는 H1=해쉬(《정규직 종업원》): H2=해쉬(《관리자》);H3=해쉬(《부서 관리자》)를 산출하도록 허용 세트를 구성하는 3가지 롤(122)을 해싱함으로써(그에 따라 회사의 실제적인 허가 구조를 해싱함으로써) 구성된다.

예컨대, H1은 스트링 《정규직 종업원》의 해쉬라고 불려진다. 마지막으로, H1,H2,H3는 스트링으로서 다루어져 연결된 다음 T=해쉬(H1,H2,H3)로서 해쉬된다. "거래 기관(80)(TA)이 허가 구조(98)를 사인한다 "라는 구문은 TA가 "T" 거래(40)의 값을 사인함을 의미한다. 그러므로, TA(80)는 《해쉬중 해쉬》를 사인중이다.

유저는 TA(80)가 서명한 AS는 우선 집합적인 롤(122)을 해싱한 다음 한번 더 이 값을 해싱하는 것으로부터 도출된다는 것을 유저가 안다는 점에서 허가 구조(98)(AS)를 사인하는 일반적인 방법이라고 알고 있다.

특정 여행 요구와 관련하여, 요구자(42)는 (1)TA(80)가 서명한 HTML의 여행 요구, (2)롤《정규직 종업원》,《관리자》,《부서 관리자》에서 세 유저에 대응하는 3개의 롤 인증서(76), (3)정규직 종업원이 우선 사인한 다음, 관리자가 사인하고, 그 다음 부서 관리자가 사인한 도 12에 도시한 바와 같은 거래 세부사항(66), 도 5에 도시된 바와 같은 해쉬된 롤(122)에 대한 서명(106)을 보낸다.

다시, 도 5와 관련해서, TAM(2)은 검증자(130)로 하여금 작성되어 서명된 문서(114)를 검증하는 것을 가능하게 하는 검증 보조 방법(116)을 포함한다. 검증자(130)는 주로 여행 요구(54)인 거래(40)을 행하도록 요구자(42)가 권한 위임받았다는 것을 검증하는데 관심이 있다. 요구자(42)는 검증자(130)에게 거래 HTML(TA(80)가 서명), 롤 인증서(76)의 집합, 롤 인증서의 검증키(120)에 대응하는 각각의 사인키(150)에 의해서 서명된 거래 세부사항(66), 허가 구조(98)를 보낸다. 각 롤 인증서(122)는 롤 기관(180)(RA)에 의해서 서명됨을 상기하라(도 8). 제1 단계(132)에서, 검증자(130)는 문서(114)상의 각 인증서(76)를 체크하기 위해RA(180)의 검증키(120)를 이용한다. 제2 단계(134)에서, 검증자(130)는 공급된 롤 인증서(76)의 검증키(120)를 이용하여 거래 세부사항(66)에 대한 서명(106)을 체크한다. 제2 단계(134)의 보조 단계(136)에서, 요구자(42)가 권한 위임받았음을 체크하기 위해, 검증자(130)는 롤 인증서(76)로부터 명명된 롤(122)을 추출한다. 제2 단계(134)의 제2 보조 단계(140)에서, 전술한 바와 같이 해쉬 중 해쉬 프로세스를 이용하여 이름이 해쉬된다. 제2 단계(134)의 제3 보조 단계(142)에서, 거래(40)의 계산된 해쉬값은 AS(98)에서 수신한 거래(40)에 대한 값과 동일하도록 거래 기관(80)이 원래 서명하였는 지에 대해 체크된다. 해쉬 중 해쉬 프로세스의 출력은 해쉬 중 해쉬 프로세스에 대한 서명(106)을 체크하기 위한 입력으로서 사용된다. 생성된 해쉬 중 해쉬 스트링은 TA(8)가 서명한 해쉬된 스트링과 부합하면, 검증자(130)는 요구(52)가 허가되었다고 판단한다. 그렇다면, 거래(40)는 검증되었고 이러한 사실의 통지는 요구자(42)에게로 보내진다.

상기 보조 방법(116)에서, TAM(2)은 요구자(42)로부터의 정보를 검증자(130)로 전송한다. 선택적으로, 요구자(42)에서 검증자(130)로의 전송은 e-메일을 통해 행해질 수 있다. 요구자(42)는 TAM(2)을 이용하여 국부적으로 모든 허가 세부사항(66)을 모은 다음, 이 모든 정보를 e-메일을 통해 검증자(130)로 보낸다. 예컨대, 모든 서명(106) 및 코스트가 모여진 다음, 요구자(52)는 예약을 행하기 위한 처리를 수행하는 여행 대행사로 e-메일을 보낸다. 지금까지는 요구자(42)와 검증자(130)가 동일 회사에 있다고 가정하지 않았다. 이것은 TAM(2)은 검증자(130)가 동일 회사에 있는지 여부와 무관하게 기능하기 때문에 불필요하다. 그들이 동일 회사에 있으면, 그들은 인트라넷(25)에 의해 연결될 수 있어 동일 서버(54a)를 공유한다. 그래서 검증자(130)의 위치는 중요하지가 않다. 검증자(130)의 롤(122)은 요구자(42)가 제공한 정보를 검증하는 것이다.

거래의 유효성을 검증하기 위해 검증자(130)는 다음을 필요로 한다. 즉,

(1) 거래(40)에 사용된 롤 인증서(76)상의 서명(106)의 정확성을 체크하기 위해 사용되는 롤 기관(180)의 서명 검증키(120)

(2) 허가 구조(98)상의 서명(106)의 정확성을 체크(해쉬 중 해쉬 프로세스)하기 위한 거래 기관(80)의 서명 검증키(120)

(3) 허가 구조(98)에 대한 거래 기관(80)의 서명이 체크될 수 있도록 명명된 롤(122)이 어떻게 집합적으로 취하여 해쉬 중 해쉬 프로세스를 수행하는 지를 아는 것이 필요하다.

롤 기관(180)과 거래 기관(80)의 서명 검증키(120)는 그들이 보안을 필요로 하지 않는다는 점에서 공동 정보이다. 그러나, 기본적인 TAM(2)은 수개의 허용 세트(100)를 포함하도록 다음과 같이 확장될 수 있다. 예컨대, 여행 요구(54)는 또한 CEO 및 CEO 비서에 의해 허가될 수 있으며, 여행 요구에 대한 두 허용 세트(P1 및 P2)는 P=(정규직 종업원, 관리자, 부서 관리자}, P2={CEO,CEO 비서}이다.

그들이 구성하는 허용 세트(100) 및 롤(122)은 도 9에 도시한 바와 같이 허가 트리(154)(AT)로 정렬될 수 있다. AT(154)는 허가 구조의 일례이다. AT(98)를 사인하는 거래 기관(80)의 경우, AT는 전술한 것과 유사한 해쉬 중 해쉬 프로세스를 이용하여 행해지는 스트링으로 우선 변환되어야 한다.

먼저, 각 롤명(122)은 다음과 같이 H1, H2, H3, H4, H5로 주어지도록 해쉬된다.

H1=해쉬(《정규직 종업원》),

H2=해쉬(《관리자》),

H3=해쉬(《부서 관리자》),

H4=해쉬(《 CEO》),

H5=해쉬(《CEO 비서》)

이들 값은 다음과 같이 각 허용 세트에 대해 하나의 해쉬를 얻도록 해쉬되어야 한다. H6=해쉬(H1,H2,H3), H7=해쉬(H4,H5). H6는 허용 세트 P1에 대한 해쉬이고, H7은 허용 세트 P2에 대한 해쉬(P2')이다. 그러므로, 각 허용 세트(100)에 대한 하나의 해쉬가 있다. 이것을 허용 세트 해쉬라고 부른다. 해쉬(H1,H2,H3)는 H1,H2,H3가 연결된 다음 해쉬된 스트링임을 의미한다. 최종적으로, 트리에 대한 해쉬는 T=해쉬(H6,H7)로서 생성된다.

이러한 해싱 프로세스는 도 15에서 표현된다. 그것은 거래 기관(80)이 서명한 거래(40) 값이다.

검증자(130)는 요구자(42)가 하나의 허용 세트(100)로 상기 주어진 예에서와 같이 유사한 방식으로 주어진 거래(40)(이 경우, 여행 요구)에 대해서 권한 위임된다.

거래(40)에 대한 서명(106)을 검증하기 위해, 검증자(130)는 도 9 및 도 15와 관련하여 기술된 트리 해싱 프로세스의 모두 또는 일부를 반복한다. 도 15에서해쉬된 기준 항목들은 언해쉬된 기준 번호 다음에 오는 프라임에 의하여 도 9의 것과는 차별화된다. 요구자(42)는 허용 세트 P1를 구성하는 역할을 하는 사람으로부터의 서명(106)을 얻는다고 가정하자, 이 경우, 요구자(42)에게는 검증자(130)에 의해 검증자가 롤 명 《정규직 종업원》,《관리자》, 《부서 관리자》을 추출할 수 있는 3가지 롤 인증서(76)가 송신된다. 다음에 검증자(130)는 전술한 바와 같이 H1,H2,H3,H6을 형성할 수 있다. 그러므로, 검증자(130)는 거래(40)를 허가한 허용 세트(100)의 허용 세트 해쉬를 형성할 수 있다.

허가 트리(154)에 대한 서명 검증을 완료하기 위해, 요구자(42)는 거래(40)를 허가하는 허용 세트 해쉬 이외에 모든 다른 허용 세트(100)의 허용 세트 해쉬를 검증자(130)에게 제공하기 위해 필요로 할 것이다. 상기 예에서, P1은 거래(40)를 허가하고 있으므로, P2의 해쉬가 제공되어야 하며, 이 경우는 전술한 바와 같이 H7과 동일하다.

H7이 주어졌을 때, 검증자(130)는 검증자가 H6을 형성할 수 있기 때문에 T를 형성할 수 있고, T에 대한 서명(106)이 체크 가능하다. 따라서, 허가 트리(154)에 대한 서명(106)을 체크하기 위해, 요구자(42)는 롤(122)이 거래를 허가하고 있는 허용 세트(100)의 해쉬와 거래를 허가하고 있지 않은 각 허용 세트의 해쉬를 형성하도록 추출되어 해쉬될 수 있는 롤 인증서(76)를 검증자에게 송신한다. 이러한 두 정보로 검증자(130)는 거래(40)의 해쉬값을 계산한 다음 서명(106)을 체크한다.

상기 여행 요구에서, TAM(2)은 월드 와이드 웹을 통해 접촉됨에 따라, TAM은 웹 서버 프로세스라고 생각될 수 있다. 방법의 작업 흐름 시스템에서, 유저는 전용네트워크 채널을 통해 TAM과 양호하게 접촉한다. 두 실시예는 본질적으로 동일하다. 즉, TAM(2)은 유저가 엑세스할 수 있는 컴퓨터 시스템(20) 어딘가에 존재한다. TAM(2)은 또한 데이터베이스(70,82,46,202) 및 다른 유저에 엑세스 가능하다. 종래 기술에서 이해할 수 있는 바와 같이, 이는 예컨대 웹과의 인터넷 연결 또는 인트라넷을 통해 또는 e-메일에 의해서 달성될 수 있다.

TA(80)은 TA에 의해서 생성된 서명(106)이 신뢰된다는 점에서 요구자(42)와 검증자(130)에 의해 신뢰된다. 어떤 의미에서, TA(80)는 거래(40)의 HTML 양식(64)으로부터 정확하게 형성하여 그것을 사인하고 거래에 대한 허가 구조(98)를 형성하도록 신뢰된다. 그러나, 보다 넓은 의미에서, TAM(2)은 신뢰될 필요는 없다. 비록 유저가 대신하여 어떤 보안 기능을 수행하도록 TAM(2)을 신뢰할 지라도, 유저는 대신에 TMM이 수행한 모든 작업이 정확함을 입증하기 위한 국부적인 프로세스를 이용할 수 있다. 웹 실시예에서, TAM(2)은 인터넷(31)상의 검증자(130) 및 요구자(42)에 의해 엑세스 가능한 독립형 서버(4b)라는 점에서 중립적(즉, 모두에 의해 신뢰되는)이다. 특히, 신뢰가 진정 존재하는 콤포넌트는 거래 기관(80)(디지탈 거래를 작성하고, 허가 구조를 작성)과 롤 기관(180)(공인된 롤을 담당할 수 있는 사람에게 롤 인증서(76)를 할당)을 갖고 있다. 그러므로, 검증자(130)는 단지 HTML 양식(64)에 대한 거래 기관(80)과 허가 구조(98), 롤 인증서(76)상의 서명을 위한 롤 기관(180)에 의해서 생성된 서명(106)을 신뢰하는 것을 필요로 한다.

상기 여행 요구(54)에서, TAM(2)이 정보를 인출해서 서명(106)을 체크하기 때문에 요구자(42) 대신에 신뢰된 롤을 수행하고 있다. 예컨대, 모든 정보가서버(54b)상에 존재하는 공동 데이터베이스(전자 문서 데이터베이스(70), 허가 구조 데이터베이스(96), 롤 인증서 데이터베이스(82))상에 놓이도록 명확해야한다. 요구자(42)는 전자 문서 데이터베이스(70)에 엑세스 가능하며 여행 요구 HTML 문서(64)를 직접 얻어, TA(80)의 서명(106)을 그곳(TA(80)의 검증키(120)는 모두에게 이용 가능하다.)에서 체크한다. 다음에 요구자(42)는 허용 세트(100)를 형성하도록 서명(106)한 유저와 접촉하고, 롤 인증서 데이터베이스(82) 등에 엑세스함으로써 서명을 체크한다.

TAM(2)가 데이터베이스 인출 및 서명 수집을 수행할 때, 실용상 어떠한 방법으로 작용하는지를 차치하고 이것은 요구자(42)에 대한 신뢰이다. 신뢰 및 비신뢰가 유저가 최우선적으로 고려할 사항이라면, 다음에 TAM(2)은 모든 당사자에 의해서 신뢰받을 필요는 없다.

전술한 바와 같이, 기업 내부 허가 및 기업간 허가에 있어 뚜렷이 구별되는 점은 기업 내부 허가의 경우, 회사는 검증자(130)에게 그의 허가 구조를 드러내는 것에 대해 덜 관심이 있다. 기업간 허가의 경우, 허가 구조는 소정 작업에 대한 허가 트리(154)이며, 모든 허가 트리의 집합을 포함하는 데이터베이로의 엑세스는 회사 바깥의 유저에게 바인딩되어야 한다. 이미 기술한 바와 같이 TAM(2)을 기업간 시나리오에 적응하는 수개의 방법이 있다. 유저 UA 및 UB에 의해 표현되는 A 회사 및 B 회사간의 거래(40)의 예로 돌아가서, 대부분의 직접적인 접근은 각 회사가 회사 대신에 EA에 의해서 생성된 서명(106)을 검증하기 위해 사용될 수 있는 공개키를 갖는 기업 기관 EA을 갖게 하는 것이다. EA 기관은 모든 거래의 검증자(130)가회사내에서 시작하게 함으로써, 모든 기업간 거래를 허가한다. 즉, 거래가 허가되면, EA는 또 다른 회사의 유저에 의해 검증될 수 있는 이러한 효과에 대한 진술을 사인한다.

또한, 비록 TAM(2)이 분산된 작업 흐름 관리 시스템(6)내에서 양호하게 동작할지라도, 그 방법은 단순히 메시지 교환 메카니즘으로 구성 가능하다. 이 실시예에서, 전통적인 작업 흐름 관리 시스템(6)으로서 동작하지 않는 메시지 교환 메카니즘은 대신에 회사내에서 어떤 역할을 하는 사람과 요구자(42) 사이에서 HTML e-메일 또는 첨부물이 있는 e-메일와 같은 전자 메시지 흐름을 관리한다. 이러한 메카니즘의 관리는 데이터베이스의 관련 구조를 따르도록 구성된 풀다운 메뉴 및 서브메뉴와 파일 서버형 데이터 베이스(도 11에 도시한 데이터베이스70,96,82,202와 유사)를 이용하여 PC 상주 롤을 근간으로 하는 프로그램(즉, 유저(8)의 특정 롤에 적합하도록 커스터마이즈된 프로그램)과 같이 단순한 어떤것을 통해 실현된다. 전형의 메뉴 항목은 예컨대, 상이한 유형의 거래('거래 요구')를 열거하는 보조 메뉴를 여는 "거래 유형"이다. 특정 거래(40)를 활성화함으로서 그 거래가 필요로 하는 허용 세트(100)를 보여주는 또 다른 보조 메뉴를 열 수 있다. 허용 세트(100)를 활성화함으로써 첨부물의 거래 세부사항(66)을 갖는 e-메일을 연다. e-메일은 허용 세트(100)에서 모든 사람에게 사전 어드레스되어 서명 분배와 검증을 보다 간단히 한다.

도 15에서 기술하고 있는 허가 트리(154)의 해쉬를 이용하는 실시예는 롤 UR의 유저가 거래(40)를 요구할 수 있다는 점을 제외하곤 유저의 회사의 결정 구조에대한 소량의 정보만을 검증자가 안다는 이점을 가진다. 한편, EA 서버는 모든 기업간 요구가 검증 및 서명을 위해 EA로 갈 때, 병목 현상이 있을 수가 있다. 대안의 솔루션은 다른 회사에 의한 검증을 위해 허가 트리(154)를 공동 인터넷(31)상의 회사 외부에서 이용 가능하게 하는 것이다. 코스의 주요 문제는 AT(154)를 직접 드러나게 함으로써 회사내의 결정 프로세스에 대한 많은 정보가 드러나는 것이다. 다음 섹션에서, TAM(2)에 대한 수개의 변형이 기업간 허가에 대해 보다 적합하게 한다.

예컨대, 기업 기관(하위 레벨의 종업원이 거래를 허가하기 위한 권한을 가졌다는 확인을 위한 거래 관리자(80))으로부터 모든 거래(40)의 직접적인 승인을 얻는 대신에, 기업 기관은 단지 허가 구조(98)를 승인하는 것이 필요하다. 이제 허가의 검증이 항상 기업 기관을 통해 갈 필요는 없고, 오히려 허가는 허가 구조(98)의 요건을 단지 채울 필요가 있다.

또 다른 이점으로, 일단 TA(80)가 거래(40)와 허가 구조(98)를 작성한 다음, RA(180)는 롤 인증서(76)를 작성하고, 시스템(20)은 TAM(2)을 이용하여 작성한 계약이 용이하게 자동적으로 검증될 수 있다는 점에서 매우 신뢰할만 하다.

방법 2는 하나의 롤 허용 세트(100)로 기능함을 이해하여야 한다. 그러나, 허가 결과에 대한 추가 신뢰성 이점은 하나 이상의 롤(122)이 허용 세트(100)에서 규정되는 경우 얻어진다. 또한, TAM(2)의 하위 자원을 강조하는 실시예는 한번의 추출 및 검증을 제공함으로써 얻어질 수 있다, 즉 허용 세트(100)에서 먼저 열거된 롤 인증서(76)는 수개의 롤(122)로 구성된다. 상위 레벨의 종업원이 롤 인증서(76)가 우선 열거되도록 허용 세트(100)의 구조를 한정함으로써, 이 실시예의 신뢰성을향상한다. 그럼에도 불구하고, 이러한 실시예는 모든 롤 인증서(76)(즉, 거래(40)에 대한 롤 인증서(76)가 거래를 허가하는데 필요로 하는 특정 롤에 대응하는)와 허용 세트(100) 자체의 롤 내용을 추출하여 검증하는 실시예와 비교해서 다소 신뢰성이 떨어진다.

각종 변형 및 수정이 여기서 기술된 본 발명의 실시예에서 가능하다. 비록 본 발명이 예증의 실시예가 여기서 도시되고 기술되었지만, 광범위한 변형, 수정 대체가 전술한 개시 내용에서 고려될 수가 있다. 어떤 예에서, 본 발명의 어떤 특징들이 대응의 다른 특징적 구성요소를 사용하지 않고 채용될 수가 있다. 따라서, 전술한 개시 내용은 예증에 의하여 광범위을게 구성되고 이해되어야 하며 본 발명의 사상 및 범위는 첨부된 청구범위에 의해서만 제한된다.

허가 트리의 해쉬를 이용하는 실시예는 롤 UR의 유저가 거래를 요구할 수 있다는 점을 제외하곤 유저의 회사의 결정 구조에 대한 소량의 정보만을 검증자가 안다는 이점을 가진다.

또 다른 이점으로, 일단 TA가 거래와 허가 구조를 작성한 다음, RA는 롤 인증서를 작성하고, 시스템은 TAM을 이용하여 작성한 계약이 용이하게 자동적으로 검증될 수 있다는 점이다.

Claims

복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 프로세스 흐름을 갖는 컴퓨터화된 방법으로, 각 컴퓨터는 프로세서, 메모리, 입/출력 장치를 포함하며, 각 자원은 적어도 하나의 컴퓨터에 동작 가능하게 연결되어 상기 프로세스 흐름의 작업들 중 적어도 하나를 실행하는 컴퓨터화된 방법에 있어서,

허가(권한 부여, 인증;authorization)와 관련된 롤(역할) 인증서(role certificate)가 정본인지를 추출하여 확인하는 검증 가능한 방식으로 거래의 전자 허가를 어셈블하는 것을 특징으로 하는 컴퓨터화된 방법.
복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 프로세스 흐름을 갖는 컴퓨터화된 방법에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 프로세스 흐름의 활동 중 적어도 하나를 실행하는 컴퓨터화된 방법에 있어서,

허가와 관련된 적어도 하나의 유형의 롤 인증서가 정본인지를 추출하여 확인함으로써 거래의 전자 허가를 확인하는 것을 특징으로 하는 컴퓨터화된 방법.
제 1 항 또는 제 2 항에 있어서,

상기 롤 인증서와 관련된 롤은 해쉬(hash)되고, 해쉬된 롤의 데이터베이스내의 해쉬된 롤과 비교되는 컴퓨터화된 방법.
제 1 항 또는 제 2 항에 있어서,

상기 허가는 허가와 관련된 롤 인증서가 허가 구조(authorization structure)의 롤의 허용 세트(집합)의 롤과 대응함을 검증함으로써 추가 보증되며, 상기 롤 인증서는 거래를 허가하기 위해 요구되는 컴퓨터화된 방법.
제 4 항에 있어서,

상기 허가 구조는 허가 트리인 컴퓨터화된 방법.
제 4 항에 있어서,

상기 롤은 상기 거래와 관련된 롤 인증서로부터 추출되며, 추출된 각각의 롤은 해쉬되고, 해쉬된 롤은 연결되어 다시 해쉬된 다음, 허가 구조에 따라 다른 허용 세트의 해쉬와 연결되고, 다시 한번 해쉬되어 거래 관리자(TransactionAdministrator)가 사인한 해쉬 값과 비교될 수 있는 계산된 해쉬값으로 되며, 두 값이 일치하면 거래가 허가됨을 나타내는 컴퓨터화된 방법.
복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 분산 작업 흐름 관리 시스템에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 프로세스 흐름의 활동 중 적어도 하나를 실행하는 분산 작업 흐름 관리 시스템에 있어서,

허가와 관련된 적어도 하나의 유형의 롤 인증서가 정본인지를 추출하여 확인하는 검증 가능한 방식으로 거래의 전자 허가를 어셈블하는 방법에 의해 인코딩되는 것을 특징으로 하는 분산 작업 흐름 관리 시스템.
복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 분산 작업 흐름 관리 시스템에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 프로세스 흐름의 활동 중 적어도 하나를 실행하는 분산 작업 흐름 관리 시스템에 있어서,

허가와 관련된 적어도 하나의 유형의 롤 인증서가 정본인지를 추출하여 확인함으로써 거래의 전자 허가를 검증하는 방법으로 인코딩되는 것을 특징으로 하는 분산 작업 흐름 관리 시스템.
복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 메시지 교환 메카니즘에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 상기 컴퓨터 네트워크를 통해 다른 자원으로 송신될 메시지를 판독하고 기록할 수 있는 메시지 교환 메카니즘에 있어서,

허가와 관련된 롤 인증서가 정본인지를 추출하여 확인하는 검증 가능한 방식으로 거래의 전자 허가를 어셈블하는 것을 특징으로 하는 메시지 교환 메카니즘.
복수의 상호 연결된 컴퓨터와 복수의 자원을 포함하는 컴퓨터 네트워크를 통해 동작하는 메시지 교환 메카니즘에서, 각각의 컴퓨터는 프로세서, 메모리, 입출력 장치를 포함하며, 각 자원은 컴퓨터 중 적어도 하나에 동작 가능하게 연결되어 상기 컴퓨터 네트워크를 통해 다른 자원으로 송신될 메시지를 판독하고 기록할 수 있는 메시지 교환 메카니즘에 있어서,

허가와 관련된 적어도 하나의 유형의 롤 인증서가 정본인지를 추출하여 확인함으로써 거래의 전자 허가를 검증하는 방법으로 인코딩되는 것을 특징으로 하는메시지 교환 메카니즘.
제 7 항 내지 제 10 항 중 어느 한 항에 있어서,

상기 롤 인증서와 관련된 롤은 해쉬되어 해쉬된 롤의 데이터베이스의 해쉬된 롤과 비교되는 분산 작업 흐름 관리 시스템 또는 메시지 교환 메카니즘.
제 7 항 내지 제 10 항 중 어느 한 항에 있어서,

상기 허가는 허가와 관련된 롤 허가가 허가 구조의 롤의 허용 세트의 롤에 대응함을 확인함으로써 추가 보장되며, 상기 롤 인증서는 거래를 허가하는데 필요한 분산 작업 흐름 관리 시스템 또는 메시지 교환 메카니즘.
제 12 항에 있어서,

상기 허가 구조는 허가 트리인 분산 작업 흐름 관리 시스템 또는 메시지 교환 메카니즘.
제 12 항에 있어서,

상기 롤은 상기 거래와 관련된 롤 인증서로부터 추출되며, 추출된 각각의 롤은 해쉬되고, 해쉬된 롤은 연결되어 다시 해쉬된 다음, 허가 구조에 따라 다른 허용 세트의 해쉬와 연결되고, 다시 한번 해쉬되어 거래 관리자가 사인한 해쉬 값과 비교될 수 있는 계산된 해쉬값으로 되며, 두 값이 일치하면 거래가 허가됨을 나타내는 분산 작업 흐름 관리 시스템 또는 메시지 교환 메카니즘.
컴퓨터 판독 가능한 매체에 인코딩된 거래 허가 방법(a transaction authorization method)에 있어서,

(a) 거래 요구(a request for a transaction)를 수신하는 단계와,

(b) 전자 문서 데이터베이스로부터 상기 거래의 세부사항을 가진 문서의 전자 양식(an electronic representation)을 획득하는 단계와,

(c) 롤 인증서 데이터 베이스로부터 거래 관리자에 의한 서명으로 사인된 롤 인증서를 획득하고 그 서명을 확인하는 단계와,

(d) 거래 세부사항을 요구자로 복귀하는 단계와,

(e) 요구자가 사인한 완료된 양식을 요구자로부터 대기하고 수신하는 단계와,

(f) 허가 구조 데이터베이스로부터 거래에 대한 허가 구조를 요구하며,-상기 허가 구조는 거래 관리자에 의한 서명으로 사전에 사인되어 그 서명을 검증한다- 이 롤명에 사인하도록 접촉하기 위해 롤명(role name)의 허용 세트와 허용 세트의유저 멤버를 선택하는 단계와,

(g) 요구자의 서명과 함께 거래 요구의 세부사항을 선택된 허용 세트에 대응하는 롤을 갖는 다른 요구자에게로 전송하여 허용 세트에서 지시된 각 롤의 서명을 수집하는 단계와,

(h) 롤 인증서 데이터베이스로부터의 롤 인증서와 허용 세트의 각 멤버에 대한 서명을 요구하여 그들을 문서에서 인코딩하는 단계와,

(i) 서명과 롤 인증서를 포함하는 완료된 전자 문서를 요구자로 전송하는 단계-상기 완료된 전자 문서는 거래의 유효성을 확인하는데 필요한 허가 세부사항을 포함한다-를 포함하는 거래 허가 방법.
제 15 항에 있어서,

상기 롤 인증서와 허가 구조는 허용 세트 및 롤에 대한 해쉬된 정보로 이루어지며, 상기 해쉬된 정보는 언해쉬된 롤 인증서와 허용 세트를 대체하는 거래 허가 방법.
컴퓨터 판독 가능한 매체에 인코딩된 거래 검증 방법에 있어서,

(a) 거래와, 거래 기관(Transaction Authority)에 의해서 서명되는 관련된 거래 세부사항과, 롤 기관(Role Authority)에 의해서 사인된 명명된 롤을 확인하는 롤 인증서의 집합(a collection of role certificates)과, 상기 롤 인증서의 검증키에 대응하는 각각의 사인키에 의해서 서명된 검증키와, 허가 구조를 나타내는 전자 문서를 수신하는 단계와.

(b) 상기 롤 기관의 검증키를 이용하여 상기 문서상의 각각의 인증서를 체크하는 단계와,

(c) ⅰ) 롤 인증서로부터 명명된 롤을 추출하고,

ⅱ) 해쉬 중 해쉬 프로세스(a hash-of-hashes process)를 이용하여 해쉬하며,

ⅲ) 상기 허가 구조에서 수신된 거래에 대한 값과 같음을 보증하기 위해 상기 거래의 계산된 해쉬값을 상기 허가 기관에 의해 원래 사인된 것에 대해서 체크하고,

ⅳ) 상기 해쉬 중 해쉬 프로세스의 출력을 입력으로서 이용하여 상기 해쉬 중 해쉬 프로세스상의 서명을 체크하고, 생성된 해쉬 중 해쉬 스트링(string)이 상기 거래 기관이 사인한 해쉬된 스트링에 부합하면, 상기 요구가 허가되었음을 판단하는 방식

으로 공급된 롤 인증서의 검증키를 이용하여 상기 거래 세부사항상의 서명을 체크하는 단계와,

(d) 그 결과를 보고하는 단계를 포함하는 거래 검증 방법.
거래 허가 방법으로 인코딩된 분산 작업 흐름 관리 시스템에 있어서,

(a) 거래 요구를 수신하는 수신 수단과,

(b) 전자 문서 데이터베이스로부터 거래의 세부사항을 가진 문서의 전자 양식을 획득하기 위한 검색 수단과,

(c) 롤 인증서 데이터 베이스로부터 거래 관리자의 서명으로 사인된 롤 인증서를 얻어 그 서명을 검증하기 위한 검색 수단과,

(d) 거래 세부사항을 요구자로 복귀시키는 전송 수단과,

(e) 요구자가 사인한 완료된 양식을 요구자로부터 수신하기 위한 수신 수단과,

(f) 허가 구조 데이터베이스로부터 거래에 대한 허가 구조를 요구하는 질의 수단-상기 허가 구조는 거래 관리자의 서명으로 미리 사인된다-과,

(g) 서명을 검증하기 위한 검증 수단과,

(h) 이 롤명에 사인하도록 접촉하기 위해 롤명의 허용 세트와 허용 세트의 유저 멤버를 선택하는 선택 수단과,

(i) 요구자의 서명과 함께 거래 요구의 세부사항을 선택된 허용 세트에 대응하는 롤을 갖는 다른 요구자로 전송하여 허용 세트에서 지시된 각 롤의 서명을 수집하는 전송 수단과,

(j) 롤 인증서 데이터베이스로부터의 롤 인증서와 허용 세트의 각 멤버에 대한 서명을 요구하는 검색 수단과,

(k) 단계(j)에서 모은 서명을 상기 문서에서 인코딩하는 인코딩 수단과,

(i) 서명과 롤 인증서를 포함하는 완료된 전자 문서를 요구자로 전송하는 전송 수단-상기 완료된 전자 문서는 거래의 유효성을 확인하는데 필요한 허가 세부사항을 포함한다-을 포함하는 분산 작업 흐름 관리 시스템.
제 18 항에 있어서,

상기 롤 인증서와 허가 구조는 허용 세트 및 롤에 관한 해쉬된 정보로 이루어지며, 상기 해쉬된 정보는 언해쉬된 롤 인증서와 허용 세트를 대체하는 분산 작업 흐름 관리 시스템.
거래 검증 방법으로 인코딩된 분산 작업 흐름 관리 시스템으로서,

상기 거래 검증 방법은,

(a) 거래와, 거래 기관에 의해서 서명되는 관련된 거래 세부사항과, 롤 기관에 의해서 사인된 명명된 롤을 확인하는 롤 인증서의 집합(a collection of role certicates)과, 상기 롤 인증서의 검증키에 대응하는 각각의 사인키에 의해서 서명된 검증키와, 허가 구조를 나타내는 전자 문서를 수신하는 단계와.

(b) 상기 롤 기관의 검증키를 이용하여 상기 문서상의 각각의 인증서를 체크하는 단계와,

(c) ⅰ) 롤 인증서로부터 명명된 롤을 추출하고,

ⅱ) 해쉬 중 해쉬 프로세스(a hash-of-hashes process)를 이용하여 해쉬하며,

ⅲ) 상기 허가 구조에서 수신된 거래에 대한 값과 같음을 보증하기 위해 상기 거래의 계산된 해쉬값을 상기 허가 기관에 의해 원래 사인된 것에 대해서 체크하고,

ⅳ) 상기 해쉬 중 해쉬 프로세스의 출력을 입력으로서 이용하여 상기 해쉬 중 해쉬 프로세스상의 서명을 체크하고, 생성된 해쉬 중 해쉬 스트링이 상기 거래 기관이 사인한 해쉬된 스트링에 부합하면, 상기 요구가 허가되었음을 판단하는 방식으로 공급된 롤 인증서의 검증키를 이용하여 상기 거래 세부사항 상의 서명을 체크하는 단계와,

(d) 그 결과를 보고하는 단계를 포함하는 분산 작업 흐름 관리 시스템.