등록특허 10-0613316 고전적인 단일 사용 승인 구조 및 제품들은 많은 애플리케이션들을 위한 다양한 로그인 스크립트 또는 패스워드를 포함한 다. 예컨대, 미국 특허 번호 제5,944,824호는 복수의 네트워크 요소들에 단일 사용 승인하기 위한 시스템 및 방법을 개시 한다. 상기 특허는 프락시를 사용하는 경우가 아니라면, 브라우저 전용 사용자는 허용하지 않는다(Req.2와 비교). 또한, 상 기 특허는 인증 정보만을 다룰 뿐, 다른 신원 관련 정보(Req.3과 비교) 및 어떠한 프라이버시 정책들(Req.5)도 다루지 않 는다. 특히 X509와 같은 고전적인 공개 키 기반 구조(PKIs)는 본질적으로 오직 인증 정보만을 고려한다(Req.3과 비교). 정보가 고정된 인증서를 통해 운반되므로, 그 정보가 다른 신원 관련 정보를 포함하지 않는다면, 이 정보는 고정되는데, 이는 Req.5에 모순된다. 전용 클라이언트 소프트웨어에 있어서, 예컨대 속성 인증서로 다른 속성들을 구분하여 송신하는 방법 을 쉽게 디자인할 수 있지만, 이는 브라우저 전용 사용자와 호환되지 않고(Req.2), 특히 다양한 브라우저를 사용하기 위한 상호 운용 가능한 방법이 존재하지 않는다(또한 Req.2). 전자 상거래에서 개인 데이터를 전송하기 위한 고전적인 제품은 폼 채우기(form filler)이다. 그들은 폼 필드(form fields) 로 속성들을 드래그 앤 드롭(drag-and-drop)하기 위하여 브라우저와 긴밀히 상호 작용하거나, 폼 내의 필드들을 해석하 기 위하여 강력한 도구들을 사용한다. 통상적으로, 그들은 복잡한 클라이언트 소프트웨어 및 그 외에 프락시로서 동작하는 데, 이는 Req.2와 모순된다. 또한, 이러한 방법에는 서버가 정보를 요청하기 위한 대응되는 방법이 존재하지 않으므로, 완 전한 상호 운용 가능성(interoperability)을 제공하지 않는다. 마이크로소프트의 Passport는 하나의 고정된 위치 개체 또는 특정 도메인에서 사용자들에 대한 정보를 모두 갖는 적어도 한 세트의 개체들을 상정한다. 즉, 사용자에 의한 선택이나 예컨대 위치 개체로서 사용자의 은행을 선택하는 것과 같은 다 른 비지니스 관계에 기초한 선택은 존재하지 않는다고 상정하는데, 이는 Req.1에 반한다. 서버는 자신이 접속할 위치 개체 가 어떤 것인지에 대해 미리 알고 있다고 가정하고 있으므로, 이러한 특징은 다른 사용법이나 실시예에 의해 변경될 수 있 는 것이 아닌 이러한 시스템의 본질적인 특성이다. 소위 연합(federation)으로의 확장을 고려하면, 다음의 시스템과 같이 몇가지 다른 결점들이 여전히 존재할 가능성이 있다. Passport는 아직 제3자 확인을 필요로 하는 정보를 구분하지 못한다 (Req.3과 비교). 또한, 진정한 익명성(anonimity)을 허용하지도 않는데, 그 예로, 사용자들이 다수의 계정을 가지고, 어렵 게 관리함으로써 겨우 회피할 수 있는 전역적 사용자 식별자(global user identifier)가 존재하고, 또한, 위치 개체는 사용 자의 통신 상대방을 알게 된다(Req.4와 비교). 또한, 유연한 프라이버시 정책도 존재하지 않는다(Req.5). 또한, Passport 는, 보다 긴 데이터의 안전한 전송을 위해 필수적인 서버와 위치 개체 사이의 직접 접촉도 허용하지 않고, 이는 언급한 모 든 요구 사항들을 만족시키도록 연합 환경에서 달성하기에 사소한 문제도 아니다. 미국 특허 번호 제6,226,752호는 인증을 위한 방법 및 장치를 개시한다. 상기 특허는 Passport에서와 동일한 이유로 위치 개체에 대한 사용자의 선택권을 허용하지 않는다(Req.1과 비교). 상기 특허는 오직 인증 정보만을 고려하고(Req.3과 비 교), 따라서 아무런 프라이버시 정책도 존재하지 않으며(Req.5), 익명성을 위한 방법도 존재하지 않는다(Req.4). - 3 - 이러한 요구 조건들(이하에서 Req. 으로 표시함)을 충족시키는 신원 관리 시스템의 이익에 대해 논의하는 것이 도움이 될 것이다. Req.1 은, 최소한 자신의 사업과 관련된 관계에 있는 피고용자 또는 고객을 위한 위치 개체로서 역할을 수행하기 를 원하는 고용주 및 은행과 같은 회사에 의해 제시된다. 또한, 개인들이 신원 관리를 기꺼이 받아들일 것인지도 일반적으 로 믿는 것만큼 확실하지 않다. 현재로서는, "모든 계란을 한 바구니에 담는 것"에 대한 두려움과 프라이버시 및 신용에 대 한 우려가 단일 사용 승인 및 단순화된 폼 채우기(form filling) 모두에 대해 대부분의 사람들에게는 인식되는 이익을 넘어 선다. 또한, Req.1에서와 같은 자유로운 선택은 특히 사용자의 진정한 개인적인 정보를 위한 "로컬" 위치 개체를 허용하도 록 하는데 도움이 될 것이다. 이러한 프라이버시 및 신용에 대한 우려는 Req.4에 대한 동기를 부여한다. Req.2는 실용성을 위한 것으로, 이는 많은 사용자들이 부가적인 소프트웨어를 인스톨할 수 없고, 일부 사용자들은 다양한 인터넷 키오스크 (kiosk) 등으로부터의 정보화 사회 기반을 사용하고 있기 때문이다. 인터넷 키오스크는 예컨대, 인터넷 카페에서 공용 컴 퓨터로서 발견된다. Req. 3은 예컨대, 단 하나의 시스템에 있어서, 특정한 정보 및 특정한 동작에 대한 액세스를 일정한 사 용자들에게만 허용하고, 주소, 배송 정보 등의 전송을 사업 파트너에게만 허용하는 것과 같은 일반적인 적용성 (applicability) 및 사용자 친숙성(user friendliness)을 위한 것이다. Req.3의 마지막 부분 및 Req.5의 이점은 다음과 같이 요약할 수 있다: 적은 양의 데이터를 전송하는 것은, 운송 및 청구(billing) 정보와 같은 데이터가 자주 필요하고, 통신 상대 방과 독립적인 표준 전자 상거래 애플리케이션을 목표로 한다. 서적 및 여행 선호도와 같은 보다 구체적인 데이터에까지 확장하면, 상대방을 보다 잘 구분해야 할 것이다. 장기적인 광범위한 솔루션들은 제3자 확인(third-party confirmation)을 필요로 하는 데이터를 포함할텐데, 이들은 예컨대, 이러한 상대방으로부터 얻어진 개인의 영수증과 같은 거래 데이터들 또 한 관리하고, 이러한 영수증들을 사용하여 세금 소득 신고와 같은 다른 개인용 적용예와도 통합될 것이다. 또한, 장기적인 솔루션은 일정 공유(calendar sharing)와 같은 개인간 적용예와, 한 기업의 사용자가 가입한 서비스에 액세스하는 것과 같 은 기업간 적용예를 포함할 것이다.