KR101924683B1 - 요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증 - Google Patents

요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증 Download PDF

Info

Publication number
KR101924683B1
KR101924683B1 KR1020157033829A KR20157033829A KR101924683B1 KR 101924683 B1 KR101924683 B1 KR 101924683B1 KR 1020157033829 A KR1020157033829 A KR 1020157033829A KR 20157033829 A KR20157033829 A KR 20157033829A KR 101924683 B1 KR101924683 B1 KR 101924683B1
Authority
KR
South Korea
Prior art keywords
authentication
user
wtru
elements
mfas
Prior art date
Application number
KR1020157033829A
Other languages
English (en)
Other versions
KR20160004363A (ko
Inventor
요겐드라 씨. 샤
안드레아스 슈미트
비노드 쿠마 초이
락시미 숩라마니안
안드레아스 라이셔
Original Assignee
인터디지탈 패튼 홀딩스, 인크
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 인터디지탈 패튼 홀딩스, 인크 filed Critical 인터디지탈 패튼 홀딩스, 인크
Publication of KR20160004363A publication Critical patent/KR20160004363A/ko
Application granted granted Critical
Publication of KR101924683B1 publication Critical patent/KR101924683B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)

Abstract

사용자들이 상이한 서비스들에 대한 액세스를 얻을 때, 서비스들의 등급은, 예를 들어, 저가 서비스들로부터 고가 서비스들까지 가변할 수도 있다. 저가는 낮은 인증 강도가 요구됨을 나타낼 수도 있는 반면, 고가는 높은 인증 강도가 서비스에 액세스하는데 요구됨을 나타낼 수도 있다. 서비스 제공자(SP)에 의해 제공되는 제 1 서비스에 액세스하기 위한 인증 요건의 결정(204), 인증을 위해 이용가능한, 디바이스 또는 사용자에 연관된 하나 이상의 인증 요소들의 발견(208), 발견된 인증 요소들 중 적어도 하나의 발견된 인증 요소가 인증 요건을 달성하는데 충분한지의 여부의 결정(210), 만약 그렇다면, 대응 인증 프로시저들의 수행(212-228)을 포함하는, 디바이스를 인증하는 방법이 개시되어 있다.

Description

요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증{MULTI-FACTOR AUTHENTICATION TO ACHIEVE REQUIRED AUTHENTICATION ASSURANCE LEVEL}
관련 출원들에 대한 상호 참조
본 출원은 2013년 4월 26일자로 출원된 미국 가특허출원 제61/816,446호, 및 2013년 6월 7일자로 출원된 미국 가특허출원 제61/832,509호를 우선권 주장하며, 이로써 그 개시물들은 본원에 그 전부가 언급된 것처럼 참조로 통합된다.
클라우드에서의 서비스들 및 콘텐츠에 액세스하려는 모바일 디바이스들의 소비자 사용은 근년에 증가하였다. 덧붙여서, 기업들에 의해 "당신 소유의 디바이스를 가져와"(bring your own device, BYOD)를 향하는 경향이 증가하였는데, 이 경향에서는 고용인들이 기업 서비스들/데이터에 액세스하고 기업 데이터를 그들의 디바이스들 상에 국소적으로 저장하기 위해 그들의 개인 모바일 디바이스들을 사용할 수 있다. 모바일 지불 서비스들을 위한 모바일 디바이스들의 사용이 또한 증가하고 있다. 모바일 디바이스들의 증가된 사용의 위의 예들은, 다른 사용들과 함께, 보안에 대한 새로운 요건들로 이어졌다. 예를 들어, 단순한 패스워드들보다 더 강한 인증(authentication)의 형태들이 서비스들에 액세스하고 보안 동작들을 프로세싱하는데 종종 요구된다.
2-요소(factor) 인증이 사용자의 인증을 강화하기 위해 사용될 수도 있다. 일 예의 2-요소 인증이 제 1 인증 요소로서의 사용자의 아이덴티티(identity, ID) 및 패스워드와 제 2 인증 요소로서의 하드웨어/소프트웨어 기반 토큰에 기초하고 있다. 사용자 ID 및 패스워드가 사용자의 존재를 인증하고 토큰은 토큰 기능이 상주하는 디바이스의 사용자의 소유를 확인한다. 다중요소(multi-factor) 인증이 하나를 초과하는 요소를 사용하는 임의의 인증을 지칭한다. 예의 인증 요소들은 사용자 아이덴티티들과 함께 대응 패스워드들, 토큰들, 및 사용자의 생체인식/행동 양태들을 포함한다.
다중요소 인증에 대한 현존 접근법들이 유연하지 않고 사용자 친화적이지 않다. 본원에서 설명되는 다양한 실시형태들이 인증의 다양한 요소들을 통합하는 포괄적 아키텍처를 포함한다. 다양한 요소들은 사용자가 무엇을 알고 있는지(예컨대, 패스워드), 사용자가 누구인지(예컨대, 생체인식), 또는 사용자가 무엇을 가지는지(디바이스 인증)에 대응하는 요소들을 포함할 수도 있다. 예를 들어, 생체인식 인증은 패스워드 기반 인증과 결합될 수도 있다. 인증들은 네트워크 상에서 또는 사용자 장비(user equipment, UE) 상에서 수행될 수도 있다. 몇몇 경우들에서, 본원에서 설명되는 다중요소 인증이, 예를 들어 OpenID 프로토콜과 같은 다양한 프로토콜들을 활용한다.
일 예의 실시형태에서, 무선 송수신 유닛(wireless transmit/receive unit, WTRU) 또는 그 WTRU를 동작시키는 사용자 중 적어도 하나, 예를 들면 양쪽 모두가 인증된다. 예를 들어 서비스 제공자(service provider, SP) 또는 아이덴티티 제공자(identity provider, IdP)와 같은 네트워크 엔티티가, SP에 의해 제공되는 제 1 서비스에 액세스하기 위해 SP에 의해 요구된 제 1 인증 요건을 결정한다. 인증 요건은 요구되는 제 1 보증(assurance) 레벨을 나타낼 수도 있다. 예의 실시형태에 따라, 네트워크 엔티티는 인증을 이용할 수 있는 하나 이상의 능력들을 발견(discovery)한다. 하나 이상의 능력들은 WTRU 또는 사용자 중 적어도 하나와 연관될 수도 있다. 네트워크 엔티티는 발견된 하나 이상의 능력들 중 적어도 하나가 제 1 인증 요건, 예를 들면 SP에 의해 요구된 인증 보증 레벨(assurance level)을 달성하는데 충분한지의 여부를 결정할 수도 있다. 발견된 능력들 중 적어도 하나가 충분하다고 결정되면, 하나 이상의 인증 요소들이 선택된다. 하나 이상의 인증 요소들은 SP에 의해 요구된 제 1 인증 보증 레벨을 달성할 수도 있다. 그 후, 선택된 하나 이상의 인증 요소들 중 적어도 하나의 인증 요소의 수행이 트리거된다. 하나 이상의 인증 요소들의 성공적인 수행 시, WTRU 및 사용자는 제 1 서비스에 액세스할 수도 있다.
도 1은 일 실시형태에 따른 다중요소 인증을 위한 일 예의 아키텍처의 블록도이며;
도 2a 및 도 2b는 일 예의 실시형태에 따라, 도 1에 도시된 아키텍처에 의해 수행될 수도 있는 다중요소 인증에 대한 흐름도를 묘사하며;
도 3a 내지 도 3c는 다른 예의 실시형태에 따라 다중요소 인증에 대한 다른 흐름도를 묘사하며;
도 4는 일 예의 실시형태에 따라 예의 OpenID 표명들을 도시하는 호출 흐름도이며;
도 5는 보증 레벨들이 일 예의 실시형태에 따라 통신되는 방법을 도시하는 블록도이며;
도 6은 일 예의 실시형태에 따라 OpenID 아이덴티티 제공자(identity provider, OP)에 대한 예의 인터페이스들을 도시하는 블록도이며;
도 7a 내지 도 7c는 일 예의 실시형태에 따른 네트워크 기반 다중요소 인증을 도시하는 흐름도를 묘사하며;
도 8a 내지 도 8c는 다른 예의 실시형태에 따라 국소적으로 생성된 온-디바이스 인증 및 표명(assertion)을 도시하는 흐름도를 묘사하며;
도 9a 내지 도 9c는 또 다른 실시형태에 따라 네트워크 상에서 생성되는 표명과 결합되는 로컬 인증을 묘사하는 흐름도를 묘사하며;
도 10은 일 예의 실시형태에 따른, 서비스 제공자가 신뢰 당사자(relying party, RP) 및 아이덴티티 제공자(IdP)를 포함하는 예의 시스템을 도시하는 블록도이며;
도 11a 및 도 11b는 서비스들에 대한 의사 아이덴티티(pseudo identity, PID) 기반 이음매 없는 액세스를 도시하는 흐름도를 묘사하며;
도 12a 내지 도 12e는 서비스에 대한 PID 기반 이음매 없는 액세스의 다른 예를 도시하는 흐름도를 묘사하며;
도 13은 UE와 통신할 수도 있는 두 개의 신뢰의 원(circle of trust)들을 도시하는 블록도이며;
도 14는 일 예의 실시형태에 따라 다른 신뢰의 원(CoT)을 도시하는 블록도이며;
도 15는 다양한 실시형태들에 의해 구현될 수 있는 다중요소 인증에 대한 일 예의 아키텍처를 도시하는 블록도이며;
도 16은 일 예의 실시형태에 따라 도 15에 묘사된 예의 아키텍처의 변동을 도시하는 블록도이며;
도 17은 부가적인 예의 기능이 묘사된 도 15의 아키텍처를 도시하는 블록도이며;
도 18은 일 양태에 따르는 일 예의 디바이스 아키텍처시스템이며;
도 19는 일 예의 실시형태에 따라 다중요소 인증을 위한 일 예의 디바이스 아키텍처를 도시하는 블록도이며;
도 20은 일 예의 실시형태에 따라 다중요소 인증을 위한 일 예의 서브릿 아키텍처를 도시하는 블록도이며;
도 21은 일 예의 다중요소 인증 서버(multi-factor authentication server, MFAS)와 통신할 수 있는 다양한 데이터베이스들의 일 예를 도시하는 시스템도이며;
도 22는 위에서 참조된 아키텍처들을 사용하여 수행될 수 있는 다중요소 인증을 위한 호출 흐름도이며;
도 23은 부가적인 정책 엔티티들이 묘사되는 도 20에 도시된 예의 아키텍처를 도시하며;
도 24는 스마트 OpenID에 기초한 다중요소 인증 아키텍처의 일 예를 도시하며;
도 25는 착수(launch)될 수 있는 상이한 예의 인증 활동들을 도시하는 애플리케이션의 블록도이며;
도 26a 내지 도 26c는 일 예의 실시형태에 따라 통합식 패스워드 및 생체인식 인증을 도시하는 호출 흐름도이며;
도 27은 도 1에 도시된 예의 아키텍처의 변동을 도시하는 블록도이며;
도 28a 및 도 28b는 도 27에 도시된 아키텍처 로컬 생체인식 인증에 대한 호출 흐름도이며;
도 29a 내지 도 29d는 두 신뢰 당사자들을 사용한 일 예의 다중요소 인증에 대한 호출을 묘사하며;
도 30a 내지 도 30d는 하나의 RP가 구현되는 도 29a 내지 도 29d에 묘사된 호출 흐름의 변동을 묘사하며;
도 31은 일 예의 FIDO-MFAS 아키텍처를 도시하는 블록도이며;
도 32a는 하나 이상의 개시된 실시형태들이 구현될 수도 있는 일 예의 통신 시스템의 시스템도이며;
도 32b는 도 32a에 예시된 통신 시스템 내에서 사용될 수도 있는 일 예의 무선 송수신 유닛(WTRU)의 시스템도이며; 그리고
도 32c는 도 32a에 예시된 통신 시스템 내에서 사용될 수도 있는 일 예의 무선 액세스 네트워크 및 일 예의 코어 네트워크의 시스템도이다.
보증하는 상세한 설명이 예의 실시형태들을 예시하기 위해 제공되고, 본 발명의 범위, 적용 가능성, 또는 구성을 제한하는 의도는 아니다. 다양한 변경들이 엘리먼트들 및 단계의 기능 및 배치구성에서 본 발명의 사상 및 범위로부터 벗어남 없이 이루어질 수도 있다. 예를 들어, 실시형태들이 사용자 친화적 다중요소 인증을 제공기 위해, 예를 들어, 최적화된 OpenID 프로토콜과 같은 연합된 관리 기술들을 사용하여 본원에서 설명될 수도 있지만, 유사한 실시형태들이 다른 인증 엔티티들 및 기능들을 사용하여 구현될 수도 있다.
다중요소 인증이 하나를 초과하는 요소를 사용하는 임의의 인증을 지칭한다. 예의 요소들은 사용자 식별자들(ID들), 패스워드들, 토큰들, 및 사용자의 생체인식을 포함한다. 본원에서 설명되는 다양한 실시형태들에 따라, 보안 및 사용자 친화적 다중요소 인증의 구현예 및 전개배치가, 예를 들어, 사용자가 무엇을 아는지, 사용자가 누구인지, 및 사용자가 무엇을 가지는지를 포함하는, 사용자 인증의 다양한 양태들을 평가하는 다수의 인증 요소들에 기초한 사용자 또는 사용자의 모바일 디바이스의 인증을 포함할 수도 있다.
도 1을 참조하면, 예의 시스템(100)은 네트워크를 통해 서로 통신할 수도 있는 사용자 장비(UE)(102), 신뢰 당사자(RP)(104), 및 OpenID 서버(106)를 포함한다. 사용자(107)가 UE(102)를 동작시킬 수도 있다. 사용자 장비(UE)라는 용어는 아래에서 추가로 설명되는 바와 같이, 임의의 적절한 무선 송수신 유닛(WTRU)을 포함하는 디바이스를 지칭할 수도 있다는 것이 이해될 것이다. 예를 들어, WTRU가 고정식 또는 모바일 가입자 유닛, 페이저, 셀룰러 전화기, 개인 정보 단말기(PDA), 스마트폰, 랩톱, 태블릿 컴퓨터, 개인용 컴퓨터, 무선 센서, 소비자 가전기기들 등을 지칭할 수도 있다. OpenID(OID) 서버(106)는 임의의 적절한 아이덴티티 제공자에 의해 구현될 수도 있고, 따라서 OID 서버(106)는 아이덴티티 제공자(106)라고 지칭될 수도 있다는 것이 이해될 것이다. 게다가, RP(104)는 예를 들어 웹 서비스와 같은 임의의 서비스 제공자(SP)에 의해 구현될 수도 있고, 따라서 RP(104)는 SP(104)라고 또한 지칭될 수도 있다. 예의 시스템(100)은 개시된 요지의 설명을 용이하게 하기 위해 단순화되고 본 개시물의 범위를 제한하도록 의도되지 않는다는 것이 이해될 것이다. 다른 디바이스들, 시스템들, 및 구성들이 시스템(100)과 같은 시스템에 부가하여, 또는 그 대신에, 본원에 개시된 실시형태들을 구현하는데 사용될 수도 있고, 모든 이러한 실시형태들은 본 개시물의 범위 내인 것으로서 생각된다.
예시된 실시형태에 따라, OID 서버(106)는 다수의 인증 요소들을 조정 또는 용이하게 할 수도 있고, 따라서 OID 서버(106)는 다중요소 인증 계층(multi-factor authentication layer, MFAL)(106) 또는 마스터 IdP(106)라고 또한 지칭될 수도 있지만, 간략화를 위해 MFAL(106) 및 마스터 IdP(106)는 본원에서 다중요소 인증 서버(MFAS)(106)라고 지칭된다. 예를 들어, MFAS(106)는 네트워크 측이라고 일괄하여 지칭될 수도 있는 하나 이상의 다른 아이덴티티 제공자들로부터의 다수의 인증 요소들을 사용할 수도 있다. MFAS(106)는 클라이언트 측이라고 지칭될 수 있는 UE(102)로부터의 인증 요소들을 또한 사용할 수도 있다. 따라서, MFAL은 네트워크 측 또는 클라이언트 측으로부터의 다중요소 인증을 가능하게 할 수도 있다. 예시된 바와 같이, UE(102)는 OpenID 클라이언트(108)를 포함하는데, OpenID 클라이언트는 임의의 적절한 브라우저일 수 있고, 따라서 OpenID 클라이언트(108)는 브라우저(108)라고 또한 지칭될 수 있다. 예시된 바와 같이 UE(102)는, 예를 들어 지문 또는 눈 스캔과 같은 생체인식 인증 요소들을 수신 및 프로세싱하도록 구성될 수도 있는 생체인식 클라이언트(112)를 포함한다. 예시된 UE(102)는 SIM/UICC(114)라고 지칭될 수도 있는, 가입자 식별 모듈(subscriber identity module, SIM)(114) 또는 유니버셜 집적회로 카드(universal integrated circuit card, UICC)(114)를 더 포함한다. UE(102)는, 인증의 다수의 요소들을 조정하는 논리적 엔티티일 수도 있는 다중요소 인증 프록시(multi-factor authentication proxy, MFAP)(110)를 더 포함할 수도 있다. 예를 들어, MFAP(110)는 애플리케이션 프로그래밍 인터페이스(application programming interface, API)를 사용하여 액세스될 수도 있거나 또는 MFAP(110)는 브라우저(108)에 대한 플러그인으로서 구현될 수도 있다. MFAP(110)는 확장된 기능을 가질 수도 있고 마스터 IdP(106)의 프록시로서 작동할 수도 있다.
MFAP(110)는 다양한 기능들을 수행할 수도 있다. 예를 들어, MFAP(110)는 사용자(107) 및 UE(102)의 프로파일을 유지할 수도 있다. 그 프로파일은 사용자(107) 또는 UE(102)의 예를 들어, 인증 능력들과 같은 능력들을 포함할 수도 있다. MFAP(110)는 RP(104)와 인증 요건들을 협상할 수도 있다. 예로서, 인증 요건은 요구되는 특정 인증 강도를 표현할 수도 있는 보증 레벨을 지칭할 수도 있다. MFAP(110)는 또한 사용자(107) 및/또는 UE(102)와 인증 요건들을 협상할 수도 있다. 아래에서 추가로 설명되는 바와 같이, MFAP(110)는 보증 레벨들을 인증의 요소들로 해석할 수도 있다. 특히, MFAP(110)는 보증 레벨들을 적절한 인증 방법들 또는 프로토콜들의 세분화(granular) 레벨로 해석할 수도 있다. MFAP(110)는 UE(102) 또는 사용자(107)의 아이덴티티에 기초하여 적절한 아이덴티티 제공자들(IdP들)을 식별할 수도 있다. 게다가, MFAP(110)는 인증의 요소들을 대응 IdP들 또는 대응 클라이언트 인증 에이전트들(AA들)을 호출함으로써 트리거할 수도 있다. 일 예의 실시형태에서, MFAP(110)는 인증에 대한 정책 결정 포인트이다. MFAP(110)는 각각의 인증 요소에 대해 신선도 레벨을 유지할 수도 있다. 본원에서 사용되는 바와 같이, 인증 요소에 연관되는 신선도 레벨은 인증 요소를 사용한 인증이 수행되었던 시간을 나타낸다. 예로서, SP(104)는 인증 요소에 대한 특정한 신선도 레벨을 요구할 수도 있다. 추가 예로서, SP(104)는 인증이 일어난지 30 분이 안되었다면 인증이 용인가능하지만, 인증이 일어난지 30분이 지났다면 그 인증은 용인가능하지 않다고 결정할 수도 있다. 30 분의 시간은 단지 예시이고, 신선도 레벨 요건은 임의의 적절한 시간을 원하는 대로 규정할 수도 있다. 여전히 도 1을 참조하면, MFAP(110)는 복수의 인증 요소들의 결과들을 통합하여 표명을 생성할 수도 있다. 표명은 요구된 보증 레벨 및 요구된 신선도 레벨을 각각 충족 또는 초과하는 보증 레벨 및 신선도 레벨을 포함할 수도 있다. 신선도 레벨은 다수의 인증 요소들의 집계 신선도를 표현하는 통합된 신선도 레벨일 수도 있다. 다양한 인증 요소들의 결과들은 인증 서버(AS)에 의해 MFAS(106)에게 전달될 수도 있다. 대안으로, 그 결과들은 로컬 인증 에이전트들에 의해 MFAP(110)에게 전달될 수도 있으며, 그 MFAP는 그 다음에 그 결과들/표명들을 MFAS(106)에게 전달할 수도 있다. 통합된 신선도 레벨 대신, 또는 그것에 더하여, 표명은 복수의 인증 요소들의 각각에 대한 신선도 레벨을 포함할 수도 있다. MFAP(110)는 다수의 디바이스들을 사용하여 인증 디바이스들에게 일을 시킬 수도 있다. 예를 들어, 사용자(107)는 다중요소 인증에서 사용되는 다수의 디바이스들의 각각을 소유 또는 동작시킬 수도 있다. 이러한 시나리오는 분리 터미널(split-terminal) 시나리오라고 지칭될 수도 있다. MFAP(110)는 정책 계층이라고도 또한 지칭될 수도 있는 정책 엔진과 협업할 수도 있어서, 정책은 UE(102) 상에 국소적으로 저장될 수도 있거나 또는 정책은 예를 들어 MFAS(106) 및/또는 RP(104)와 같은 네트워크 엔티티와 동기화될 수도 있다.
도 1을 계속 참조하여, 클라이언트 측에서의 MFAP(110)는 마스터 IdP(106)가 수행하는 기능들과 비교하여 유사한 및 상보적 기능들을 수행할 수도 있다. 예를 들어, 온-디바이스 기반 인증이라고 지칭될 수도 있는, 사용자(107)가 UE(102) 상에서 인증되는 시나리오에서, MFAP(106)는 마스터 IdP(106)가 사용자(107)를 인증할 때 마스터 IdP(106)가 수행하는 기능들의 적어도 일부, 예를 들면 그 기능들의 전부를 흉내낼 수도 있다. MFAP(110)는, UE(102)의 사용자 인터페이스 또는 브라우저(108)를 통해, 사용자(107)가 패스워드 기반 인증을 개시할 것을 요청할 수도 있다. 마찬가지로, UE(102)와 특히 SIM/UICC(114)는, 예를 들어 포괄적 부트스트래핑 아키텍처(generic bootstrapping architecture, GBA) 인증과 같은 디바이스 인증을 수행하도록 트리거될 수도 있다. 생체인식 클라이언트(112)는 생체인식 인증을 수행하도록 호출될 수도 있다. 디바이스 측의 인증 클라이언트들의 각각에 대해, 네트워크 측에 연관된 인증 서비스가 있을 수도 있다. 예를 들어, 예시된 실시형태에 따라, 생체인식 클라이언트(112)는 마스터 IdP(106)의 부분일 수도 있는 생체인식 인증 서버(116)와 통신할 수도 있다. 대안으로, 생체인식 인증 서버(116)는 마스터 IdP(106)와는 별개이지만, 마스터 IdP(106)의 생체인식 프록시 기능부(118)를 통해 마스터 IdP(106)에 통신적으로 커플링될 수도 있다. 패스워드 서버(120)가 패스워드를 사용하여 사용자(107)를 인증하기 위해 UE(107)와 통신할 수도 있다. 패스워드 서버(120)는 마스터 IdP(106)의 부분일, 또는 대안으로 마스터 IdP(106)에 통신적으로 커플링될 수도 있다. 마스터 IdP(106)는 부트스트래핑 서버 기능부(bootstrapping server function, BSF)(124)와 상호작용하는 네트워크 애플리케이션 기능부(network application function, NAF)(122)를 포함하거나, 또는 대안으로 그 네트워크 애플리케이션 기능부에 통신적으로 커플링될 수도 있다. 마스터 IdP(106)는 홈 가입자 서버(HSS)(128)와 상호작용하는 AAA 서버(126)를 더 포함할, 또는 대안으로 그 AAA 서버에 통신적으로 커플링될 수도 있다. 마스터 IdP(106)는, 예를 들어 인증 요건에 기초하여, 디바이스 측 인증 클라이언트들과 연관될 수도 있는 다양한 인증 서비스들을 호출할 수도 있다.
일 예의 실시형태에 따라, 하나 이상의 인증 요소들이 인증된 후, 마스터 IdP(106)는 표명을 생성한다. 표명은 하나 이상의 인증 요소들에 의해 달성되는 보증 레벨을 포함할 수도 있다. 표명은 하나 이상의 인증 요소들에 연관되는 신선도 정보를 더 포함할 수도 있다. 그 표명은 사용자(107) 및 UE(102)가 RP(104)에 의해 제공되는 서비스에 대한 액세스를 수신하도록 RP(104)에게 제시될 수도 있다.
여전히 도 1을 대체로 참조하면, 다중요소 인증이 정책들, 이를테면 SP(104)에 의해 제공되는 서비스에 연관되는 정책들에 의해 도출될 수 있다. 본원에서 설명되는 것은 연합 아이덴티티 관리 시나리오들에서의 정책 주도(driven) 다중요소 인증을 지원하는 방법들이다. 예를 들어, SP(104)는 SP가 최종 사용자(107)와 직접 신뢰 관계를 확립할 필요가 없도록 다중요소 인증을 요청하기 위해 연합 서비스(federation service)를 사용할 수 있다. 게다가, 예를 들어 시스템(100)을 사용하여, SP(104)는 SP(104)가 다수의 인증 요소들에 대한 인프라를 갖는 일 없이 다중요소 인증을 요청할 수 있다.
서비스에 액세스하기 위하여, 사용자(107)는 서비스를 제공하는 SP(104)의 인증 요건들을 충족해야 할 수도 있다. 인증 요건들은 다양한 서비스들의 인증 정책들에 기초할 수도 있다. 예를 들어, SP(104)의 정책은, SP(104)에 의해 제공되는 서비스가 액세스되기 전에, 인증 강도라고 또한 지칭될 수도 있는 미리 결정된 보증 레벨을 인증이 충족시킬 것을 요구할 수도 있다. 따라서, 정책들은 보증 레벨들로서 표현될 수 있다. 보증 레벨들은 인증의 강도를 표시할 수도 있고, 높은 보증 레벨이 인증의 다수의 요소들을 요구할 수도 있다. 일 예의 실시형태에서, 보증 레벨은 사용자가 인증되는 보증 레벨을 지칭한다. 보증 레벨은, 인증 프로토콜들이 사용하는 것들인, 인증에 대한 다수의 요소들, 인증 요소의 유형(예컨대, 생체인식, 디바이스, 사용자), 인증의 신선도, 보충적 조건들, 또는 임의의 적절한 그것들의 조합에 기초할 수도 있다. 보증 레벨은 외부 기관에 의해 정의될 수도 있다. 일 예의 실시형태에서, 소망의 보증 레벨들이, 예를 들어, 미국 국립표준기술원(National Institute of Standards and Technology, NIST), 3세대 파트너십 프로젝트(3rd Generation Partnership Project, 3GPP), 월드 와이드 웹 컨소시엄(World Wide Web Consortium, W3C) 등과 같은 표준화 기구들을 포함하는 다양한 외부 기관들에 의해 특정된다. 예를 들어, 외부 기관이, 예컨대, 애플리케이션 자체의 보안 요건들, 요청된 서비스를 호스팅하는 회사의 보안 정책들 등과 같은 다양한 기준에 기초하여 보증 레벨들을 특정할 수도 있다. 추가 예로서, SP(104)는 SP(104)가 요청된 서비스를 사용자(107)에게 제공하기 위하여 요구하는 보증 레벨을 특정할 수도 있다.
몇몇 경우들에서, 요구된 보증 레벨이 요청되는 서비스에 연관된 위험에 기초한다. 예를 들어, 요청된 서비스가, 예를 들어 은행 계좌 정보를 송신 및 수신하는 은행업무 서비스와 같은 민감한 정보의 송신 및 수신을 포함한다면, 요구된 보증 레벨은 높을 수도 있다. 높은 보증 레벨이 다중요소 인증을 수행함으로써 충족될 수도 있다. 추가 예로, 요청된 서비스가 적은 위험, 예를 들어 개인 정보에 액세스 하지 못하는 서비스와 연관된다면, 요구된 보증 레벨은 낮을 수도 있다. 예를 들어, 낮은 보증 레벨이 패스워드 인증에 의해 충족될 수도 있다. 따라서, 예를 들어 SP(104)와 같은 서비스 제공자들은, 인증 강도가 서비스에 연관된 위험과 일치하도록 세분화 서비스들을 제공함으로써, 사용자들에게의 과도한 불편을 피할 수 있다.
일 예의 실시형태에서, SP(104)는 UE(102) 및 사용자(107)의 인증 능력들을 찾는다. 발견된 인증 능력들에 기초하여, SP(104)는 요구된 보증 레벨을 달성하기 위해 수행되어야 하는 하나 이상의 인증 요소들을 선택 및 특정할 수도 있다. 대안으로, 마스터 IdP(106)는 UE(102) 및사용자(107)의 인증 능력들을 발견할 수도 있다. 예를 들어, SP(104)는 인증 능력들의 발견을 IdP(106)에게 위임할 수도 있다. 따라서, 발견된 인증 능력들에 기초하여, IdP(106)는 요구된 보증 레벨을 달성하기 위해 수행되어야 하는 하나 이상의 인증 요소들을 선택 및 특정할 수도 있다. SP(104)는 SP(104)가 제공하는 요청된 서비스에 액세스하는 사용자(107)와 연관된 위험을 나타냄으로써 능력들의 발견을 IdP(106)에게 위임할 수도 있다. SP(104)는 사용자(107)가 SP(104)에 의해 제공되는 서비스에 액세스하기 위해 요구되는 보증 레벨을 또한 표시할 수도 있다. 예를 들어, 보증 레벨 요건이 다양한 수단들을 사용하여, MFAS(106)라고 지칭될 수 있는 마스터 IdP(106)에게 전달될 수도 있다. 예로서, PAPE 확장들이라고 간단히 지칭될 수 있는 OpenID 제공자 인증 정책(Provider Authentication Policy, PAPE) 확장들이, RP(104)가 PAPE 확장을 사용하여 보증 레벨 요건들에 관한 임의의 필요한 세부사항들을 MFAS(106)에게 제공하도록 구현될 수 있다. 정책 서버라고 일반적으로 지칭될 수 있는 MFAS(106)의 일 구현예에서, 정보를 수신하는 MFAS(106)가 임의의 주어진 보증 레벨에 기초하여, 동적으로 요구된 정책들을 생성하고 생성된 정책들 실행하도록 MFAS(106) 상의 지능형 정책 엔진이 구현된다. 정책들을 생성하기 위해 MFAS(106)에 의해 수신될 수 있는 예의 정보는, 예로서 제시되지만 제한의 예로서는 아닌, 사용자(107)의 정책, SP(104)의 정책, SP(104)에 의해 제공된 특정 서비스에 액세스하기 위한 요건들 등을 포함한다.
여전히 도 1을 참조하면, 서비스 제공자들, 이를테면 SP(104)가, 다양한 서비스들에 액세스하기 위한 인증 강도 요건들을 가질 수도 있다. 예를 들어, SP(104)에 의해 제공된 서비스에 액세스하기 위하여, 사용자들은 인증이 SP(104)의 인증 요건들을 충족시키도록 인증될 것이 필요할 수도 있다. 몇몇 경우들에서, 인증 요건이, 예를 들어 OpenID 2.0 또는 OpenID Connect와 같은 연합 아이덴티티 관리 프로토콜들을 사용하는 시나리오와 같은 위임된 인증 시나리오를 포함할 수도 있다. 본원에서 설명되는 다양한 예의 실시형태들이 다양한 연합 아이덴티티 프로토콜들(예컨대, SAML, OpenID 2.0, OpenID Connect)을 사용하여 구현될 수 있기 때문에, 특정 프로토콜의 맥락에서 설명되는 실시형태들이 그렇게 제한되지 않는다는 것이 이해될 것이다. 예를 들어, 연합 아이덴티티 제공자(104)에 의해 수행되고 있는 것으로서 본원에서 설명될 수도 있는 기능들을 서비스 제공자(104)가 수행하고 다중요소 인증이 연합되지 않도록 그 다중요소 인증은 다양한 실시형태들로 구현될 수도 있다. 아래에서 설명되는 정책 관리 기능부가, 사용자 친화적, 유연한 다중요소 인증을 가능하게 하기 위해 아이덴티티 관리 시스템에 추가될 수도 있는 플러그가능 모듈일 수도 있다.
위에서 언급했듯이, 예를 들어 RP(104)와 같은 서비스 제공자들은, 사용자의 인증이 그 인증을 위해 다수의 요소들을 사용할 것을 요구할 수도 있다. RP(104)는 사용자(107) 또는 사용자의 디바이스(UE(102))와 직접 신뢰 관계를 가질 필요가 없는데, 다른 엔티티들이 사용자(107) 또는 UE(102)를 인증할 것을 RP(104)가 요청할 수도 있기 때문이다. 예를 들어, 서비스 제공자들은, 그들의 애플리케이션들, 서비스들, 또는 서버들에서 인증 기능을 구현하는 서비스들에 대한 필요 없이, 이용가능한 인증 요소들의 임의의 조합을 사용하여 인증을 요청할 수도 있다. 따라서, 인증 요소들, 뿐만 아니라 사용자들 및 인증 요소들의 등록을 구현, 유지, 및 관리하는 부담이, RP(104)가 자신 소유의 다중요소 인증 인프라스트럭처에서의 투자 없이 다중요소 인증을 사용하도록 시스템(100)에 의해 핸들링될 수도 있다. 예의 인증 시스템들, 이를테면 시스템(100)은, 상이한 요건들, 상이한 사용자들, 및 상이한 디바이스 유형들에 맞는 유연한 다중요소 인증 솔루션을 제공할 수 있다. 게다가, 본원에서 설명되는 예의 시스템들은 MFAaaS(multi-factor authentication as a service)를 제공할 수도 있다.
몇몇 경우들에서, SP(104)는 사용자(107)에 의해 및/또는 사용자의 현재 디바이스(UE(102))에 의해 전달될 수 없는 인증을 요청했을 수도 있다. 예를 들어, 요청된 인증이, 특정 디바이스에 의해 수행될 수 없는 예를 들어 지문 인증과 같은 인증 요소를 요구할 수도 있다. 그런 경우들에서, SP(104)는 사용자/디바이스의 능력들에 기초하여 서비스 액세스를 협상할 수도 있다. 예를 들어, SP(104)는 UE(102) 및/또는 아이덴티티 제공자(106)에 의해 제공될 수 있는 인증 강도에 따라 액세스될 수 있는 서비스를 조정하기 위해 IdP(106) 및 UE(102)와 협상할 수도 있다.
예로서, 사용자(107)가 예를 들어 태블릿 컴퓨터일 수도 있는 UE(107) 상의 은행업무(banking) 애플리케이션을 사용하고 있고 사용자(107)가 거래를 하기 원하는 경우를 고려한다. 이 예에서 RP(104)인 은행은 생체인식을 사용하여 사용자(107)를 인식할 필요가 있을 수도 있지만, 사용자의 태블릿은 생체인식 인증을 제공하지 않는다. 그 경우, 뱅킹 애플리케이션은 사용자가 자신의 잔고를 체크하는 것을 허용할 수도 있지만, 다른 계좌에 대한 임의의 거래를 허용하지 않을 것이다. 따라서, SP(104)는 디바이스의 인증 능력들에 기초하여 제한된 액세스를 제공할 수도 있다. 제한된 액세스는 요청되었던 완전한 액세스보다 작을 수도 있지만, 액세스가 없는 것보다는 클 수도 있다.
본원에서 설명되는 바와 같이, 서비스들은 복수의 유형들, 예를 들면 두 개의 유형들로 분류될 수도 있다. 예를 들어, 엄격하고 분명한 요건들을 갖는 서비스들, 이를테면 특정 요소들로부터 인증을 받을 필요가 있는 서비스들은, 유형 1 서비스들이라고 지칭될 수 있다. 요구된 인증 강도의 표시에 관련될 수도 있는 보증 레벨을 포함하는 요건들을 갖는 예의 서비스들은, 유형 2 서비스들이라고 지칭될 수도 있다. 요구된 인증 강도는 다양한 인증 요소들 또는 상이한 인증 요소들의 결합들로 해석될 수 있다. 유형 1 서비스들을 제공하는 서비스 제공자들이 사용자 및 디바이스 능력들을 요구할 수도 있고 특정 요소들을 사용한 인증을 요구할 수도 있다. 유형 1 서비스들을 제공하는 서비스 제공자들은 그들 소유의 상이한 요소들로부터 인증 결과들을 평가할 수도 있다. 유형 2 서비스들은 충족될 필요가 있는 특정 보증 레벨을 요구할 수 있다. 요구되는 보증 레벨은 사용자 및 디바이스의 인증 능력들에 기초하여 선택될 수도 있는 하나 이상의 인증 요소들을 수행함으로써 충족될 수도 있다. 인증 요소들이 수행된 후, 인증 요소들의 각각으로부터의 결과들을 결합하는 결과가 서비스 제공자에게 반환될 수도 있다.
도 2a 및 도 2b를 참조하면, 유형 2 서비스에 대한 일 예의 다중요소 인증(200)이 도시되어 있다. 일 예의 실시형태에서, 다중요소 인증(200)이, 예를 들어 IdP(106)와 같은 시스템(100)에 의해 수행될 수도 있다. 도 1과 도 2a 및 도 2b를 참조하면, 예시된 실시형태에 따라, RP(104)는 요구된 인증 보증 레벨(202)을 포함한다. 인증 보증 레벨(202)은 사용자(107) 및 UE가 RP(104)에 의해 제공되는 특정 서비스에 액세스할 수 있기 전에 충족되어야만 하는 인증의 레벨을 표현할 수도 있다. 204에서, IdP(106)는 RP(104)로부터 인증 보증 레벨(202)을 획득한다. UE(102)는 자신의 인증 능력(206)의 표시를 포함할 수도 있다. 208에서, IdP(106)는 UE(102)의 인증 능력(206)을 획득 또는 발견한다. 210에서, 예시된 실시형태에 따라, IdP(106)는 발견된 UE의 인증 능력(206)이 인증 보증 레벨(202)을 충족시킬 수 있는지의 여부를 결정한다. UE의 인증 능력(206)이 요구된 인증 보증 레벨(202)을 충족시킬 수 있다면, IdP(106)는 RP(104)의 정책 요건에 기초하여, 요구된 인증 보증 레벨(202)을 달성하는 하나 이상의 인증 요소들을 선택할 수도 있다. 요구된 인증 보증 레벨(202)은 제 1 인증 보증 레벨(202)이라고 또한 지칭될 수도 있다. 예를 들어, 212에서, IdP(106)는 요구되는 인증 요소들의 리스트를 추출할 수도 있다. UE의 인증 능력(206)이 요구된 인증 보증 레벨(202)을 충족할 수 없다면, 214에서, IdP(106)는 RP(104)와 협상하여 제 2 인증 보증 레벨을 결정할 수도 있다. 제 2 인증 보증 레벨은 제 2 인증 보증 레벨이 UE(102)의 능력들과 동일하도록 UE(102)의 인증 능력들에 기초할 수도 있다. 예로서, 제 2 인증 보증 레벨은 제 1 인증 보증 레벨 미만일 수도 있다. 인증 보증 레벨이 협상된 후, IdP(106)는, 212에서, RP(104)의 정책 요건에 기초하여, 요구된 인증 보증 레벨을 달성하는 하나 이상의 인증 요소들을 선택할 수도 있다.
도 2b를 참조하면, 예시된 실시형태에 따라, 214에서, IdP(106)는 선택된 인증 요소들 중 하나가 수행될 필요가 있는지의 여부를 결정한다. 그 인증 요소들 중 하나가 수행될 필요가 있다면, 인증 요소는 216에서 리스트로부터 선택된다. 인증 요소가 리스트로부터 선택된 후, 218에서, 인증 요소에 연관된 신선도 레벨이 충분한지의 여부가, RP(104)의 정책 요건에 기초하여 결정된다. 인증 요소가 충분한 신선도와 연관된다면, 인증 요소에 대한 인증은 수행될 필요가 없고, 이전의 인증 정보가 220에서 표명에 추가될 수 있다. 인증 요소가 충분한 신선도와 연관되지 않는다면, 이는 인증 요소의 인증이 만료되었거나 또는 신선하지 않다는 것을 의미하여, 222에서 인증 요소에 대한 인증이 수행되고 정보가 표명에 추가될 수 있다. 224에서, 로깅 정보(예컨대, 인증의 시간, 재시도 횟수 등)와 같은 연관된 정보를 포함하는 인증 결과들이 IdP(106)에 저장될 수 있다. 인증 결과들은 예를 들어 다양한 인증들이 수행되었던 시간을 나타내는 타임스탬프와 같은 연관된 신선도 정보를 포함할 수 있다. 주어진 인증 결과가 저장된 후, 프로세스는 다른 인증 요소가 수행될 필요가 있는지의 여부가 결정되는 단계 214로 되돌아갈 수도 있다. 수행할 다른 인증 요소들이 없다면, 프로세스는, 통합된 표명이 생성되는 226으로 진행할 수도 있다. 통합된 표명은 하나 이상의 인증 요소들의 각각의 수행들에 연관되는 하나 이상의 인증 결과들에 기초할 수도 있다. 통합된 결과라고 지칭될 수도 있는 통합된 표명은, RP(104)에 의해 요구되는 인증 보증 레벨, 예를 들면 제 1 인증 보증 레벨 또는 제 2 인증 보증 레벨을 달성한다. 228에서, 통합된 표명은 RP(104)로 전송됨으로써, UE(102) 및/또는 사용자(107)가 RP(104)에 의해 제공된 서비스에 액세스하는 것을 가능하게 한다.
예시된 바와 같이, 도 2a 및 도 2b는 IdP에서의 인증들의 실행에 대한 흐름을 예시한다. 다른 대안들이 본 개시물의 범위 내에 있다. 예를 들어, 아래에서 설명되는 바와 같이, 인증 요소들은, 일부 요소들이 UE(102) 상에서 국소적으로 수행되고 다른 요소들이 IdP(106) 상에서 수행되도록 국소적으로 수행될 수 있거나 또는 분리될 수 있다. 덧붙여, 표명은 또한, 일 예의 실시형태에 따라, IdP(106)의 관여 없이 국소적으로 생성될 및 RP(104)에게 직접적으로 전달될 수도 있다. 이는, 예를 들어, 모든 인증들이 UE(102) 상에서 국소적으로 조정된다면, 구현될 수도 있다.
도 2a 및 도 2b를 대체로 참조하면, 다중요소 인증(200)은 개개의 인증 요소들의 순차적 프로세싱을 묘사하지만, 인증 요소들은, 원하는 대로, 번갈아 프로세싱될, 예를 들면 동시에 프로세싱될 수도 있다. 인증들의 순서가, 예를 들어, 각각의 인증 요소에 연관된 강도에 의해 결정될 수 있다. 예를 들어, 가장 강한 인증 요소는 가장 약한 인증 요소 전에 프로세싱될 수 있다. 다른 예로서, 사용자 입력을 요구하지 않는 인증 요소가 사용자 입력(예컨대, 지문)을 요구하는 인증 요소보다 먼저 프로세싱될 수도 있다. 각각의 인증 요소에 대해, 인증의 결과 및 신선도 정보가 저장될 수도 있다. 도시된 바와 같이, 요구된 인증 요소들이 IdP(106)에 의해 프로세싱된 후, IdP(106)는 요소들의 각각의 결과들을 표현하는 결합된 표명을 생성할 수 있다.
표명들은 유형 1 및 유형 2 서비스들을 커버할 수도 있는 유연한 데이터 구조들일 수도 있다. 표명들은 다중요소 인증 동안 생성될 수도 있다. 표명들은 디바이스에 기초하여 템플릿들을 사용할 수도 있다. 다음은 예로서 제시되지만 제한으로서는 아닌 표명 유형들의 일부 예들, 즉 포괄 인증 보증 레벨 표명, 책임/부인 방지(non-repudiation)를 위해 사용되는 일부 식별자들(예컨대, IMSI)에 대한 표명, 모든 요소들에 대한 전체 표명(예컨대, 챌린지-응답 쌍들, 요소 바인딩의 암호 표명을 포함함), 또는 체인식 표명 또는 서로 바인딩된 개개의 표명들의 콜렉션이다. 서로 바인딩된 표명들은 개개의 표명들이 서로 바인딩되는 방법의 표시를 포함할 수도 있다. 표명들은 사용자 디바이스 상에서 국소적으로 생성될 수도 있다. 이러한 표명들은 네트워크에서 생성된 표명들과 결합될 수도 있다. 표명이 위에서 설명된 바와 같이 상세한 포괄 보증 레벨(서비스 제공자에 대해 경량임) 또는 그 이상을 나타낼 수도 있다.
도 3a 내지 도 3c를 참조하면 일 예의 다중요소 인증(300)이 묘사되어 있다. 예시된 다중요소 인증(300)의 프로세싱은 두 개의 부분들로 나누어진다. 예시된 실시형태에 따라, 하나의 부분이 디바이스 상에서 실행되고, 따라서 "UE 중심 프로세싱"이라고 지칭될 수도 있고 하나의 부분은 네트워크를 통해 디바이스와 통신할 수도 있는 다양한 네트워크 엔티티들에 의해 실행될 수도 있다. 이 부분은 "네트워크 중심 프로세싱"이라고 지칭될 수도 있다. 예시된 인증(300)은 본원에서 설명되는 다중요소 아키텍처가 네트워크 서비스들에 대한 액세스뿐만 아니라 디바이스 상의 로컬 기능들에 대해 인증하고 액세스를 가능하게 하는데 사용될 수도 있다는 것을 보여준다. 302에서, 사용자 또는 UE 상의 애플리케이션이 인증 요청을 발행하는데, 이는 예를 들어 신뢰 당사자와 같은 네트워크 엔티티를 향해 사용자 및/또는 UE를 결국에는 인증할 수도 있다. 304에서, UE는 네트워크 접속이 이용가능한지를 결정한다. 네트워크 접속이 이용가능하지 않다면, 예시된 프로세스는 314로 진행하는데, 이 단계에서는 UE 인증 프록시, 예를 들면 MFAP(110)는, 로컬 인증 정책이 요청된 인증을 위해 구성되는지의 여부를 결정하여서, 인증이 국소적으로 실행될 수 있다. 네트워크 접속이 있다고 304에서 결정된다면, 프로세스는 단계 306로 진행하는데, 이 단계에서는 UE, 특히 MFAP(110)는, 로컬 인증을 수행하도록 구성된다. 314에서, 특정 로컬 인증 정책이 이용가능하다면, UE(MFAP)는 318에서 정책을 페치할 수도 있다. 특정 인증 정책이 이용가능하지 않다면, 디폴트 정책이 316에서 페치될 수도 있다.
도 3a 내지 도 3c를 계속 참조하여, 336에서, 예시된 실시형태에 따라, 인증 정책은 국소적으로 이용가능한 인증 요소들을 사용하여 실행된다. 네트워크 접속이 존재한다는 것이 338에서 결정된다면, UE, 특히 MFAP(110)는, 340에서 서명된 토큰을 생성하고, 그것을 SP로부터 서비스에 액세스하기 위해 SP로 전송한다. 서명된 토큰은 로컬 인증이 성공인지 또는 실패인지를 표시한다. 네트워크 접속이 338에서 이용불가능하다면, UE/MFAP는 342에서 성공적인 로컬 인증들을 체크한다. 예를 들어, (예컨대, 336에서) 성공적인 로컬 인증이 있다면, 344에서, 디바이스 자원에 대해 액세스가 허가될 수도 있다. 로컬 디바이스 자원이 UE 상에서 실행되는 애플리케이션을 포함할 수도 있다. 예의 실시형태에 따라, 로컬 인증이 성공되지 않았다면, UE 또는 UE 상에서 호스팅되는 자원에 대한 액세스는 346에서 허용되지 않을 수도 있다. 306에서, 네트워크 측 인증이 가능하고 결정된다면, 특정 인증 정책은 308에서 발견된다. 308에서, 특정 인증 정책이 UE 상에서 이용가능한지의 여부가 결정된다. 이용가능하다면, 프로세스는 단계 312로 진행하는데, 이 단계에서, 특정 SP에 연관될 수도 있는 특정 정책이 페치된다. 308에서, 그 정책이 이용불가능하다고 결정되면, 정책 준비 프로토콜 실행이 310에서 UE/MFAP 및 네트워크 측 IdP(예컨대, MFAS(106)) 간에 시도된다. 308 및 310에서의 단계들은 1회 이상 반복될 수도 있다. SP와 연관될 수도 있는 인증 정책을 수신 또는 페치한 후, 다양한 네트워크 측 및 로컬 인증 요건들이 320에서 분리된다. 322에서, 로컬 인증 요소들만이 SP에 의해 요구되는지의 여부가 결정된다. 로컬 인증 요소들만이 요구된다면, 예시된 실시형태에 따라, 프로세스는 324로 진행하는데, 이 단계에서는 로컬 요소들은 336에서 사용되는 기능과 실질적으로 동일할 수도 있는 기능에 의해 실행된다. 326에서, 토큰 체인이 준비될 수도 있다. 토큰 체인은 국소적으로 실행된 요소들에 대한 표명들을 포함할 수도 있다.
여전히 도 3a 내지 도 3c를 참조하면, 예시된 실시형태에 따라, 350에서, 네트워크 지원 인증이 SP에 의해 제공되는 요청된 서비스에 액세스하기 위해 요구되는지의 여부가 결정된다. 네트워크 지원 인증이 필요하다면, 프로세스는 단계 352로 진행할 수도 있으며, 그 단계에서 로컬 요소들을 통한 표명들을 포함하는 서명된 토큰은 요청된 네트워크 지원 요소들의 실행을 위해 네트워크 IdP/MFAS로 전송된다. 네트워크 지원 요소들이 요청되지 않는다면, 서명된 토큰은 354에서 SP로 전송되고, 인증은 356에서 성공적으로 종료된다. 322에서, 로컬 인증들이 SP의 특정 정책 요건들에 따라 적용가능하지 않다고 결정되었다면, 또는, 350에서, 로컬 인증 요소(들) 외에도 네트워크 지원 인증이 요청된다고 결정되었다면, 328에서, 네트워크 인증 요소들은 328/330에서 결정되었다. 332에서, 네트워크 인증 요소들은 개시되고 실행된다. 단계 332와 같은 단계들이, 예를 들어 MFAS(106) 및 MFAP(110)와 같은 하나 이상의 네트워크 엔티티들, 및/또는 본원에서 설명되는 하나 이상의 제 3 당사자 인증 서버들(예컨대, MNO, UICC 등) 간의 상호작용을 수반할 수도 있다는 것에 주의한다. 334에서, 예시된 실시형태에 따라, 로컬 인증 표명들을 이미 포함할 수도 있는 표명 토큰 체인은, 실행되었던 하나 이상의 네트워크 인증 요소들에 대응하는 표명들을 추가함으로써 수정된다. 따라서, 결합된 또는 통합된 표명으로서 일반적으로 지칭될 수도 있는 완전한 토큰 체인은, 348 및 354에서 UE를 통해 SP/RP로 전송되며, 356에서, 인증 프로세스가 종료된다.
본원에서 설명된 바와 같이, 디바이스들, 이를테면 UE(102)의 인증 용량들은, 발견될 수도 있다. 발견될 수도 있는 인증 능력들의 예들은 다음을 수행하는 능력들을 포함한다: 모바일 네트워크들에 의해 (예컨대, AKA, GBA, 또는 EAP-SIM을 사용하여) 지원되는 인증들과 같은 UlCC 기반 인증들; 예를 들어 SMS를 통해 전송된 OTP와 같은, 이차적인 채널을 사용하는 인증들; 생체인식 판독기 및 연관된 백엔드 서비스를 사용한 생체인식 인증들; 인터넷 IdP와 함께 사용되는 사용자 네임/패스워드(예컨대, 이메일 주소/패스워드)를 사용한 인증들; 암호 토큰들(예컨대, 정부 발행 e-아이덴티티 카드의 NFC 칩)을 사용한 인증들; 사용자 행동 분석을 사용한 인증들; 또는 사용자/UE 및 예를 들어 IdP와 같은 인증 엔드 포인트 간에 동작하는 챌린지/응답 메커니즘들을 사용한 인증들.
인증 기능들이라고도 또한 지칭될 수도 있는 인증 능력들이, SP 또는 IdP에 의해 검출될 수도 있다. 인증 능력이 특정 인증 요소를 사용하여 인증을 수행하는 능력을 지칭할 수도 있다. 따라서, 사용자 또는 디바이스의 인증 요소들이 SP 또는 IdP에 의해 검출될 수도 있다고 또한 말해질 수 있다. 하나의 실시형태에서, 인증 능력들이 검출되는 경우, 각각의 능력 및 단일 사용자 간의 보안 연관이 SP 또는 IdP에서 유지된다. 이 보안 연관은, 예를 들어 나중에, 특정 SP에 의해 요구될 수도 있는, 사용자 및 특정 인증 프로토콜에 대응하는 보증 레벨의 확립을 허용할 수도 있다. 게다가, 인증 요소들이 검출되는 경우, 각각의 인증 요소에 대응하는 식별자들은 사용자 아이덴티티 또는 UE의 식별자에 연관될 수도 있고, 인증 요소들 및 사용자들 또는 UE들의 연관은 사용자 인증 데이터베이스에 저장될 수도 있다. 연관을 저장하는 것은 IdP에 독립적인 상이한 당사자들에 의한 다양한 인증 요소들의 수행을 조정하는 것을 도울 수도 있다. 예를 들어, 지문들은 하나의 당사자에 의해 인증될 수도 있고 패스워드들은 다른 당사자에 의해 인증될 수도 있다. 사용자 인증 데이터베이스(DB)는 MFAS(106)에 상주할 수도 있다.
몇몇 경우들에서, 하나 이상의 인증 요소들이 디바이스의 제조의 시간에 디바이스 아키텍처로 구축된다. 다른 경우들에서, 인증 요소들은 소프트웨어 기능들이다. 이러한 기능들은 디바이스가 구매될 때 미리 로드될 또는 디바이스의 구입 후에 사용자에 의해 로드될 수도 있다. 본원에서 사용되는 다른 인증 요소들은 상기한 바의 조합일 수도 있다. 그러므로, 인증 요소의 수행에 있어서 외부 인증기가 전체 보증 또는 신뢰 레벨을 평가하는 것을 가능하게 하기 위해서, 인증의 요소들이 기능의 보안을 플랫폼 상에서 구현 및 실행되는 것으로서 고려하는 것이 중요하다는 것이 본원에서 인식되었다. 예를 들어, 디바이스가 지문 인증 능력을 제공할 수도 있지만, 지문 기반 인증의 수행 주변의 보안이 디바이스 보안 아키텍처 관점에서 약화된다(강하지 않다)면, 보증 또는 신뢰의 레벨은 조정될 수도 있다. 예시의 목적을 위한 예로서, 애플 아이폰 5S는 지문의 캡처부터 인증까지의 모든 기능들이 보안 방식으로 수행되고 메인 프로세서에게 보이지 않는 지문 인증 능력을 갖는다. 예시의 목적을 위한 추가의 예로서, 상이한 유형의 폰 디바이스(예컨대, 삼성 S5)가 지문 인증 능력을 또한 보유할 수도 있지만, 상이한 지문 인증 능력이 인증을 수행하기 위해 소프트웨어 및 하드웨어로 구현될 수도 있다. 예를 들어, 소프트웨어가 잘 보호되지 않는다면, 후자의 프로세서에서의 보증 또는 신뢰 레벨은 애플 아이폰 5S만 못하다고 간주될 수도 있다. 위의 예들은 심지어 모든 인증 능력들이 동일한 요소(예컨대, 지문들)에 의존하더라도, 그러한 모든 인증 능력들이 보안 관점에서 동일한 것으로 간주되지는 않는다는 것을 보여준다. 위의 예들은, 심지어 양쪽 모두의 디바이스들 상에서 수행되는 특정 인증 요소가 동일한 유형으로 되더라도, 보증 레벨은 그 특정 인증 요소에 대해 디바이스마다 다를 수도 있다는 것을 추가로 보여준다.
따라서, 디바이스에 의해 지원되는 인증 요소의 유형 뿐만 아니라 인증의 수행 주변의 보안 또한 보안적으로 확인하는 것이 중요할 수도 있다. 다양한 예의 실시형태들에 따라, 이는 디바이스의 고유의 불변 식별자로 시작하는 발견 프로토콜에 의하여 평가될 수도 있다. 부가적인 정보는, 식별자로부터, 신뢰성 있는 제 3 당사자들을 통해 모아질 수도 있다. 예를 들어, 하나의 당사자는 독립적이고 신뢰할 만한 검정 하우스(certification house)로부터 디바이스에 대한 검정을 획득한 디바이스의 제조업자일 수도 있다. 마찬가지로, 디바이스의 소프트웨어 양태들은 플랫폼 상의 소프트웨어 컴포넌트들의 보안 및 그런 소프트웨어 컴포넌트들의 검정 레벨의 평가를 통해 또한 평가될 수도 있다. 이 정보(예컨대, 하드웨어 및 소프트웨어 검정서들)는 디바이스의 증명서(attestation)와 함께 포함될 수도 있다. 따라서, 디바이스의 플랫폼의 총 보안 상태는 확인될 수도 있다. 특히, 예를 들어, 디바이스의 인증 능력들의 평가는, 디바이스가 디바이스 상에서 이용가능한 인증의 다양한 요소들을 사용함으로써 달성할 수 있는 인증 보증 레벨의 평가를 가능하게 하는 신뢰할 만한 방식으로 수집될 수도 있다.
다시 도 1을 참조하면, 디바이스 또는 사용자, 예를 들면 UE(102) 또는 사용자(107)의 하나 이상의 인증 능력들을 발견하는 것은, 다양한 예의 실시형태들에 따라 보안성있게 행해진다. 예를 들어, 사용자(107)는, UE(102)를 사용하여, IdP(106)의 웹사이트로 브라우즈할 수도 있다. IdP(106)는 사용자들 및 디바이스들을 등록시키는 MFAS(106)를 포함할 수도 있다. 보안 채널이 성공적으로 실행된 인증에 기초하여 사용자(107) 및 MFAS(106) 간에 확립된다. 예로서, 이메일이 사용자의 IdP(106) 식별자인 사용자의 이메일 주소로 전송될 수도 있다. 그 이메일은 MFAS(106)로부터 UE(102)로, 또는 다수의 디바이스들로 소프트웨어를 다운로드하기 위한 링크들을 포함할 수도 있다. 사용자에 의해 다운로드된 이 소프트웨어 조각은, MFAP(110)라고 지칭되는 MFAS(106)의 로컬 프록시로서 역할을 할 수도 있다. 따라서, MFAP(110)에는 사용자의 IdP 아이덴티티가 갖추어진다.
MFAP(110)는 다양한 로컬 인터페이스들 및 API들을 사용하여, UE(102) 상에서 이용가능한 인증 능력들, 예를 들어 인증 프로토콜들을 결정할 수도 있다. MFAP(110)는 인증 능력들(기능들)을 신뢰할 만한 방식으로 추가로 결정할 수도 있다. 인증 능력들은 신뢰할 만한 제 3 당사자에게 정보가 추적가능하도록 MFAS(106)에 의해 또한 발견가능할 수도 있다. 예를 들어, UE(102)의 인증 능력들은 UE(102)의 제조 동안 검정되고 영구 불변 디바이스 아이덴티티에 바인딩되어서, 검정된 인증 능력들에 대응하는 특정 인증들을 수행함에 있어서 외부에서 액세스 가능한 보증 레벨을 제공할 수도 있다. 일단 인증의 요소들의 적어도 일부, 예를 들면 모두가 확인 또는 발견된다면, MFAS(106)는 인증 능력들 및 정책들을 MFAP(110)에게 푸시할 수도 있다.
일 예의 실시형태에 따라, 몇몇 경우들에서, MFAS(106)는 인증 용량들에 연관된 특정 식별자들을 자율적으로 결정할 수도 있다. 예를 들어, MFAS(106)는 UE(102)의 아이덴티티(ID)에 대한 IMSI를 결정할 수도 있다. 몇몇 경우들에서, MFAS(106)는 몇몇 식별자들을 결정할 수 없을 수도 있다. 그런 경우들에서, MFAS(106)는 식별자(들)에 대해 사용자(107)에게 프롬프트할 수도 있다. 식별자들은 지원되는 인증 능력들에 대응하는, 예를 들어 백엔드 서버들의 주소 정보와 같은 임의의 다른 요청된 특성들과 함께 수집될 수도 있다. 사용자 기록이, 예를 들어, MFAS(106)에 의해 저장될 수도 있다. 사용자 기록은 사용자(107) 및/또는 UE(102)에 대응하는 다양한 인증 능력들에 대한 수집된 식별자들로 이루어질 수도 있다. 사용자 기록은 MFAS(106)에 의해 수집되었던 보충 데이터를 더 포함할 수도 있다.
여전히 도 1을 대체로 참조하면, UE(102)(또는 사용자(107))와, 로컬인 또는 네트워크에 있는 인증 엔드포인트들이라고 총칭하여 지칭될 수도 있는 인증을 수행하는 다양한 엔티티들 간의 다중요소 인증의 실행을 가능하게 하기 위해, 트리거 메시지들이 인증 엔드 포인트들에게 전송된다. 각각의 인증 요소에 대한 트리거 메시지들은 다양한 스테이지들에서 다중요소 인증으로 전송될 수도 있다.
몇몇 경우들에서, 트리거 메시지의 타겟은 모바일 디바이스, 이를테면 UE(102)이다. 다중요소 인증이 OpenID에 기초하는 일 예의 시나리오에서는, UE(102)로 향하게 되는, OpenID 서버(106)라고 지칭될 수도 있는 IdP(106)로부터 오는 HTTP REDIRECT 메시지가 있을 수도 있다. 재지향(redirect) 메시지는 통상 브라우저(108)를 인증 웹 페이지로 재지향시킨다는 것이 인식된다. 일 예의 실시형태에서, 브라우저(108)를 "HTTP REDIRECT http://..." 형태의 웹 주소로 재지향시키는 재지향 메시지 대신에, 상이한 URI 체계가 UE(102)에 의한 송신된 URI의 상이한 핸들링을 호출하는데 사용될 수도 있다.
다른 실시형태에서, 다양한 프로토콜들이 비-연합 또는 연합일 수 있는 다중요소 인증을 실행하기 위해 사용될 수도 있다. 예를 들어, OpenID는 하나의 이러한 프로토콜이다. SAML은 다중요소 인증들의 특정한 서브 세트를 수행하기 위해 사용될 수도 있다. 인증들 및 표명들의 결합된 결과는 예를 들어 OpenID/OpenID Connect에 기초하여, 또는 SAML을 통해 단일 표명을 사용하여 전송될 수도 있다. 대안으로, 프로토콜들의 조합이 인증들 및 표명들을 전송하는데 사용될 수도 있다.
일 예의 실시형태에 따라, MFAP(110)의 기능들 중 하나는 사용자(107)의 인증(사용자 인증)을 지원하는 UE(102)의 맞춤화된 프런트 엔드들을 지원하는 것이다. UE(102)의 맞춤화된 프런트 엔드가 인증의 보증을 달성하기 위해 사용될 필요가 있는 인증 요소들의 다양한 조합들을 지원할 수도 있다. 이러한 프런트 엔드가 인증 프런트 엔드(authentication front end, AFE)에 의해 생성될 수도 있다.
AFE UE(102) 상의 인증 흐름을 안내하는데 사용되는 사용자 프런트 엔드를 동적으로 생성할 수도 있다. 사용자 프런트 엔드는 예를 들어 HTML5 또는 자바스크립트와 같은 다양한 프로토콜들을 사용하여 생성될 수도 있다. 프런트 엔드는 AFE에 의해 자율적으로 또는 UE(102)와의 사용자 상호작용에 의해 생성될 수도 있다. 예를 들어, 생체인식, 패스워드들 등과 같은 인증 요소들은 사용자 상호작용을 요구하고 내장된 확인을 가질 수도 있다. 대안으로, 예를 들어 GBA 및 EAP-SIM과 같은, 디바이스 인증을 위한 모바일 네트워크 기반 요소들은 사용자(107)가 UE(102)와 상호작용하는 일 없이 실행될 수도 있다. 표명들 및 인증들의 악의적이고 비밀스런 생성을 방지하기 위하여, 인증 요소들은 적어도 사용자에 의해 확인될 수도 있다. 사용자 상호작용은 인증을 위해 사용자에 관련된 다양한 크리덴셜(credential)들의 사용을 허용하는 사용자(107)로부터의 허가를 수신하는 것을 포함할 수 있다. 크리덴셜들은 디바이스 정보 또는 다른 저장된 정보를 포함할 수도 있다. 예를 들어, 사용자 허가들은 인증 요소들이 트리거되기 전에 사용자(107)가 누를 필요가 있는 하나 이상의 버튼들을 통해 UE(102)에 의해 수신될 수도 있다. UE(102)의 사용자 인터페이스, 이를테면 디스플레이가, 각각의 인증이 완료된 후, 표시, 이를테면 컬러(예컨대, 녹색) 표시를 랜더링할 수 있다.
다양한 예의 실시형태들에서, 사용자(107)에게는 사용되고 있는 요소에 관한 정보를 보여주는 확인 스크린이 제시된다. 확인 스크린은 인증 요소가 사용되고 있는 웹 페이지 또는 서비스를 추가로 디스플레이할 수도 있다. 사용자(107)는 자신의 인증 정보가 사용될 수 있음을 검증할 기회를 가질 수도 있다. 사용자 인터페이스들은 그것들이 사용자, 디바이스, 서비스, 또는 인증에 기초하여 맞춤화되도록 동적으로 생성될 수도 있다. 서비스에 부담이 되지 않는 이 동적 사용자 인터페이스 생성의 경우, 아래에서 설명되는 바와 같이, AFE에게 떠넘겨질 수도 있다.
AFE에 의해 생성될 수도 있는 프런트 엔드는 API를 통해 MFAP(110)와 인터페이싱할 수도 있고, MFAP(110)는 다양한 인증 요소들과 그것들의 특정 API들을 통해 인터페이싱한다. AFE는 MFAP(110)가 프런트 엔드를 생성하고 다중요소 인증을 국소적으로 생성하는 것을 가능하게 하기 위해 디바이스 커넥터를 통해 MFAP(110)와 또한 통신할 수도 있다. 유사한 메커니즘이 MFAS(106)와의 인증의 조정을 또한 용이하게 할 수도 있다.
아래에서 추가로 설명되는 바와 같이, 인증 요소들은 네트워크 정책 엔티티와 동기화되고 로깅될 수도 있다. 로컬 로그라고 지칭될 수도 있는 UE(102) 상에 저장된 로그가, 예를 들어, MFAS(106)에 접속할 때, 사용될 수도 있다. 로컬 로그는 접속이 이용가능하게 될 때 MFAS(106)와의 동기화를 허용할 수도 있다. 로그는 세션 핸들, 실행된 특정 인증의 표시, 인증에 연관된 시간, 재시도 횟수, 인증의 결과 등을 포함할 수도 있다.
몇몇 경우들에서, 인증 프로세스를 반복함으로써 사용자(107)에게 부담을 주는 일 없이 이전의 인증 결과가 재사용될 수도 있는지를 결정하기 위해 각 개개의 인증 요소의 신선도가 체크된다. 게다가, 인증 요청들은 인증 요소들이 신선할 때 줄일 수도 있는데, 이는 네트워크 인증 서버들에 대한 부담을 감소시킬 수도 있다. 하나의 실시형태에서, MFAS(106)는 신선한 인증 요소들에 기초하여 소망의 보증 레벨에 대한 표명을 생성하는 것이다. 일 예의 시나리오에서, 다중요소 인증의 개개의 요소들이 신선하다면, 복수의 인증된 결과 중 적어도 하나, 예를 들면 모두가 재사용될 수 있다. 예를 들어, MFAS(106)는 요소들의 일부가 신선하지 않게 된 후 더 낮은 보증 레벨을 표명할 수 있다. 이러한 더 낮은 레벨은 서비스에 액세스하는데 적절할 수도 있고, 따라서 MFAS(106)는 수행될 새로운 인증들을 트리거하는 것이 필요하지 않도록 더 낮은 보증 레벨을 표명할 수도 있다. 대체 실시형태에서, MFAP(110)는 신선도를 제어한다. 예를 들어, 사용자(107)가 서비스 액세스와는 독립적으로 (예컨대, 생체인식을 사용하여) UE(102)에 대해 국소적으로 인증할 경우, UE(102)와의 사용자 인증의 신선도는 사용자(107)가 UE(102)와 인증할 때마다 업데이트될 수도 있고, 업데이트는 MFAS(106)에게 시그널링될 수도 있다. 각각의 표명은 표명과의 신선도 정보 연관을 포함할 수도 있다.
다시 도 1을 참조하면, 위에서 설명된 바와 같이, SP(104)는, SP(104)에 의해 제공되는 서비스에 액세스하는 것이 UE(102) 및 사용자(107)에게 허용되기 전에 인증을 요청할 수도 있다. SP(104)는 사용자 인증에 대한 요건을, 예를 들면 회사 정책 또는 법적 요건들에 따라 설정할 수도 있다. 요청되는 것은 액세스되고 있는 데이터 또는 서비스의 유형에 또한 기초할 수도 있다. 일 예의 실시형태에서, 서비스 정책에 따른 다중요소 인증을 가능하게 하기 위해, 보증 레벨 및 다중요소 인증을 실행하려는 정책은, 예를 들어 RP(104), UE(102), 및 IdP(106)와 같은 엔티티들 간에 전송된다. 예를 들어, RP(104)는 RP(104) 및 IdP(106) 간의 연관 동안 인증 요건들을 전달할 수도 있는데, IdP는 OpenID 아이덴티티 제공자(OP)일 수도 있고, 따라서 IdP(106)는 OP(106)라고 또한 지칭될 수도 있다. OP(106)는, 예를 들어, Yadis에 기초한 발견 프로토콜들로 지원된 인증 보증 레벨들을 알릴 수도 있다.
OpenID 프로토콜 실행에서 정책 요건들을 제기하는 일 예의 방법이 RP(104)가 PAPE를 사용하는 것이다. PAPE는 다중요소 인증 및 요소 신선도를 요청하는데 사용될 수도 있는 포괄적인 용어들을 포함한다. PAPE는 커스텀 보증 레벨 지정들을 전송하기 위하여 확장들을 정의하는 메커니즘을 더 포함한다.
MFAS(106)는 인증이 수행되기 전에 인증 요소들을 전달 또는 인증 요소들을 협상하기 위한 서비스 제공자들에 대한 인터페이스를 포함할 수도 있다. 예를 들어 현존 OpenID 2.0 또는 OpenID Connect 발견 프로토콜들에 통합될 수도 있는 일 예의 발견 프로토콜을 사용하여, SP(104)는 지정 사용자, 이를테면 사용자(107)가 이용할 수 있는 인증 요소들의 리스트를 결정할 수도 있다. 일 예의 실시형태에서, MFAS(106)의 부분일 수도 있는 보증 레벨 데이터베이스 및 로직 기능이, 서비스의 위험 요건을 대응 신선도 요건들을 갖는 인증의 요소들로 해석한다. 대안으로, 서비스는 UE(102)의 공급된 인증 능력들에 기초하여 인증 요소들의 세트를 직접적으로 특정할 수도 있다. 사용자(107)에 대한 구성 및 아이덴티티 매핑에 의존하여, 예를 들어, MFAS(106)는 사용자(107)에 연관된 모든 디바이스들의 리스트 및 사용자(107)에 연관된 모든 요소들을 반환할 수 있다. 대안으로, MFAS(106)는 사용자(107)가 사용하고 있는 현재 디바이스(102)에만 연관되는 인증 요소들의 리스트를 반환할 수 있다. 인증 능력들의 리스트에 기초하여, SP(104)는 적합한 인증 요소 또는 다수의 요소들의 조합을 선택하고, 선택된 하나 이상의 요소들에 따라 인증을 요청할 수도 있다.
여전히 도 1을 대체로 참조하면, 다른 예의 시나리오에서, SP(104)는, 예를 들어, 상이한 사용자들/UE들에 의해 지원되는 인증의 요소들을 확인하는 부담을 피하기 위하여, 요청된 위험 프로파일에 일치하는 보증 레벨로 UE/사용자가 인증될 것을 요청할 수도 있다. 예를 들어, SP(104)는 UE(102)에게 서비스에 액세스할 것을 요청하는 최소(와 또한 원한다면 최대) 보증 레벨을 요구할 수 있다. MFAS(106)는 그 다음에 인증에 사용하기 위해 인증 요소들의 리스트를 컴파일할 수도 있다. 리스트는 이 보증 레벨을 달성하기 위해 사용자(107)에 대한 사용의 용이함 또는 최적합(best fit)에 기초하여 컴파일될 수도 있다.
MFAS(106)는 인증 요소들의 리스트를 결정하기 위해 상이한 특성들을 고려할 수 있다. 예의 파라미터들은 인증 비용, 사용자 선호도들, 사용자에 대한 최소의 마찰, 프라이버시 요건들, 인증 프로세스의 보안, 디바이스 상의 에너지 소비, 네트워크 및 백엔드 상의 대역폭 부하, 현존 인증들의 법적 조건들, 신선도 및 재사용 가능성 등을 포함한다. 이들 예의 특성들의 평가에 기초하여, MFAS(106)는 소망의 보증 레벨을 달성하기 위하여 사용될 수 있는 요소들의 리스트를 도출할 수 있다.
위에서 언급했듯이, 특정 인증 요소들이 SP(104)에 의해 요청될 수도 있다. 상이한 서비스들 또는 URL 도메인들에 대해, 서비스는 상이한 보증 레벨들과 연관될 수도 있다. MFAS(106)에서, 예를 들어, 정적 URL 정책들이 상이한 인증 요소들에 대해 일치될 수도 있고 그들 인증 요소들은 상이한 URL 도메인들을 위해 호출될 수 있다.
하나의 실시형태에서, MFAS(106)에서, 인증 요소들에 대한 URL 서브스트링들의 매핑은 정적 서비스 제공자 URL들에 대한 대응 인증 요소들을 실행하기 위해 사용된다. 덧붙여, 특정 서비스 제공자의 서브도메인들은 상이한 인증 요건들을 또한 요청할 수도 있다. 예로서, 아마존 체크아웃 시나리오에서, URL 서브스트링 아마존/카트가 요구된 보증 레벨일 수도 있는 인증 요건에 대해 매핑된다. "openid.return_to"가 이 서브스트링을 포함한다면, 특정된 인증 요소들은 호출된다. 다르게 말하면, RP가 RP부터 요청되고 있는 서비스들에 기초한 대응 (예컨대, 더 많은 세분화) 보증 레벨 요건들을 가질 수도 있다. 고 위험 거래가 더 낮은 위험 거래와 비교하여 높은 보증 레벨을 요구할 수도 있다. 따라서, 보증 레벨들 요건들은 RP에 직접 묶여 있지 않을 수도 있는 대신, RP에 의해 제공되는 서비스들에 묶여 있을 수도 있다. 다시 도 1을 참조하면, 소망의 인증 요건이 RP(104)에 의해 OP(106)로 동적으로 중계될 수도 있다. 선택된 인증 요소들에 기초한 인증은 MFAS(106)에 의해 수행될 수도 있고, 선택된 인증 요소들을 포함하는 인증의 결과는 MFAS(106)로부터 RP(104)에게 전달될 수도 있다.
인증 요소를 트리거하기 위한 일 예의 메시지가, soid.scheme://<method>.<factor>/<factor-data>이며, 여기서 "soid.scheme"는 인증 요소들을 핸들링하는 UE(102)에서의 일반 기능을 호출하는 URI 스키마이다. 이 내부 엔티티의 주요 태스크는 UE(102) 내의 요소 인증 프로세스를 디스패치하는 것이다. 예를 들어, 디스패치는 인증을 수행할 UE(102) 내의 적절한 기능에 대한 호출을 포함할 수도 있다. 상이한 URI 스키마들의 처리에 대한 기능은 UE(102)의 플랫폼 운영 체제 내에 포함될 수도 있다. 디스패칭을 위해, URI의 URL 부분에서의 로케이션 정보는 사용될 수도 있다. 예를 들어, 이는 위에서 도시된 바와 같은 계층적 패션으로 행해질 수 있는데, 여기서 <method>는 생체인식 요소들 또는 SIM 카드(114)와 같은 보안 엘리먼트 상에 상주하는 요소들과 같이, 공통 트레잇(trait)들로 인증 요소들의 서브세트를 제어하는 핸들러 기능을 표시한다. <factor> 키는 인증될 실제 요소를 표시할 수도 있다. <factor-data>는 UE(102) 상의 인증 기능에 필요한 임의의 데이터를 그것의 태스크를 수행하기 위해 전송하는데 사용될 수도 있다. 예를 들어, 그것은 요소가 챌린지 응답 인증일 때 챌린지 값들을 유지할 수도 있다. <factor-data>의 예들은, 제한 없이 다음의 예로서 제시된다:
soid.scheme://sim.eap-sim/?challenge_rand=<RAND>,challenge_autn=<AUTN>,...
soid.scheme://biometric.fingerprint-biokey/...
soid.scheme://soid.local/?<OpenID-parameter-set>
soid. scheme://soid. simple-password/?salted-digest=<SALTED_DIGEST_VALUE>,salt=<SALT_VALUE>
위의 "soid.scheme://soid.local/?<OpenID-parameter-set>는, 요소가, 로컬 OP라고 지칭될 수도 있는, UE(102) 상에 위치된 OpenID 제공자 엔티티임을 표시한다는 것이 이해될 것이다. 위에서 열거된 마지막 예는 패스워드가 사용자(107)로부터 국소적으로 요청되는 상이한 체계이다. 로컬 인증 에이전트가, 이 경우, 예를 들어, 사용자(107)에 의해 제공된 패스워드를 해싱하고, 그것을 소금 파라미터를 갖는 (예컨대, HMAC를 사용하는) 표준 암호 방법과 결합하고, 그것을 예정된 다이제스트 파라미터와 결합함으로써, 사용자(107)를 인증할 수도 있다. 이 방법은 HTTP-DIGEST 인증과는 적어도 부분적으로 유사할 수도 있다.
위에서 설명된 트리거 메시지들의 일 예의 확장이 다음의 예에 의해 주어진다: soid.scheme://soid.multi/?<multi-factor-policy>. UE(102) 상의 로컬 엔티티가 이러한 인증 요소 요청들('soid' 키라 지칭됨)을 핸들링할 수 있고, 로컬 엔티티는 다수의 인증 요소들을 핸들링할 수 있는 서브-컴포넌트를 포함할 수도 있다. 당해 서브컴포넌트는 예에 따라 키 'multi'라 지칭된다. 단일 인증 요소들에 대한 임의의 필요한 데이터, 및 부가적으로 그것의 조인트 실행을 위한 정책들, 이를테면 단일 요소들을 위해 요구된 신선도가, 부속된 파라미터 세트에 포함될 수도 있다.
대안으로, 서버로부터 호출되는 UE 로컬 요소 인증은, 로컬 인증 클라이언트를 개시하게 하기 위해 웹 페이지 내에 삽입된 커스텀 자바스크립트 코드 및 그 속의 커스텀 API 호출들이라고 지칭될 수도 있다. 이러한 호출들의 예들은 3GPP TR 33.823에 기재되어 있다.
여전히 도 1을 대체로 참조하면, 시스템(100)의 분산 및 연합 성질로 인해, 서비스 제공자들, 특히 SP(104)는, 사용자(107)에 의해 전달될 수 있는 것보다 더 많은 요소들 또는 더 강한 인증을 요구할 수도 있다. 달성가능한 또는 달성된 인증 강도가 서비스 요건들에 일치하지 않는다면, SP(104)는 제시된 인증 표명이 요구에 따르지 않기 때문에 액세스를 거부할 수 있거나, 또는 SP(104)는 수신된 인증 표명에 기초하여 서비스 기능을 다운그레이드할 수 있다.
하나의 실시형태에서, 소망의 보증 레벨이 인증 요소들의 임의의 조합에 의해 달성될 수 없다면, IdP(106)는 네트워크/UE/사용자 지원 메커니즘이 인증 강도 또는 보증 레벨을 개선하도록 부추킬 수도 있다. 예를 들어, IdP(106)는 SP(104)와의 입찰 프로세스에서, 주어진 사용자(107) 및 디바이스(102)가 합리적으로 도달가능한 최고 보증 레벨로 MFAS가 응답할 수 있는 상호작용 프로토콜을 시작할 수도 있다. SP(104)는 그 다음에 새로운 보증 레벨에 대한 인증을 요청할 수 있거나, 또는 SP(104)는 서비스가 낮은 보증으로 액세스될 수 있도록 서비스 제공을 다운그레이드 또는 변경한다. 대안으로, 예를 들어 챌린지-응답 프로토콜을 수행함으로써, 더 강한 형태의 인증 요소가, 초기에 요청된 서비스가 액세스되게 할 수도 있다.
UE(107) 또는 사용자(102)에 의해 달성가능한 인증 보증 레벨을 발견하는 부분으로서, MFAS(106)는 이전의 인증들을 아마도 재사용하기 위해 과거의 인증 요소들의 신선도를 또한 고려할 수 있다. 신선도 요건들은 인증 요소마다 그리고 서비스마다 상이할 수도 있다. 협상의 부분으로서, 서비스 제공자들은 특정한 인증 요소들에게 적어도 완화된 신선도 요건이 요구되는 '완화된' 정책 모드를 표시할 수도 있다. 인증 요소에 의존하는 가변하는 신선도 요건들은 상이한 레이트들에서 시간에 걸쳐 쇠퇴할 수도 있는 측정된 인증 요소들을 고려한다.
몇몇 경우들에서, 예를 들어 행동 또는 생체인식 분석을 사용하여 연속적인 인증을 수행하는 능력이 존재하는 경우, MFAS(106)는 당해 능력을 이용하고 당해 인증 요소의 측정된 보증 레벨을 적절히 이용할 수도 있다. 연속적인 인증은 개입 없이 또는 최소 상호작용으로 사용자를 인증한다는 이점을 갖는다.
상이한 서비스들 또는 URL 도메인들이 상이한 보증 레벨들과 연관될 수도 있다. MFAS에서, 정적 URL 정책들이 상이한 인증 요소들에 대해 일치될 수도 있고 그들 인증 요소들은 상이한 URL 도메인들을 위해 호출된다. 하나의 실시형태에서, MFAS(106)에서, 인증 요소들에 대한 URL 서브스트링들의 보증 레벨 매핑들은 정적 서비스 제공자 URL들에 대한 대응 인증 요소들을 실행하기 위해 사용된다. 덧붙여, 특정 서비스 제공자의 서브도메인들은 상이한 인증 요건들을 또한 요청할 수도 있다. 일 예로서, 아마존 체크아웃 시나리오의 경우, URL 서브스트링 아마존/카트가 요청된 인증 요건에 대해 매핑될 수도 있다. "openid.return to"가 이 서브스트링을 포함한다면, 특정 인증 보증 레벨에 대응하는 인증 요소들이 호출된다.
소망의 보증 레벨은 RP(104)에 의해 OP(106)에게 동적으로 중계될 수도 있다. 통신되는 보증 레벨에 기초하여, 요청 사용자(107)에게 요청된 인증 요소들은 MFAS(106)에 의해 수행되고, 수행된 인증들 상에서 획득된 보증 레벨 및 추가의 정보가 다양한 예의 실시형태들에 따라 RP(104)로 전달된다. PAPE 확장들이 다양한 정보를 전달하기 위해 사용될 수도 있다. PAPE 확장들은 URL 기반이고, 정보를 요구된 보증 레벨에 관련된 OP(106)에게 제공할 수도 있다. PAPE 메시징은 일관되게 사용될 적절한 요청 및 응답 메시징 스키마를 요구할 수도 있다.
일 예의 실시형태에서, 다음의 파라미터들은 OpenID 인증 요청 동안 RP(104)에 의해 포함된다:
_ openid.ns.pape
Value: http://specs.openid.net/extensions/pape/1.0
openid.pape.preferred_auth_policies: OP(106)가 사용자(107)를 인증할 때 충족해야하는 인증 정책들을 표현하는 영 이상의 인증 정책 URI들. 다수의 정책들이 요구된다면, OP(106)는 할 수 있는 한 그것들의 대부분을 충족시켜야 한다. 정책들이 요구되지 않는다면, RP(104)는 예를 들어 인증 나이와 같은 다른 정보에 관심이 있을 수도 있다. 이 파라미터는 인증 정책 URI들의 분리된 리스트를 제공한다. 예들은 다음을 포함한다:
openid.pape.preferred_auth_policies=
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant (or)
http://schemas.openid.net/pape/policies/2007/06/multi-factor
_ openid.pape.auth_level.ns.<cust> : (옵션) 이는 커스텀 보증 레벨에 대한 이름 공간을 나타낸다. 보증 레벨들 및 그것들의 이름 공간들은 다양한 당사자들, 이를테면 국가 또는 산업 특정 표준 기관들, 또는 다른 그룹들 또는 개인들에 의해 정의된다. 이 파라미터는 이 보증 레벨을 나타내는 URL을 포함한다.
예들은 다음을 포함한다:
openid.pape.auth_level.ns.nist=http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
openid.pape.auth_level.ns.jisa=http://www.jisa.or.jp/spec/auth_level.html
일 예의 실시형태에서, 위의 필드는 MFAS(106)에 의해 정의되는 커스텀 보증 레벨 표준을 정의하는데 사용될 수도 있다. 상이한 인증 요소들에 대한 매핑을 특정하는 보증 레벨에 대해 MFAS에서 정의되는 전반적인 정책들이 참조로서 사용될 수도 있다.
_ openid.pape.preferred_auth_level_types: (옵션) RP 요청들이 그것의 선호도의 순서로, 응답에 존재하는 하는 커스텀 보증 레벨 이름 공간들에 대한 이름 공간 별명들의 리스트. 이 파라미터는, RP의 선호도의 순서로 이름 공간 별명들의 페이스 분리된 리스트를 포함한다. 일 예는 다음이다:
openid.pape.preferred_auth_levels=jisa nist
이 커스텀 필드는 MFAS에서 해석될 수도 있는 이 사용자에 대한 요구된 인증 레벨을 전송하는데 사용될 수도 있고, 대응 인증 요소들이 호출될 수도 있다.
신뢰 당사자의 요청에 응답하여, 다음의 파라미터들은 일 예의 실시형태에 따라 OpenID 인증 응답에 포함된다. 응답 파라미터들은 인증 응답의 서명에 포함된다. 이 확장을 지원하는 OP가 다음의 파라미터들을 신뢰 당사자에 의해 요청되지 않더라도 포함할 수도 있다. 응답 파라미터들은 일 예의 실시형태에 따라 OpenID 제공자와의 최종 사용자의 현재 세션을 기술한다. 예의 응답 파라미터들은, 제한 없이 예로서 제시된 다음을 포함한다:
_ openid.ns.pape
Value: http://specs.openid.net/extensions/pape/1.0
_ openid.pape.auth_policies: OP가 최종 사용자를 인증할 때 충족했던 정책들을 표현하는 하나 이상의 인증 정책 URI들. OP를 통해 충족되었던 정책들이 응답에서 다른 정보를 운반하기 원하지 않는다면, 이 파라미터에는 일 예의 실시형태에 따라 http://schemas.openid.net/pape/policies/2007/06/none의 값이 포함된다. 이 파라미터는, 예를 들어, 다음의 인증 정책 URI들의 공간 분리된 리스트를 제공할 수도 있다:
openid.pape.auth_policies=http://schemas. openid.net/pape/policies/2007/06/multi-factor 또는 http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
_ openid.pape.auth_time: (옵션) 최종 사용자가 표명된 정책들을 맞추는 방식으로 OP에게 능동적으로 인증될 때의 가장 최근의 타임스탬프. 일 예의 실시형태에 따라, 시간들은, "Z"로 표시된 UTC 시간대에서 포맷팅된다. 하나의 예에 따라 소수 초들이 포함되지 않는다. 이 파라미터의 일 예는 다음이다: 2005-05-15T17: 11:51Z. RP의 요청이 "openid.pape.max_auth_age" 파라미터를 포함하였다면, OP는 일 예의 실시형태에 따른 자신의 응답 내에 "openid.pape.auth_time"을 포함한다. "openid.pape.max_auth_age"가 요청되지 않았다면, OP는 자신의 응답에 "openid.pape.auth_time"을 포함할 것을 선택할 수도 있다.
_ openid.pape.auth_level.ns.<cust> : (옵션) 다양한 파티들, 이를테면 국가 또는 산업 특정 표준화 기구, 또는 다른 그룹들 또는 개인들에 의해 정의된 커스텀 보증 레벨에 대한 이름 공간. 이 파라미터는 이 보증 레벨을 나타내는 URL을 제공할 수도 있다. 예를 들어 다음이다:
openid.pape.auth_level.ns.nist=http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63Vl_0_2.pdf
openid.pape.auth_level.ns.jisa= http://www.jisa.or.jp/spec/auth_level.html
_ openid.pape.auth_level.<cust>: (옵션) 최종 사용자를 인증할 때 OP에 의해 채용된 인증 방법 및 정책들에 대응하는 위의 표준화 기구, 그룹, 또는 개인에 의해 정의된 바와 같은 보증 레벨. 커스텀 보증 레벨 정의가 자신의 이름공간 내에서 표현되는 부가적인 서브파라미터 값들을 정의할 수도 있지만, 단순화를 이유로, 이는 가능하다면 회피될 수도 있다. 이 파라미터는 이 보증 레벨에 따라 정의된 스트링들을 제공할 수도 있다.
예들은 다음을 포함한다:
openid.pape.auth_level.nist=1
openid.pape.auth_level.jisa=2
위에서 설명된 PAPE 확장들은 신뢰 당사자(104) 및 MFAS(106) 간에 통신을 허용할 수도 있다. openid4java 라이브러리는 PAPE 통신들을 위해 사용될 특정한 클래스들을 제공한다. 그들 클래스들은 요청된 및 충족된 보증 레벨들 등에 관하여 OP(106) 및 신뢰 당사자(104) 간에 필요한 정보를 통신하기 위해 조작될 수 있다.
위에서 설명된 동적 보증 레벨 기능에 대해, MFAS(106)는 보증 레벨들에 대한 적어도 일부, 예를 들면 모든 가능한 정책들의 매핑을 저장할 수도 있다. 예를 들어, 보증 레벨들은 요청된 수의 네트워크 및 로컬 인증 요소들에 대해 매핑될 수도 있다. MFAS(106)는 사용자들이 그들의 디바이스 능력들에 의존하여 선택할 수도 있는 가능한 네트워크 및 로컬 인증 요소들의 리스트를 또한 유지할 수도 있다. 사용자(107)는 등록 프로세스 동안 정책들 또는 선호도들을 특정하는 것이 허용될 수도 있다. MFAS(106)에서의 정책들의 전체 세트와 사용자(107) 및 UE(102)의 능력들로부터, MFAS(106)는 인증하기 위해 선택할 수 있는 정책 서브 세트를 생성할 수도 있다.
다양한 예의 실시형태들에 따라, 보증 레벨들은 일부 신뢰할 만한 기관에 의해 정의된 사용자 진위의 보증의 레벨들의 열거물들을, 인증 프로토콜들 및 보충적 조건들, 이를테면 인증의 신선도에 매핑한다. 소망의 보증 레벨들은 상이한 외부 기관들에 의해 결정될 수 있다. 몇몇 경우들에서, 신뢰 당사자 또는 서비스 제공자가 요청된 서비스를 사용자에게 제공하기 위해 요구된 보증 레벨을 결정하는 외부 기관일 수 있다. 그 외부 기관은 기준의 상이한 세트에 기초하여 이들 보증 레벨들을 바로잡을 수도 있다. 예의 기준들은 애플리케이션 또는 서비스 자체에 대한 보안 요건들, 또는 요청된 서비스들을 호스팅하는 회사의 보안 정책들을 포함한다.
일단 소망의 보증 레벨들이 책임 기관에 의해 특정되면, 일 예의 실시형태에 따라, 소망의 인증을 수행할 필요가 있는, 사용자 에이전트라고 총칭하여 지칭되는 사용자 또는 UE가 그렇게 할 능력을 갖는지의 여부가 결정된다. 이를 평가한 후, "디바이스 당 인증 매핑 정책들"이 요구된 보증 레벨 및 해당 사용자 장비의 능력들에 기초하여 생성될 수도 있다. 매핑 정책들은 다양한 형태들의 인증 요소들의 사용자 선호도에 기초하여 추가로 생성될 수도 있다. 예를 들어, 주어진 사용자가 챌린지-응답 기반 인증을 용인하지 않을 수도 있다. 추가 예로서, 주어진 사용자가 패스워드 기반 인증에 비하여 생체인식 인증을 선호할 수도 있다.
예를 들어, 은행업무 애플리케이션이 은행업무 애플리케이션에 의해 제공된 은행 계좌에 대한 완전한 액세스를 위한 높은 보증 레벨 및/또는 생체인식 인증을 요구할 수도 있다. 주어진 UE가 생체인식 보안 능력들을 제공하지 않는다면, IdP는 RP와 협상할 수 있다. 예를 들어, IdP는 주어진 UE의 인증 능력들 중 하나인 EAP-SIM 디바이스 인증을 제안할 수 있다. 그 제안에 응답하여, RP는 그러면 자신이 제공하는 서비스를 다운그레이드할 수 있다. 예를 들어, 은행 계좌에 완전한 액세스를 제공하는 대신, RP는 거래 값들을 제한 또는 특정한 거래 유형들을 한정할 수도 있다. 대안으로, IdP는 챌린지-응답 프로토콜을 수행하여, 사용자에게의 불편을 댓가로, 보증 레벨을 소망의 레벨로 증가시킬 수도 있다. 그것은 사용자에게 불편한데, 사용자가 추가로 검증되도록 사용자가 보안 질문들(예컨대, 귀하의 어머니의 결혼 전의 성이 무엇인가요? 귀하의 첫 애완동물의 이름이 무엇인가요? 출생지는 어디인가요? 등)에 대답해야만 할 수도 있기 때문이다.
보증 레벨 매핑이 일 예의 실시형태에 따라 시간 경과에 따라 변할 수도 있다. 예를 들어, 디바이스의 인증 능력들은 가능 또는 불가능이 되는 특징(feature)들에 기초하여, 사용자 선호도 변경에 기초하여 등으로 변할 수도 있다. 디바이스가, 아래에서 설명되는 바와 같이, 용량이 변할 때 다시 등록될 필요가 있을 수도 있다.
다중요소 인증의 끝에서, SP는 단일 요소들, 또는 보증 레벨에 따른 결합된 표명을 사용하여 성공적인 인증(들)에 대한 단일 표명을 획득할 수도 있다. 다양한 실시형태들에 따라 이러한 표명들을 구성 및 전송하는 상이한 방도들이 있다.
서명된 표명들을 생성하는 표준 방법이 OpenID 표준 규격들에 의해 특정된다. 그것은 OpenID 제공자(OP) 엔티티와 사용자의 인증을 요청하는 당사자(RP) 간에 공유된 키를 먼저 확립하는 것을 포함한다. 이 프로세스는 연관(association)이라 지칭된다. 본원의 경우, OP 엔티티는, 인증 요청이 RP로부터 수신될 때, 그리고 다중요소 인증을 실행하기 전에 상기 공유된 키를 확립하는, OP 서비스 기능(OP Service function, OPSF)이라고 또한 지칭되는, MFAS 시스템의 부분이다. 다중요소 인증 정책의 성공적인 실행 후, MFAS는 OPSF 엔티티를 수동 제어할 수도 있으며, OPSF 엔티티는 그러면 앞서 언급된 공유된 키를 사용하여 OpenID 표명에 서명한다. 표명은 표준 규격들에 따라, 예를 들어, 문자들의 스트링 또는 JSON 웹 토큰과 같은 상이한 포맷들을 가질 수도 있다. 하나의 예의 실시형태에서, 표명은, 표현할 수도 있는 정보 엘리먼트들, 예를 들어, 실행된 다중요소 인증의 특정 세부사항들, 인증 완료된 사용자 아이덴티티, 또는 다른 상황적 정보를 나타내는 다양한 데이터를 또한 포함한다. 의미있는 표명들을 구성하는 방법의 일부 예의 옵션들이 아래에서 자세히 설명된다.
PAPE가 보증 레벨 및/또는 요청된 요소들을 시그널링하는데 사용되었던 일 실시형태에서, 바로 그 정보가 OpenID 프로토콜 실행에서 자동으로 추진된다. 인증들이 수행된 후, OpenID 제공자는 표명에 서명하는데, 서명은 임의의 PAPE 파라미터들을 포함하는 OpenID 표명 요청에 포함된 파라미터들을 통해 수행된다. 다시 말하면, 서명된 OpenID 표명은 인증 요소들에 관한 정보에 대한 암시적 표명을 포함할 수도 있다. 이 경우, 보증 레벨 및 포함된 요소 인증들을 보장하는 것이 OpenID 제공자의 의무일 수도 있다.
다른 실시형태에서, 식별된 사용자에 관한 정보는 OpenID 속성 교환(AX) 메커니즘들을 사용하여 교환된다. OpenID AX는 대상(예컨대, 식별된 사용자)에 관한 정보를 저장하고 그것을 요청하는 신뢰 당사자에게 제공하기 위한 OpenID 제공자에 대한 확장가능 메커니즘이다. 예를 들면, 특정 SP가 MFAS에 의해 발행된 포괄 인증 표명의 검증을 완료하였다고 가정될 수도 있는데 이러한 완료는 다중요소 인증이 사용자 및 UE로 성공적으로 완료되었음을 의미한다. 예를 들어, OpenID 표명이 위에서 설명된 바와 같은 PAPE 필드를 포함할 수도 있다. RP/SP는 단일 요소 인증들에 관한 세부사항들에 관심이 있을 수도 있다. 예를 들어, RP/SP는 포렌식 사용을 위해 단일 요소 인증들의 각각에 대한 서명된 표명들을 원할 수도 있다. 이러한 정보를 획득하기 위해, RP는 OpenID AX 페치 요청을 OP로 전송하여, 이용가능한 정보의 리스트를 요청할 수도 있다. 요청들의 예는 다음과 같다:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.name=http://axschema.org/namePerson
openid.ax.type.mauthitem=http://multi-factor.org/schema/multi-auth-listing
openid.ax.type. auth_time=http://multi-factor.org/schema/timestamp
openid.ax.type.mauth_sig=http://multi-factor.org/schema/generic-signed
openid.ax.count.mauth=unlimited
openid.ax.required=name,mauthlist,mauth_signed
위의 요청들은 실제 인증들의 리스트에 대한 요청 및 또한 이용가능한 정보의 리스트가 아이덴티티 제공자에 의해 서명될 요청을 포함한다. 일 예로서, 사용자의 실제 이름이 또한 요청될 수도 있다. 타임스탬프를 포함하는 인증 표명의 충만도가 또한 중요할 수도 있는데, 이 충만도는 원래의 OpenID 표명이 생성되었던 시간을 담고 있는 것으로서 정의될 수도 있다. 예의 응답들은 다음을 포함한다:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_response
openid.ax.type.mauthitem=http://multi-factor.org/schema/multi-auth-listing
openid.ax.type.mauth_signed=http://multi-factor.org/schema/generic-signed
openid.ax.value.name=John Doe
openid.ax.count.mauth=3
openid.ax.value, mauth.1=eap_sim
openid.ax.value.mauth.2=password
openid.ax.value.mauth.3=biometric.fingerprint
openid.ax.value.mauth_sig=iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyb1AAAAHElEQVQI12P4==
페치 요청에 대한 위의 예의 응답은 수행된 두 개의 인증들의 리스트를 포함한다. 그 예에서, 서명 속성 란을 제외한 전체 응답이 OP에 의해 서명된다. 서명은 동일한 서명 키를 사용하여 그것을 서명함으로써 원래의 OpenID 표명에 바인딩될 수도 있다. 이는 또한 RP가 응답을 즉시 검증하게 할 수도 있다.
RP가 개개의 인증 요소들의 식별자들을 알기 때문에, RP는 개개의 요소들에 관한 더 많은 정보를 계속 요청할 수도 있는데, 이러한 정보는 예를 들어 포렌식 또는 일반적 준수 목적들을 위해 요청될 수도 있다. 예를 들면, 서비스 제공자(RP)는 EAP SIM 인증에 대한 정보, 이를테면 다음의 정보를 요청할 수도 있다:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid. ax.mode=fetch_request
openid.ax.type.mno_realm=http://multi-factor.org/schema/eap-sim/realm
openid.ax.type.sim_imsi=http://multi-factor.org/schema/eap-sim/imsi
openid.ax.type.sim_triplet=http://multi-factor.org/schema/eap-sim/triplet
openid.ax.type.eap_sim_sig=http://multi-factor.org/schema/generic-signed
openid.ax.required=realm,triplet,mauth_signed
openid.ax.if_available=imsi
OP는 SP로부터의 정보에 대한 요청에 응답할 수도 있다. 일 예의 응답이 다음을 포함할 수도 있다:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_response
openid.ax.type.mno_realm=http://multi-factor.org/schema/eap-sim/realm
openid.ax.type.sim_imsi=http://multi-factor.org/schema/eap-sim/imsi
openid.ax.type.sim_triplet=http://multi-factor.org/schema/eap-sim/triplet
openid.ax.type.eap_sim_sig=http://multi-factor.org/schema/generic-signed
openid.ax.value.realm=mno.com
openid.ax.value.triplet=64BC736EF7684de1921F9C9C0E0679E2,0B7e4e4b,D2119f41D8840400
openid.ax.value.eap_sim_sig=w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
위의 예의 응답을 참조하면, 서명은 원래의 표명과는 동일한 서명 비밀을 사용하여 획득될 수도 있다. 이 응답에서, OP는 예를 들면 사용자 프라이버시를 보호하기 위해 오퍼레이터 정책에 따라 IMSI를 생략할 수도 있다. 비록 수신된 SIM 트리플릿(triplet)이 인증에 대해 또는 인증을 포렌식으로(forensically) 재추적하는데 쓸모 없을 수도 있지만, EAP SIM 인증을 수행했던 오퍼레이터는 그 응답에 포함된 영역에 오퍼레이터 상의 정보에 의해 나중에 도달될 수 있다. 예를 들어, 오퍼레이터는 트리플릿을 IMSI에 연관시키고 그것의 정확함을 검증할 수도 있다.
다양한 예의 실시형태들에서, 다른 속성 교환들이 다른 인증 요소들을 위해 사용된다. 지문이 인증을 위해 사용되는 예로서, 속성 교환은 다음을 포함할 수도 있다:
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.type.fp_authority=http://multi-factor.org/schema/generic-auth-authority
openid.ax.type.fp_transaction_id=http://multi-factor.org/schema/generic-auth-transaction-id
openid.ax.type.fp_request_protoocl=http://multi-factor.org/schema/generic-auth-protocol-id
openid.ax.type.fp_sig=http://multi-factor.org/schema/generic-signed
openid.ax.required=fp_authority,fp_transaction_id,fp_sig
openid.ax.if_available=fp_request_protocol
위의 지문 예에서 도시된 바와 같이, '기관'이라고 지칭되는 제 3 당사자가, 지문을 사용하여 인증을 제공한다. 예를 들어 제 3 당사자는 생체인식 입력을 프로세싱하고 그것을 템플릿 데이터베이스에 일치시켜 생체인식 인증을 수행할 수도 있다. 이러한 경우에, OP는 일 예의 실시형태에 따라 인증에 관한 데이터를 산출하지 못할 것이다. 대신, OP는 RP에게 인증 데이터를 제공할 수 있는 기관을 알려줄 수도 있다. 그러므로, 이러한 속성 요청들에 대한 유형들은 포괄적이고 실제 종류의 인증 요소에 의존하지 않을 수도 있는 반면, 대응 속성들의 이름들은, 위에서 보인 바와 같이, 지문 인증 요소에 특유하다. 따라서, 위의 예를 참조하면, fp_authority는, SP가 식별자 'transaction_id'를 사용하여 나중의 임의의 시간에 인증에 관한 상세한 정보를 요청할 수 있게 하는 잘 형성된 URL일 수도 있다. 게다가, SP는 'fp_request_protocol'과 같은 프로토콜을 요청할 수 있다. 그 응답은 예의 요청에 따라 구축될 수도 있다. 위의 예가 일 예의 지문 인증을 예시하지만, 예를 들어 패스워드 인증과 같이, 다른 인증 요소들이 원하는 대로 구현될 수 있다는 것이 이해될 것이다. 지문들 또는 패스워드들이 인증되는 일부 경우들에서, 실제 크리덴셜(credential) 데이터라고 지칭딜 수도 있는 지문 템플릿 데이터 또는 패스워드들은, OP 또는 요소 인증 기관과의 속성 교환에서 포함되지 않는다. 예를 들어, 실제 크리덴셜 데이터를 포함하는 것이 인증의 보안을 완화시킬 수도 있다.
이제 도 4를 참조하면, 일 예의 인증 시스템(400)은 하나 이상의 인증 엔드포인트들(406), 예를 들면 제 1 인증 엔드포인트(406a), 제 2 인증 엔드포인트(406b), 및 제 3 인증 엔드포인트(406c)를 포함한다. 시스템(400)은 클라이언트(402)라고도 또한 지칭될 수도 있는 RP(402)와, OpenID 서버 기능부(OPSF)(404)를 더 포함한다. OPSF(404), RP(402), 및 인증 엔드포인트들(406)은 네트워크를 통해 서로 통신할 수도 있다.
몇몇 경우들에서, OpenID 표명들은 OPSF(404)에 의한 성공적인 인증 후에 생성되고, 사용자를 통해 적절한 신뢰 당사자들에게 이동된다. 그 표명들은 인증 유형, 인증 강도 등에 관한 정보를 신뢰 당사자(402)에게 제공할 수도 있다. OpenID 2.0은 많은 세부사항들이 추가될 때 긴 서명된 표명을 사용한다. Open ID Connect는 이 프로세스를 토큰들을 사용하는 그것의 동작에 의하여 상당한 정도로 단순화시킨다.
다중요소 인증에서, 수반된 인증들의 각각의 성질에 관한 더 많은 정보를 이해할 필요가 있을 수도 있다. Open ID Connect는, 지정된 엔드포인트들로부터 필요한 정보를 페치하기 위해, 토큰들을 통해 사용될 수 있다. 예를 들어, 포렌식에서, 각각의 인증 요소에 대한 개개의 표명들에 대한 정보를 획득하는 것이 유익할 수도 있다. 따라서, 엔드포인트들(406)의 각각은 각각의 인증 요소에 대응할 수도 있다. 따라서, 엔드포인트들(406)의 각각은 인증 프로세스에서의 당해 요소에 대해 생성된 표명에 대한 세부사항들을 제공할 수도 있다. 예를 들어, 예시된 실시형태에 따라, 402에서, OPSF(404)는 인증 표명들을 검색하기 위해 하나 이상의 액세스 토큰들을 준비한다. 410에서, RP(402)는 하나 이상의 토큰들 중 제 1 액세스 토큰을 제 1 인증 엔드포인트(406a)에게 제공한다. 응답하여, 412에서, RP(402)는 제 1 인증 요소에 관련된 표명 및 다른 정보를 수신한다. 414에서, RP(402)는 하나 이상의 토큰들 중 제 2 액세스 토큰을 제 2 인증 엔드포인트(406b)에게 제공한다. 응답하여, 416에서, RP(402)는 제 2 인증 요소에 관련된 표명 및 다른 정보를 수신한다. 418에서, RP(402)는 하나 이상의 토큰들 중 제 3 액세스 토큰을 제 3 인증 엔드포인트(406c)에게 제공한다. 응답하여, 420에서, RP(402)는 제 3 인증 요소에 관련된 표명 및 다른 정보를 수신한다.
도 1을 대체로 참조하면, 인증들은, 싱글 사인 온(single sign-on, SSO) 서브시스템 또는 로컬 OpenID 아이덴티티 제공자(OP)라고도 또한 지칭될 수도 있는 MFAP(110)를 통해 UE(102) 상에서 국소적으로 수행될 수도 있다. 인증이 국소적으로 수행될 수도 있는 일부 경우들에서, UE(102)의 인증 능력들은 식별자들에 매핑되고, 그 매핑은 UE상에, 예를 들어 보안 환경에서 국소적으로 저장된다. 발견 또는 등록 프로세스 동안 네트워크에서 수집되고 유지되는 정책 정보는 UE(102), 특히 MFAP(110) 상에서 또한 이용가능할 수도 있다. 예를 들어, 네트워크 MFAS(106)는 MFAP(110)에서 매핑 정보를 구성할 수도 있다. 의무들의 확실한 분리를 유지하기 위하여, 예를 들어, MFAP(110)는 이용가능한 인증 요소들을 사용하여 네트워크 측 MFAS(106) 정책 매핑 기능을 흉내낼 수도 있다. MFAP(110)는 그 다음에 지정 사용자, 이를테면 사용자(107), 및 연관된 사용자 식별자를 소망의 정책과, 따라서 인증 요소들과 매핑할 수도 있다. 따라서, 디바이스 및 사용자 인증 능력들이 제 3 당사자에 노출될 필요가 없을 때 사용자의 프라이버시가 보호될 수도 있다.
도 5를 또한 참조하면, MFAS(106) 및 MFAP(110)는 네트워크 및 디바이스 측 상의 상이한 인증 방법들이 실행될 수 있도록 다양한 정책들에 따라 상이한 방도들로 기능을 할 수 있다. MFAS(106)에서, 고도로 특징-풍부한(feature-rich) 정책 엔진, 이를테면 정책 엔진(503)이, 상이한 보안 요건들, 사용자 요건들, 및 서비스-제공자 요건들에 맞출 수도 있다. 예를 들어, 모든 사용자 및 그 사용자가 사용하는 디바이스(들)에 대한 가능한 인증 능력들의 리스트가 있을 수도 있고, 정책 엔진(503)은 사용자가 RP(104)로부터의 보증 레벨 요건들을 충족시키기 위해 수행할 수 있는 네트워크 및 로컬 인증 요소들의 조합으로부터 동적으로 선택할 수도 있다. 단순화된 예의 시나리오에서는, MFAS(106)에 등록되는 사용자의 상이한 디바이스들로부터 사용자가 수행할 수 있는 네트워크 및 로컬 인증 요소들의 정적 리스트가 있을 수도 있고, 정책 엔진(503)은 네트워크 및 로컬 인증 요소 조합들의 이 정적 리스트로부터 선택할 수도 있다.
MFAS(106) 및 MFAP(110)의 임무들은 다양한 실시형태들에 따라 가변한다. 하나의 실시형태에서, 마스터-슬레이브 관계가 MFAS(106) 및 MFAP(110) 간에 존재한다. 예를 들어, 사용자(107) 및 서비스 제공자들에 관계된 정책들은 MFAS(106)에서 이용가능하고, MFAS(106)는 네트워크 측 및 디바이스 측 양쪽 모두에서 관련 정책들의 실행을 개시한다. 예의 실시형태에 따라, MFAP(110)는 로컬 인증 요소들을 주어진 시퀀스로 실행함으로써 MFAS(106)로부터 수신한 명령들을 따른다. 따라서, 하나의 실시형태에서, MFAP(110)에는 정책 엔진이 없다.
다른 실시형태에서, 일단 사용자(107)가 RP(104)로부터 MFAS(106)와 통신하면, MFAS(106)에서의 정책 엔진(503)은, MFAS(106)에 의해 핸들링될 네트워크 측 정책들 및 프록시 정책 엔진을 사용하여 핸들링할 수 있는 디바이스(102) 상의 MFAP(110)에서 핸들링되는 로컬 정책들의 명확한 분리를 동적으로 반환한다. 이 실시형태에서, MFAP(110)는, 정책 푸시 동안을 제외하면, MFAS(106)에 의해 직접 제어되지 않을 수도 있다. 정책 푸시는 정책들에 대한 업데이트들이 있다면 후속 푸시들을 포함하는 것을 초기 정책 푸시로서 발생할 수도 있거나 또는 인증마다 기반으로 발생할 수도 있다.
위에서 설명된 예의 실시형태들에서, MFAS(106)는 UE(102)의 구체적인 로컬 인증 능력들 및 구성된 정책 및 매핑 정보를 포함하는 정보를 유지할 수도 있다. 덧붙여서, 정책은 소망의 인증 보증을 달성하기 위해 사용될 인증 요소들 또는 인증 요소들에 대한 보증 레벨 매핑에 기초할 수도 있다.
도 5를 참조하면, 또 다른 예의 실시형태에 따라, 인증 정책으로의 보증 레벨의 매핑은 MFAS(106) 및 MFAP(110) 간에 분리될 수 있다. 다시 말하면, 요청된(RP(103)에 의함) 보증 레벨(AL)은 로컬 보증 레벨(AL_loc)과, 정책들, 미리 정의된 규칙들, 및 매핑 테이블들에 따른 다양한 엔티티들에 의해 충족되는 네트워크 보증 레벨(AL_net)로 분리될 수도 있다. 예를 들어, MFAS(106)는 그 분리를 실행하고 인증 요청 시에 AL_loc를 MFAP(110)로 전송할 수 있다. 다른 예에서, MFAP(110)는 MFAS(106)와 요건을 협상할 수도 있다. MFAP(110)는 더 낮은 AL_loc 능력을 나타내는 메시지로 협상에 응답할 수 있으며, 그 응답에 기초하여 MFAS는 AL_net을 그에 따라 적응(예컨대, 그것을 상승)시켜 여전히 전체 AL을 달성할 또는 요건을 충족하도록 MFAP 정책을 적응시킬 수도 있다. MFAP(110)의 응답은 로컬 조건들 및/또는 국소적으로 유지되는 디바이스 능력 정보(예컨대, 조명 조건들이 얼굴 인식 생체측정을 위해 현재 불충분함)에 기초할 수도 있다.
여전히 도 5를 참조하면, 예시된 실시형태에 따라, 504에서, 전체 AL은 MFAS(106)에 전달된다. AL 매핑 엔진이, 예를 들어, AL 매핑 엔진 및 룩업 테이블(502)이라고 지칭될 수도 있는, 컴퓨테이션 엔진, 데이터베이스, 또는 룩업 테이블을 사용하여, AL_loc 및 AL_net의 잠정적 값들을 도출할 수도 있다. 506에서, AL_loc는 UE(102) 및 MFAP(110)에게 전달된다. 508에서, MFAP(110)는 UE(102) 상의 로컬 조건들을 평가하고 그것의 현재 능력들을 나타내는 AL_loc*로 MFAS(106)에게 응답할 수도 있다. 로컬 보증 레벨은 UE(102)의 현재의 조건들에 기초하고, 따라서 동일한 것을 표시하기 위해 도 5에서 별표로 참조된다. 로컬 인증은 이미 수행되었을 수도 있고 AL_loc*는 따라서 국소적으로 달성된 보증 레벨을 알리는 서명된 표명 메시지의 부분일 수도 있다. 이 경우, 506에서의 메시지는, 훨씬 더 낮은 문턱값이 이용가능하지 않은 경우에 동작을 중단시킬지 또는 로컬 인증들을 수행할지를 MFAP(110)가 결정하게 하기 위해서, 최소 요청된 로컬 보증 레벨(AL_loc_min)을 나타내는 더 낮은 임계 값 보증 레벨을 또한 포함할 수도 있다. 508에서 전송되는 보증 레벨에 기초하여, MFAS(106)는, 510에서, AL_net를 정책 실행 엔진(503)으로 제출함으로써 네트워크 기반 인증들을 시작할 수도 있다.
로컬 MFAP 준비된 정책은, 예를 들어, 디바이스(102)가 MFAS(106)에 접속되지 않을 때에도, 인증을 실행할 수도 있다는 것이 MFAP(110)를 사용하는 것에서 도출되는 일 예의 이점이다. 예를 들어, 몇몇 경우들에서, 디바이스(102)가 네트워크에 접속되지 않기 때문에 MFAS(106)와 통신하는 것은 가능하지 않다. 다른 경우들에서, MFAS(106)에의 통신들은, 예를 들어, 네트워크 트래픽을 감소시키기 또는 MFAS(106) 상의 프로세싱 부담을 감소시키기 위하여 제한된다. 국소적으로 시행된 인증 정책은 네트워크 정책 기능과 동기화될 그리고 시간 경과에 따라 업데이트 또는 재동기화될 수도 있는데, 예를 들어, 그 능력들이 변할 수도 있거나 또는 인증 매핑의 요소들에 대한 보증 레벨이 변할 수도 있기 때문이다.
일 예의 실시형태에 따라, OP 서버는 본원에서 설명되는 다중요소 인증 실시형태들을 구현하도록 확장될 수 있다. 예를 들어, 도 6에 묘사된 예의 시스템(600)을 참조하면, OP 서버(602)는 OpenID 규격들과 충돌하는 일 없이 부가적인 인터페이스들을 포함하도록 확장될 수 있다. OP 서버(602)는 일 예의 실시형태에 따라 표명에 서명할지의 여부에 대한 최종 결정을 할 수도 있다. 예를 들어, 표명이 사용자/UE(606)에게 전송된 후, RP(604)가 표명을 그것이 유효하다면 수락할 수도 있다. OP 서버(602)는 RP(604) 및 사용자(606)에 대한 HTTPS 기반 엔드포인트들을 구현할 수도 있다. 사용자 에이전트(606)가 사유 프로토콜들을 실행할 수도 있는 한 그 사유 프로토콜들을 통해 생체인식 인증들이 될 수도 있다는 것이 이해될 것이다. OP(602)가 실제 인증을 수행하는 것이 요구되지 않는다는 것이 추가로 이해될 것이다. 따라서, 인증들은 다른 인증 서비스들에 의해 수행될 수도 있다. 다른 인증 서비스들은 인증의 결과들을 보안성있게 OP(602)에게 반환할 수도 있다. OP(602) 및/또는 다른 인증 서비스들은 인증 프로세스에 포함시킬, 예를 들어, 다양한 인증들을 함께 바인딩할 랜덤 논스(nonce)를 생성할 수도 있다. 게다가, 결과들을 포함하는 메시지는, OP(602)가 성공/실패 메시지를 진행중인 사용자 로그인 세션에 매핑할 수 있도록 인증의 신선도의 표시, 및 세션 식별자를 포함할 수도 있다.
도 6을 참조하면, 예시된 실시형태에 따라, OP(602)는 예를 들어 OpenID 2.0 엔티티와 같은 임의의 OpenID 아이덴티티 제공자를 지칭한다. RP(604)는 예를 들어 Open ID 2.0 RP와 같은 OpenID 신뢰 당사자를 지칭한다. UE(606)는 임의의 사용자 에이전트, 이를테면 사용자를 갖는 모바일 디바이스를 나타낼 수도 있다. OP(602)에서의 인증 확장 인터페이스들(AuthXIF)(608)이, OP(602)를 인증 서버들(610)에 접속시킨다. 인증 서버들(610)의 각각은 실제 사용자/UE 인증 방법을 실행할 수도 있다. 예를 들어, 인증 서버들(610)은 사용자 인증을 수행하는데 필요한 정보(예컨대, GBA의 경우의 SLF)인 인증 데이터를 저장할 수도 있다. 다중요소 인증 계층(611)이 OP(602)에 통합되는 컴포넌트일 수도 있는데, 이 컴포넌트는 다중요소 인증이 발생하는 것을 가능하게 한다. 다중요소 인증 계층(611)은 다수의 인증 요소들을 트리거하고 상이한 인증들로부터 결과들을 수집/바인딩하기 위한 OP(602) 및 정책 계층(612)에 대한 인터페이스를 추가로 제공할 수도 있다. IdP 정책 계층(612)은 요청된 정책들에 기초하여 어떤 인증 방법들을 트리거할지를 결정하는 크로스 계층 기능으로서 역할을 할 수도 있다. 정책 계층(612)은 또한, 다수의 인증들의 결과를 평가하고, 결합된 인증의 결과를 (예컨대, 요청된 정책에 대한 매칭에 기초하여) 다시 OP(602)로 전달할 수도 있고, 그 OP는 그러면 (결합된) 표명을 생성할 수도 있다.
여전히 도 6을 참조하면, 사용자 인증 확장 인터페이스(614)가 사용자/UE(606)에 대한 인증 프로세스를 개시할 것이 OP(602)에 의해 요청될 수도 있다. 그 인터페이스는 HTTP(S) 기반일 수도 있지만, 그 인터페이스는, 예를 들어 사유 프로토콜에 기초하는 것과 같이 번갈아 기초할 수 있다는 것이 이해될 것이다. 사용자 인증 인터페이스(616)가, 예시된 실시형태에 따라, 사용자 인증 메커니즘을 실행하기 위해 인증 서버들(610)에 의해 사용된다. 예를 들어, 인터페이스(616)는 GBA 키들을 요청하기 위해, 지문들을 요청하기 위해, EAP-SIM을 요청하기 위해 등을 위해 사용될 수 있다. 인터페이스(616)가 HTTP(S) 기반인 것으로 묘사되지만, 임의의 적절한 전송 프로토콜이 UE(606) 및 인증 서버들(610) 간에 데이터를 전하는데 사용될 수도 있다는 것이 이해될 것이다. 인터페이스(618)가 각각의 크리덴셜 데이터베이스들(620)을 연결시키는 인증 서버들(6120)을 위한 내부 인터페이스를 나타낼 수도 있다. 인터페이스(618)는 OP(602), RP(604), 및 UE(606)의 관점에서 보이지 않을 수도 있다.
다수의 인증 요소들이 사용될 것이면, 부가적인 인터페이스들(608)이 OP(602)에 추가될 수도 있다. 예를 들어, 예시된 시스템(600)은 OP(602)를 제 1 인증 서버(610a)에 커플링하는 제 1 인터페이스(608a)를 보여준다. 시스템은 OP(602)를 제 2 인증 서버(610b)에 커플링시키는 제 2 인터페이스(608b)를 더 포함한다. 인증 확장 인터페이스들(608)은 각각의 인증 서버(610)에 의해 제공되는 라이브러리/모듈일 수도 있다. 예를 들어 인터페이스들(608)은 웹 키에 대한 웹 키 애플리케이션 코드, GBA에 대한 NAF 라이브러리 등일 수도 있다. 예의 시스템(600)은 상이한 인증 방법들을 포함하는 통합 인터페이스를 OP(602)에게 제공한다. OP(602)는 상이한 인증들을 트리거하여 그것들의 결과들을 얻으며, 적절한 표명 메시지를 구축하고, 인증 방법들에 관한 다양한 정보를 포함할 수도 있는 서명된 표명을 (예컨대, PAPE를 사용하여) RP(604)에게 전송할 수 있다. RP(640)는 그 다음에 인증 방법들이 적어도 인증 강도의 요청된 및 요구된 레벨들을 충족시키는데 충분한지를 체크할 수 있다. 다양한 라이브러리들이 OP(602)와 통합될 수도 있다는 것이 이해될 것이다. 게다가, 인증 요소들은 슨차적으로 또는 서로 병렬로 트리거될 수도 있다. AuthXIF 컴포넌트들은 내부 인터페이스들을 통해, 예를 들어 서버 구현예/코드에 대한 라이브러리들 또는 모듈들로서 OP(602)에 통합될 수도 있다.
위에서 설명된 바와 같이, 인증들 및 표명들은 다양한 실시형태들에 따라 다양한 방도들로 실행될 수도 있다. 예를 들어, 인증은 서버(네트워크) 상에서 수행되고 네트워크 생성된 표명과 결합할 수도 있다. 인증은 UE(온-디바이스 또는 로컬) 상에서 수행되고 온-디바이스(로컬) 생성된 표명과 결합될 수도 있다. 인증이 온-디바이스(로컬)이고 네트워크 생성된 표명과 결합될 수도 있다. 인증이 온-디바이스(로컬)이고 온-서버(네트워크) 인증과 결합될 수도 있다.
이제 도 7a 내지 도 7c를 참조하면, 일 예의 인증 시스템(700)이 하나 이상의 인증 에이전트(authentication agent, AA)들(710), 예를 들면 제 1 인증 에이전트(AA)(710a), 제 2 AA(710b), 및 제 3 AA(710c)를 포함한다. 도 7a 내지 도 7c는 네트워크 기반 다중요소 인증의 일 예를 도시한다. 인증 에이전트들은 UE(102)의 부분일 수도 있고, UE(102)는 사용자(107)에 의해 동작될 수도 있다. UE(102)와, 따라서 시스템(700)은, 브라우저(704)라고도 또한 지칭될 수도 있는 클라이언트 애플리케이션(704)을 제한 없이 포함한다. 클라이언트 애플리케이션(704)은 또한, 예를 들어, 안드로이드 또는 iOS 애플리케이션과 같은 모바일 애플리케이션일 수도 있고 그것이라고 또한 지칭될 수도 있다. 시스템(700)은 마스터 IdP/MFAS(106), RP/SP(104), 및 하나 이상의 인증 서버들(706)을 더 포함한다. 참조 번호들이 편이를 위해 도면들 전체에 걸쳐 반복되고, 하나를 초과하는 도면에서 보이는 참조 번호들은 그것들이 보이는 각각의 도면에서 동일하거나 또는 유사한 특징들을 언급한다는 것이 이해될 것이다. 세 개의 인증 에이전트들이 인증 시스템(700)에서 예시되지만, 인증 시스템(700)에서의 인증 에이전트들의 수는 원하는 대로 가변할 수도 있다는 것이 이해될 것이다. 예시된 실시형태에 따라, 제 1 인증 에이전트(710a)는 제 1 인증 서버(706a)와 연관되며, 제 2 인증 에이전트(710b)는 제 2 인증 서버(706b)와 연관되고, 제 3 인증 에이전트(710c)는 제 3 인증 에이전트(706c)와 연관된다. 게다가, 인증 에이전트들(710) 및 인증 서버들은 브라우저(704)에는 SP(104)에 의해 제공된 서비스들에 대한 액세스가 제공될 수 있도록 3-요소 인증을 가능하게 한다. 마스터 IdP(106)와, 인증 서버들(706)은 인증 시스템(700)의 네트워크 측이라고 총칭하여 지칭될 수도 있다. 일 예의 3-요소 인증이 도 7a 내지 도 7c에서 예시되지만, 도 7a 내지 도 7c에 도시된 호출 흐름은 3 개를 초과하는 또는 그 미만의 요소들을 사용하는 인증을 위해 확장될 수도 있다는 것이 이해될 것이다. 예시된 실시형태에 따라, MFAP(110)는 SP(104)의 정책 요건들을 평가하고 마스터 IdP(106)는 정책들을 해석하여 정책 요건들을 충족시킬 인증 프로토콜들의 파라미터들을 결정한다.
여전히 도 7a 내지 도 7c를 참조하면, 예시된 실시형태에 따라, 712에서, 사용자(107)는 브라우저(704)를 통해 서비스(SP(104)에 의해 제공됨)에 대한 액세스를 요청한다. 브라우저는 SP(104)와 통신하고 있을 수도 있고, 그 통신은 사용자(107)에 연관되는 사용자 ID를 포함할 수도 있다. 사용자 ID에 기초하여, 716에서, SP(104)는 발견을 수행하고 사용자 ID에 연관되는 마스터 IdP(106)와 연관한다. 마스터 IdP(106)는 OpenID 아이덴티티 제공자(OP) 또는 네트워크 액세스 기능부(network access function, NAF)와 연관되는 기능을 수행할 수도 있고, 따라서 마스터 IdP(106)는 OP(106) 또는 NAF(106)라고 또한 지칭될 수도 있다. 714에서, 예시된 실시형태에 따라, SP(104)는, 예를 들어, SP(104)의 정책에 기초하여, 사용자(107)가 SP(104)에 의해 제공되는 요청된 서비스에 액세스하기 위하여 다중요소 인증이 요청된다고 결정한다. 예시된 실시형태에 따라, SP(104)는 패스워드 인증 및 생체인식 인증이 서비스에 액세스하기 위해 요구된다고 결정한다. SP(104)는 사용자가 SP(104)에 의해 제공되는 요청된 서비스에 액세스하기 위해 요구되는 인증의 보증 레벨을 또한 결정할 수도 있다. 718 및 720에서, 예시된 실시형태에 따라, SP(104)는 720에서 HTTP 재지향 메커니즘을 사용하여, 자신의 보증 레벨 요건을 브라우저(704)를 통해 MFAS/마스터 IdP(106)에게 전달한다.
예시된 실시형태에 따라, 브라우저(704)는 SP(104)에 의해 요구되는 보증 정보를 또한 전송한다. 722에서, 서비스에 액세스하기 위해 요구되는 보증 레벨에 기초하여, 예를 들어, MFAS(106)는 요구된 보증 레벨을 달성하기 위해 수행될 수 있는 인증 요소들의 유형들 및 강도들을 결정한다. MFAS(106)는 요청된 인증들을 수행할 수 있는 인증 에이전트들을 추가로 식별할 수도 있다. 예를 들어, 예시된 실시형태에서, MFAS(106)는 제 1 AA(710a), 제 2 AA(710b), 및 제 3 AA(710c)가 인증 요소들의 결정된 유형들 및 강도들에 연관된다고 결정한다. 제 1 인증 에이전트(710a)가 식별된 후, 725에서, MFAS(106)는 제 1 인증 요소의 인증을 수행하기 위해 제 1 AA 인증 에이전트(710)를 트리거할 수도 있다. 726에서, MFAS(106)는 제 1 인증 요소의 인증을 수행하기 위해 제 1 인증 서버(706a)를 또한 트리거할 수도 있다. 예를 들어, MFAS(106)는 제 1 인증 서버(706a)가 제 1 AA 개시 인증을 위한 콘텍스트를 생성할 것을 요청하기 위해 제 1 AA(710a)에 연관되는 제 1 인증 서버(706a)와 통신할 수도 있다. 724에서, MFAS(106)는 제 1 인증 요소 또는 적어도 제 1 인증 요소를 준비하는 메커니즘을 포함하는 메시지를 MFAP(110)로 전송함으로써 제 1 인증 요소를 옵션으로 개시할 수도 있다. 725 및 726에서 수행되는 단계들은 서로 병렬로 수행될 수도 있다. 대체 실시형태에서, 725 및 726을 서로 병렬로 수행하는 대신, 726에서의 메시지만이 전송되고, 725에서의 인증을 수행하기 위한 트리거는 아래에서 설명되는 728에서 수행된다.
도 7b를 계속 참조하여, 예시된 실시형태에 따라, 728에서, 제 1 AA(710a) 및 제 1 인증 서버(706a)는 인증을 수행할 수도 있다. 그 인증은 사용자(107)로부터의 입력을 또한 요구할 수도 있다. 예를 들어, 그 인증은 브라우저(704)의 사용자의 인증(예컨대, 사용자의 생체인식), 브라우저(704)의, UE(102)의 등의 인증을 포함할 수도 있다. 728에서 수행되는 인증의 성공 또는 실패는, 728에서 인증 서버(706a)에 의해 AA(710a)로 전달될 수도 있다. 728에서 수행되는 인증은 예를 들어 챌린지-응답 메시지들을 또한 포함할 수도 있는 왕복 메시징의 수를 수반할 수도 있다. 예를 들어 제 1 표명과 같은 표명이, 성공적인 인증 시 제 1 인증 서버(706a)에 의해 생성될 수도 있다. 제 1 표명은, 732에서, 제 1 인증 서버(706a)에 의해 MFAS(106)로 전송될 수도 있다. 제 1 표명은 인증 결과의 신선도를 포함하는 인증 결과를 나타낼 수도 있다. 대안으로, 예시된 실시형태에 따라, 제 1 표명은 730에서, 제 1 AA(710a)에 의해 생성되고 MFAP(110)로 전송될 수도 있다. 그렇더라도, 인증의 종료 시, 제 1 AA(710a) 및 제 1 인증 서버(706a) 양쪽 모두는 인증의 증거를 가질 수도 있고, 그 증거는 도 7에 따라 제 1 표명이라고 지칭된다. 덧붙여서, MFAS(106) 및 MFAP(110)는 728에서 수행되었던 제 1 인증들의 지식 및 증거를 가질 수도 있다.
730에서, 725에서 수신되었던 트리거에 응답하여, 제 1 AA(710a)는 제 1 표명을 포함하는 트리거 응답을 전송할 수도 있다. 그 트리거 응답은 MFAP(110)에게 전송될 수도 있고, 그 트리거 응답은 성공적인 인증이 수행되었음을 입증할 수도 있다. 732에서, 네트워크 측에서, 제 1 인증 서버(706a)는 제 1 표명 및 그것의 연관된 신선도(예컨대, 인증이 수행되었던 때의 날짜/시간)를 MFAS(106)로 전송할 수도 있다.
736에서, 예시된 실시형태에 따라, MFAS(106)는 제 2 인증 콘테스트를 생성하기 위한 트리거를 제 2 인증 서버(706b)로 전송한다. 트리거되는 제 2 인증 콘텍스트는 제 2 인증 요소를 사용하여, 제 2 인증 서버(706b) 및 제 2 AA(710b)에 의해 수행되는 제 2 인증과 연관된다. 734에서, 예를 들어 정책들에 기초하여, MFAS(106)는 트리거를 MFAP(110)를 통해 제 2 AA(710b)로 전송함으로써, 또는 대안으로는 MFAP(110)에 의해 트리거되는, 제 2 인증 요소를 사용하여 제 2 인증의 시작을 개시할 수도 있다. 734 및 736에서의 단계들은 서로 병렬로 수행될 수도 있거나, 또는, 대체 실시형태에서, MFAS(106)로부터 제 2 인증 서버(706)로의 트리거만이 736에서 수행된다. 738에서, 예시된 실시형태에 따라, 제 2 요소 인증이 제 2 AA(710b) 및 제 2 인증 서버(706b) 간에 수행된다. 제 2 요소 인증을 수행하는데 사용되는 제 2 요소는, 사용자의 생체인식, 사용자(107)에 연관된 다른 요소, 디바이스(102)에 연관된 요소, 사용자(107)의 행동 분석에 연관된 요소 등일 수도 있다. 대안으로, 예를 들어, 제 2 요소 인증은 제 2 AA(710b) 및 사용자(107) 간에 수행될 수도 있다. 이러한 인증은, 예를 들어, 생체인식 인증, 사용자 디바이스에 연관된 요소의 인증, 또는 사용자의 행동분석에 연관된 요소를 포함할 수도 있다. 제 2 요소 인증의 종료 시, 제 2 인증 서버(706b)는 예를 들어 제 2 표명과 같은 표명을 생성할 수도 있다. 제 2 표명은 랜덤 논스를 포함할 수도 있고 그리고/또는 티켓은 암호로 생성될 수도 있다. 제 2 표명은 제 2 AA(710b)로 전송될 수도 있다. 대안으로, 일 예의 실시형태에서, 제 2 AA(710b)는 제 2 티켓을 생성하기 위해 제 2 인증 서버(706b)에 의해 사용된 것과 유사한 메커니즘들을 사용하여 제 2 티켓을 생성하고 따라서 제 2 티켓은 제 2 인증 서버(706b)로부터 제 2 AA(710b)로 전송되지 않는다. 740에서, 734에서 전송되었던 트리거에 응답하여, 제 2 AA(710b)는 제 2 표명 및 그것의 연관된 신선도를 MFAP(110)로 전송한다. 마찬가지로, 742에서, 제 2 인증 서버(706b)는 제 2 표명 및 그 표명에 연관된 인증의 신선도를 MFAS(106)로 전송할 수도 있다. 대안으로, 예를 들어 로컬 인증이 제 2 AA(710b)에 의해 수행된다면, 제 2 AA(710b)는 제 2 표명을 생성하고 제 2 표명을 MFAP(110)로 포워딩할 수도 있다. 임의의 수의 인증 요소들이 바람직하다는 것이 이해될 것이다. 따라서, 단계들(743 및 745)은, 제 3 AA(710c) 및 제 3 인증 서버(706c)가 각각 제 2 AA(710b) 및 제 2 인증 서버(706b) 대신 사용된다는 것을 제외하면, 각각 단계들(734 및 736)처럼 수행될 수도 있다. 게다가, 단계들(747, 749, 및 751)은 각각 단계들(738, 740, 및 742)을 참조하여 위에서 설명된 바와 같이 수행될 수도 있다.
도 7a 내지 도 7c를 계속 참조하여, 예시된 실시형태에 따라, 744에서, MFAS(106)는 제 1, 제 2, 및 제 3 표명들을 통합하여 다수의 인증 요소들에 대한 통합된 표명을 생성한다. 하나의 예에서, 결집 보증 레벨이 각각의 인증 요소에 연관된 보증 레벨을 함께 합산함으로써 컴퓨팅된다. 다른 예로서, 보증 레벨들은, 하나의 인증 요소가 인증 요소들 양쪽 모두에 대응하는 결집 보증 레벨에서의 다른 인증 요소에 비하여 더욱 무겁게 가중되도록 가중될 수도 있다. 각각의 인증 요소의 수명을 고려하는 신선도 쇠퇴(decay) 함수와 같은 부가적인 파라미터들이, 결집 보증 레벨을 컴퓨팅함에 있어서 고려될 수도 있다. 다른 실시형태에서, MFAS(106)는 컴퓨팅된 결집 보증 레벨을 전송하지 않는다. 예를 들어, MFAS(106)는 각각의 인증의 결과를 전송할 수도 있다. 746에서, 브라우저(704)는 MFAS(106)로부터 통합된 표명을 수신한다. 748에서, 브라우저(704)는 표명을 SP(104)로 재지향하여 전송한다. 결집 보증 레벨을 포함할 수도 있는 서명된 표명은, 746에서, 예를 들어 HTTP 재지향 메시지를 사용함으로써, MFAS(106)에 의해 SP(104)에게 UE 브라우저를 통해 전달된다. 대안으로, 결집 보증 레벨을 포함하는 서명된 표명은 다른 채널들을 사용하여 MFAS(106)에 의해 SP(104)에게 직접 전달될 수도 있다. 전송되는 서명된 표명은 수행되었던 다중요소 인증에 의해 달성되었던 보증 레벨 및 각각의 인증 요소에 대한 신선도 레벨을 포함할 수도 있다. 750에서, 예시된 실시형태에 따라, SP(104)는 표명, 특히 표명 서명을 검증하고, 752에서, SP(104)에 의해 제공된 요청된 서비스에 대한 액세스를 브라우저(704)의 사용자(107)에게 제공한다.
도 8a 내지 도 8c는 인증이 UE(102) 상에서 수행되는 도 7a 내지 도 7c의 변형예를 도시한다. 도 8a 내지 도 8c에 예시되어 있는 대부분의 단계들은 도 7a 내지 도 7c에 관해 설명되어 있다. 특히 도 8a를 참조하면, 718a에서, 예시된 실시형태에 따라, SP(104)는 자신의 보증 레벨 요건을 브라우저(704)를 통해 MFAS(106)에게 전송한다. 대안으로, SP(104)는 자신의 보증 레벨 요건을 SP(104) 및 MFAS(106) 간에 직접적으로 확립된 채널을 통해 전달할 수도 있다. 이러한 채널은 716에서 발생하는 발견 및 연관의 부분으로서 확립될 수도 있다. 720a에서, 브라우저(704)는 SP(104)가 브라우저(704)를 통해 MFAS(106)의 서비스들을 호출하도록 MFAS(106)로 재지향된다. 722에서, MFAS(106)는 SP(104)에 의해 요구된 보증 레벨을 달성하기 위하여 호출될 수도 있는 인증 요소들의 유형 및 수를 결정한다. 724a에서, MFAS(106)는 메시지 또는 트리거를 브라우저(704)를 통해 MFAP(110)로 전송함으로써 다중요소 인증 요소를 개시한다. 메시지 또는 트리거는 인증 요소들을 포함할 수도 있다. 메시지 또는 트리거는 인증 요소들 대신, 또는 그것들에 부가하여 전송되는 요구된 보증 레벨을 또한 포함할 수도 있다. MFAP(110)는 그 보증 레벨을 사용하여 인증 요소들을 결정할 수도 있다. 802에서, 브라우저(704)는 MFAP(110)로 재지향되거나 또는 MFAP(110)는 트리거된다. 제 1 인증 에이전트(710a)가 식별된 후, 725에서, MFAS(106)는 제 1 인증 요소의 인증을 수행하기 위해 제 1 AA 인증 에이전트(710a)를 트리거할 수도 있다. 728a에서, 도 8b를 특히 참조하면, 제 1 AA(710a) 및 사용자(107)는 인증을 수행할 수도 있다. 사용자(107)는 예를 들어 생체인식 판독기와 같은 판독기를 또한 지칭할 수도 있다. 728a에서의 인증은 사용자(107)로부터의 입력을 요구할 수도 있다. 예시된 실시형태에 따라, 730에서, 제 1 표명이 제 1 AA(710a)에 의해 생성되고, MFAP(110)로 전달될 수도 있다. 마찬가지로, 738a에서, 제 2 AA(710b) 및 사용자(107)는 제 2 인증 결과를 생성하기 위해, MFAP(110)에 의해 제 2 AA(710b)로 전송된 트리거에 응답하여 인증을 수행할 수도 있다. 740에서, 제 2 AA(710b)는 제 2 인증 결과를 MFAP(110)로 전송한다. 게다가, 747a에서, 제 3 AA(710c) 및 사용자(107), 특히 판독기(reader)는, 제 3 AA(710c)에 대해 MFAP(110)에 의해 개시된 트리거에 기초하여 제 3 인증 결과를 생성하는 인증을 수행할 수도 있다. 749에서, 도 7a 내지 도 7c를 계속 참조하여, 예시된 실시형태에 따라, 제 3 인증의 결과는 제 3 AA(710c)에 의해 MFAP(110)로 전송된다. 744a에서, MFAP(110)는 제 1, 제 2, 및 제 3 인증 표명들을 통합하여 다수의 인증 요소들에 대한 통합된 표명을 생성한다. MFAP(110)는 통합된 표명에 서명한다. MFAP(110)는 결집 달성 보증 레벨 및 신선도 레벨을 추가로 컴퓨팅할 수도 있다. 하나의 예에서, 결집 보증 레벨이 각각의 인증 요소에 연관된 보증 레벨을 함께 합산함으로써 컴퓨팅된다. 다른 예로서, 보증 레벨들은, 하나의 인증 요소가 인증 요소들 양쪽 모두에 대응하는 결집 보증 레벨에서의 다른 인증 요소에 비하여 더욱 무겁게 가중되도록 가중될 수도 있다. 각각의 인증 요소의 수명을 고려하는 신선도 쇠퇴(decay) 함수와 같은 부가적인 파라미터들이, 컴퓨팅 결집 보증 레벨에서 고려될 수도 있다. 다른 실시형태에서, MFAS(106)는 컴퓨팅된 결집 보증 레벨을 전송하지 않는다. 746a에서, 브라우저(704)는 MFAP(110)로부터 통합 표명을 수신한다. 748에서, 브라우저(704)는 그 표명을 SP(104)로 전송한다. 전송되는 표명은 수행되었던 다중요소 인증에 의해 달성되었던 신선도 레벨 및 보증 레벨을 포함할 수도 있다. 750에서, 예시된 실시형태에 따라, SP(104)는 표명, 특히 표명 서명을 검증하고, 752에서, SP(104)에 의해 제공된 요청된 서비스에 대한 액세스를 브라우저(704)의 사용자(107)에게 제공한다.
도 9a 내지 도 9c는 표명이 네트워크에 의해 수행되는 반면 인증들이 MFAP(110)에 의하여 UE(102) 상에서 수행될 수도 있는, 도 7a 내지 도 7c 및 도 8a 내지 도 8c의 변형예를 도시한다. 도 9a 내지 도 9c에 예시되어 있는 대부분의 단계들은 도 7a 내지 도 7c 및 도 8a 내지 도 8c에 관해 설명되어 있다. 도 9a 내지 도 9c를 참조하면, 예시된 실시형태에 따라, 901에서, MFAP(110)는 제 1, 제 2, 및 제 3 인증 결과들을 결합한다. MFAP(110)는 브라우저(704)에 대한 결집 달성 보증 레벨 및 신선도 레벨을 추가로 컴퓨팅할 수도 있다. 하나의 예에서, 결집 보증 레벨이 각각의 인증 요소에 연관된 보증 레벨을 함께 합산함으로써 컴퓨팅된다. 다른 예로서, 보증 레벨들은, 하나의 인증 요소가 인증 요소들 양쪽 모두에 대응하는 결집 보증 레벨에서의 다른 인증 요소에 비하여 더욱 무겁게 가중되도록 가중될 수도 있다. 각각의 인증 요소의 수명을 고려하는 신선도 쇠퇴(decay) 함수와 같은 부가적인 파라미터들이, 컴퓨팅 결집 보증 요소를 컴퓨팅함에 있어서 고려될 수도 있다. 902 및 904에서, MFAP(110)는 결합된 결과를 연관된 정보와 함께 브라우저(704)를 통해 MFAS(106)로 전송한다. 744b에서, MFAS(106)는 수신된 인증 결과들에 기초하여 서명된 표명을 생성한다. MFAS(106)는 도 9a 내지 도 9c에 묘사된 실시형태에 따라 통합된 표명에 서명한다. 906에서, MFAS(106)는 브라우저(704)를 사용하여 서명된 표명을 전송한다. 브라우저(704)는 MFAS(106)로부터 통합 표명을 수신한다. 748에서, 브라우저(704)는 그 표명을 SP(104)로 재지향시킨다. 전송되는 표명은 수행되었던 다중요소 인증에 의해 달성되었던 신선도 레벨 및 보증 레벨을 포함할 수도 있다. 750에서, 예시된 실시형태에 따라, SP(104)는 표명, 특히 표명 서명을 검증하고, 752에서, SP(104)에 의해 제공된 요청된 서비스에 대한 액세스를 브라우저(704)의 사용자(107)에게 제공한다. 위에서 설명된 온-디바이스 인증 또는 온-네트워크 인증 중 적어도 하나가 하나 이상의 정책들에 따라 수행될 수도 있다는 것이 이해될 것이다. 게다가, 서명된 표명은 UE(102) 상에서 MFAP(110)에 의하여 생성될 수도 있으며, 서명된 표명은 IdP/MFAS(106) 상에서 생성될 수도 있다.
이제 도 10을 참조하면, 일 예의 시스템(1000)이 제 1 네트워크 엔티티(1002a)로 축약되는(collapsed ) 제 1 RP(104a) 및 제 1 IdP(106a)를 포함하는 서비스 제공자 기능을 포함한다. 마찬가지로, 제 2 네트워크 엔티티(1002a)는 제 2 RP(104b) 및 제 2 IdP(106b)를 포함하고, 제 3 네트워크 엔티티(1002c)는 제 3 RP(104c) 및 제 3 IdP(106c)를 포함한다. 따라서, 네트워크 엔티티들(10002)은 각각이 더 강한 인증 서비스들을 제공하기 위하여 그들의 각각의 RP에서 MFAS 기능을 호스팅할 수 있다. 예시된 실시형태에 따라, 예시된 신뢰 당사자들은 다수의 인증 요소들을 수행할 수 있는 IdP의 역할을 또한 수행할 수도 있다. 따라서, 인증에 대한 하나의 요소, 이를테면 패스워드를 현재 사용하는, 예를 들어, 은행과 같은 주어진 RP는, 축약된 RP/IdP 내에서 제어되는 MFAS 기능을 호스팅함으로써 다중요소 인증을 향해 전개할 수도 있다. 네트워크 엔티티들(1002)의 구성은 예를 들어 모바일 네트워크 오퍼레이터(mobile network operator)들과 같은 제 3 당사자들에 의해 제공되는 다른 인증 요소들에 RP들이 접속되는 것을 또한 가능하게 할 수도 있다.
여전히 도 10을 대체로 참조하면, 예시된 RP/IdP 축약된 기능은, 아래에서 설명되는 바와 같이, 프라이버시를 보존할 수도 있다. 예를 들어, OpenID는 동작의 식별자 선택 모드로서 알려진 아이덴티티 프라이버시를 위한 메커니즘을 제공한다. 의사 아이덴티티(PID)가일 예의 실시형태에 따라 대안적 방식으로 달성될 수도 있다. 예로서, 사용자가 MFAS의 서비스들을 사용하여 IdP에 의해 인증된다면, PID라고 또한 지칭될 수 있는 임시 아이덴티티가 생성될 수도 있다. 그러면, 인증 보증 및 신선도가 액세스되고 있는 특정 서비스에 대해 충분하다고 가정하여, RP의 서비스들을 획득하기 원하는 사용자가 PID를 사용하여 IdP와 현존 인증을 활용함으로써 RP에 대한 이음매 없는 액세스를 얻을 수도 있다. 일 예의 실시형태에서, PID는 서비스 제공자 발행 아이덴티티와 함께 사용자의 아이덴티티로서 제시되고, 사전 인증 정보가 발견을 통해 복구된다. 예를 들어, 사전 인증 정보가 액세스에 충분하다면, 이음매 없고 투명한 액세스가 다른 인증을 수행하는 일 없이 제공된다. 이는, 예를 들어, 사용자가 한 번 인증되고 난 다음 PID가 시구간(예컨대, 한 시간)에 대해 유효할 때 유용할 수 있고, 따라서 다른 RP들에 액세스하기 위한 임의의 후속 시도들은 인증이 리프레싱을 요구하도록 그 시구간(예컨대, 그 시간)이 만료되기까지 사용자 개입 없이 이음매 없이 제공된다.
예로서 제시되지만 제한으로서는 아닌, PID가 도출될 수도 있는 방법의 일 예가 다음과 같이 도시된다:
SesssionString = UserID@IdP1|sessionID|Nonce|RP-ID|"String"
sessionID는 HTTP 세션 또는 TLS-마스터 비밀에 연관될 수도 있다. Nonce는 PID의 각각의 새로운 생성을 위해 MFAS에 의해 생성될 수도 있다. RP-ID는 RP의 도메인 ID(예컨대, www.bankofamerica.com 등과 같은 서버 검정서 내의 도메인 정보)일 수도 있다. "String"은 옵션이고, 예를 들어, PID 생성과 같은 동작의 유형을 식별하는 무엇일 수도 있다. "SessionString"은 다음의 예에 따라 도시된 다양한 파라미터들의 접합물(concatenation)이다:
PIDKey = HMAC-SHA-256 (Shared key, Nonce)
tempID = HMAC-SHA-256(PIDKey, SessionString);
PID = tem.pID@IdP1.com
도 11을 참조하면, 예의 시스템(1100)은 사용자(1102), 결합된 기능을 갖는 제 1 RP 및 IdP를 구비한 네트워크 엔티티(1104), 및 제 2 RP(1106)를 포함한다. 네트워크 엔티티(1104)는, 위에서 설명된 바와 같이, MFAS를 또한 포함할 수도 있다. 사용자(1102)는 도 11에서 "제인"이라고 지칭된다. 예의 시스템(1100)은 개시된 요지의 설명을 용이하게 하기 위해 단순화되고 본 개시물의 범위를 제한하도록 의도되지 않는다는 것이 이해될 것이다. 다른 디바이스들, 시스템들, 및 구성들이 시스템(1100)과 같은 시스템에 부가하여, 또는 그 대신에, 본원에 개시된 실시형태들을 구현하는데 사용될 수도 있고, 모든 이러한 실시형태들은 본 개시물의 범위 내인 것으로서 생각된다.
예시된 실시형태에 따라, 1108에서, 사용자(1102)는 자신의 UE에서 국소적으로 인증된다. 예를 들어, 사용자(1102)는 생체인식 인증이 발생하도록 UE의 지문 센서를 스위핑할 수도 있다. 일단 생체인식 인증이 완료되면, 이는 네트워크 엔티티(1104) 상에서 MFAS와의 로컬 인증의 등록을 트리거할 수도 있다. 부가적인 인증 요소들이 국소적으로 수행될 수도 있고, 그것들은 UE(1102) 상에 위치되는 MFAP(110)에 의해 용이하게 될 수도 있거나, 또는 부가적인 인증들이 네트워크 상에서 IdP(1104)의 서비스들을 사용하여 수행될 수도 있다. 예를 들어, 네트워크 인증이, 1110에서, 네트워크 엔티티(1104), 특히 MFAS에 의해 수행될 수도 있다. 1110에서의 인증에 기초하여, 1112에서, 의사 아이덴티티(ID)(PID)일 수도 있는 임시 아이덴티티가 생성된다. PID는 이전에 수행되었던 인증에 대응하는 연관된 수명 및 보증 레벨을 가질 수도 있다. 1114에서, PID는 사용자(1102)에게 전송된다. 1116에서, PID는 예를 들어 신뢰성 있는 플랫폼 모듈(trusted platform module, TPM) 또는 신뢰성 있는 실행 환경(trusted execution environment, TEE)과 같은 보안 엘리먼트 내에 저장되어서, PID는 MFAP(110)만이 액세스가능하다. 1118에서, 사용자는 예를 들어 사용자의 은행일 수도 있는 제 2 RP(1106)에 의해 제공된 서비스들에 액세스하기를 원한다. 1120에서, 사용자의 UE 상의 MFAP는 유효한 수명(만료되지 않음)을 갖는 유효한 인증이 있다고 인식한다. 유효한 인증은 이전에 수행되었던 인증을 나타낸다. 사용자의 UE 상의 MFAP는 PID를 획득하고, PID와 제 2 RP(1106)에 연관되는 사용자 아이덴티티(UID)를 통합시킨다. 1122에서, UE는 제 2 RP(1106)에 연관된 PID 및 UID를 제 2 RP(1106)로 전송한다. 1124에서, 제 2 RP(1106)는, 예를 들어, PID와 함께 제공된 도메인 정보에 기초하여, UID에 연관되는 PID를 옵션으로 검증할 수도 있다. 1126에서, RP(1106)는 RP l/IdP(1104)라고도 또한 지칭될 수도 있는 네트워크 엔티티(1104)를 발견하기 위하여 PID에 기초하여 발견 프로세스를 수행한다. RP(1106)는 사용자가 요청했던 서비스에 액세스하기 위해 사용자(제인)에게 요구되는 보증 레벨(AL) 요건을 결정한다. 1128 및 1130에서, 사용자(1102)는 RP(1106)에 의해 네트워크 엔티티(1104), 특히 IdP(1104)로 재지향된다. 재지향은 보증 레벨 요건들을 나타내는 정보를 포함할 수도 있다. 1132에서, MFAS는 당해 PID에 대한 유효한 인증이 있다고 인식했다. MFAS는 PID를 통합하고 옵션으로는 사용자의 프로파일 정보에 연관되는 파라미터들을 포함할 수도 있다. MFAS는 IdP(1104)에 의해 제 2 RP(1106)로 전송되는 서명된 표명을 생성한다. 1134에서, 네트워크 엔티티, 특히 MFAS는, 서명된 표명을 사용자(1102)를 통해 (예컨대, 제인의 웹 브라우저를 통해) 제 2 RP(1106)에게 전송한다. 사용자(1102)는, UE를 통해, 서명된 표명을 RP(1106)에게 포워딩한다. 1138에서, 제 2 RP(1106)는 UE로부터 수신하는 서명된 표명을 검증한다. 서명된 표명이 유효하다면, RP(1106)는 성공 메시지를 사용자(1102)에게 전송하고, 사용자/UE는 1142에서 RP(1106)에 의해 제공되는 서비스에 대한 액세스를 받을 수 있다. 따라서, 사용자(1102)는 네트워크 엔티티(1102)인 RP와 함께 현존 인증을 활용함으로써 RP(1106)에 의해 이음매 없이 인증된다.
이제 도 12a 내지 도 12e 그리고 또한 대체로 도 1을 참조하면, 일 예의 시스템(1200)이 도 12a 내지 도 12e에서 "제인"이라고 지칭되는 사용자(107)를 갖는 UE(102)를 포함한다. UE(102)는 로컬 생체인식 인증 기능(112)이 라고 또한 지칭될 수 있는 생체인식 클라이언트(112)를 구비한다. UE(102)는 MFAP(110) 및 브라우저(704)를 더 구비한다. 시스템(1200)은 제 1 RP(1202), 제 2 RP(1204), 및 MFAS(106)를 더 구비하는데, MFAS는 마스터 IdP(106)라고도 또한 지칭될 수도 있다.
도 12a를 특히 참조하면, 예시된 실시형태에 따라, 1206에서, 제 1 시간에, 사용자(107)는 제 1 RP(1202)인 자신의 은행(www.bac.com)과 적어도 하나의 거래를 수행하고 싶어한다. 1208에서, 사용자(107)는 자신의 사용자 아이덴티티(예컨대, jane@bac.com)를 제 1 RP(1202)에 의해 제공된 포탈의 "사용자 id" 필드 내에 입력한다. 브라우저(704) 또는 브라우저 플러그인은 사용될 수도 있는 PID가 있는지의 여부를 결정할 수도 있다. 1210에서, 제 1 RP(1202)는 예를 들어 사용자 아이덴티티에 기초하여 MFAS와 연관된다. 1212에서, 예시된 실시형태에 따라, RP(1202)(www.bac.com)에서의 정책들은 요청되고 있는 서비스에 액세스하기 위해 사용자(107)에게 요구된 보증 레벨을 결정한다. 요구된 보증 레벨은 사용자(107)에 관련된 사용자 프로파일 정보에 기초하여 결정될 수도 있다. 예를 들어, MFAS(106)는 사용자 프로파일 데이터베이스(DB)(1203)로부터 사용자 프로파일 정보를 검색할 수도 있다. 요구된 보증 레벨(AL)은 정책 DB 내에 저장된 정책들에 기초하여 또한 결정될 수도 있다. 정책 엔진 및 DB들은 마스터 IdP/MFAS/OP(106)에 위치될 수도 있다. 1214에서, RP(1202)는 브라우저(704)를 통해 인증 요건, 및 세션 핸들 또는 챌린지라고 일반적으로 지칭될 수도 있는 요구된 보증 레벨로 응답한다. 1216에서, 의도적으로 MFAP(110)를 호출한다.
도 12b를 특히 참조하면, 예시된 실시형태에 따라, 1218에서, 정책들과 RP(1202)에 의해 요청된 AL 및 수행 완료된 신선한 인증들에 기초하여, MFAP(110)는 수행되어야 할 남아있는 인증 요소들을 결정한다. 1220에서, MFAP(110)는 패스워드(PWD) 인증이 수행되어야 한다고 결정하고 그러므로 사용자(107)에게 자신의 PWD를 입력할 것을 요청할 수도 있다. 1222에서, 사용자(107)는 자신의 PWD를 입력하고 PWD는 MFAP(110)에서 수신된다. 1224에서, MFAP(110)는 패스워드를 체크하고 정책들에 기초하여, 로컬 생체인식 인증이 발생해야 한다고 결정한다. 1226에서, MFAP(110)는 생체인식 애플리케이션(112)이라고도 또한 지칭될 수도 있는 로컬 생체인식 인증 기능(112)을 호출한다. 1228에서, 생체인식 애플리케이션(112)은 사용자(107)에게 자신의 손가락들을 지문 판독기를 통해 스위핑할 것을 요청할 수도 있다. 1230에서, 사용자(107)는 지문 판독기에 커플링된 센서 상에서 자신의 손가락이 지나가게 하고, 지문(들)은 생체인식 애플리케이션(112)으로 전송된다.
도 12c를 특히 참조하면, 예시된 실시형태에 따라, 1232에서, 생체인식 애플리케이션(112)은 수신된 지문들 중에서 지문 모델을 생성하고 그 모델과 지문 등록 프로세스 동안 생성되었던 국소적으로 저장된 및 보안화된 지문 모델을 비교한다. 1234에서, 생체인식 인증의 결과들은 생체인식 애플리케이션(112)에 의해 MFAP(110)로 전송된다. 1236에서, 위에서 설명된 인증 요소들의 양쪽 모두가 성공적으로 수행된다면, 서명된 표명은 RP(1202)에 의해 제공된 핸들/챌린지를 사용하여 생성된다. 서명 키는 MasterIdP/MFAS(106), RP(1202), 및 MFAP(110) 간에 공유된 비밀일 수도 있다. 대안으로, MFAP(110)의 개인 키가 표명을 서명하기 위해 사용될 수도 있고 MFAP(110)의 대응하는 공개 키는 등록 프로세스 동안 MFAS(106)에 등록되었을 수도 있다. 서명된 표명은 RP(1202)에게 브라우저(704)를 통해 전송될 수도 있다. 부가하여, 1242에서, PID가 예의 실시형태에 따라 생성된다. 예를 들어, PID는 예를 들어 HMAC-SHA-256(PIDKey, SessionString)@bac.com과 같은 기능들과 동일할 수도 있다. 1238에서, MFAP(110)는 서명된 표명을 PID와 함께 MFAS/마스터 IdP(106)로 전송한다. 1240에서, MFAS(106)는 서명된 표명과 획득되었던 보증 레벨을 검증한다. 게다가, MFAS(106)는 1244에서 PID를 사용자 프로파일 DB(1203) 내에 등록시킬 수도 있다. 1246에서, 예시된 실시형태에 따라, MFAS(106)는 PID의 등록을 확인하고 HTTP(200) OK 메시지를 MFAP(110)로 전송한다. 1248에서, 브라우저(704)는 UE(102) 상의 사용자 DB를 당해 특정 신뢰의 원(CoT)에 대한 PID 정보로 업데이트하는데, 이는 아래에서 더 설명된다. 따라서, PID는 MFAP(110) 내에 등록되고 사용자(108)는 제 1 RP(1204)(예컨대, www.bac.com)에 의해 제공된 서비스들에 액세스할 수 있다.
도 12d를 특히 참조하면, 제 1 시간보다 나중인 제 2 시간에, 사용자는 예를 들어 브로커(예컨대, 메릴 린치)일 수도 있는 제 2 RP(1204)와 일부 거래들을 수행하고 싶어한다. 제 1 및 제 2 RP들은 원하는 대로 임의의 서비스 제공자들일 수도 있다. 1242에서, 사용자(107)는 제 2 RP(1204)에 연관되는 자신의 id(jane@merrillynch.com)를 사용하여 자신의 서비스 요청을 제 2 RP(1204)에게 전송할 것을 시도한다. 1254에서, 브라우저 플러그인(704)은 제 1 RP(1202)과는 동일한 CoT 내에 속하는 RP(1204)에 대해 요청이 이루어진다고 결정한다. 게다가, 브라우저(704)는 PID가 당해 사용자(107)에 대해 미리 존재한다고 결정한다. 따라서, 사용자 아이덴티티는 PID로 대체된다. 1256에서, PID(예컨대, abc12de82...@bac.com)가 "user id"로서 RP(1204)(www.merrillynch.com)에게 전송된다. 1258에서, PID(예컨대, bac.com)에 연관된 도메인 이름에 기초하여, OpenID를 사용한 발견 및 연관이 MFAS(106) 및 제 2 RP(1204) 간에 수행된다. 1260 및 1262에서, HTTP 메시지들은 이 예의 시나리오에서 또한 RP(1204)일 수도 있는 마스터 IdP(106)(www.bac.com)로 재지향된다. 1264에서, 도시된 예에 따라, IdP(106)는 AL 요건들을 체크하고 네트워크 기반 인증이 액세스가능하고 신선한 로컬 인증이 요청된다고 결정한다.
도 12e를 특히 참조하면, 예시된 실시형태에 따라, MFAS(106)는 핸들/챌린지 및 AL 요건들을 브라우저(704)를 통해 MFAP(110)로 전송한다. 1268에서, 핸들/챌린지 및 AL 요건들은 MFAP(110)로 전송된다. 1270에서, MFAP(110)는 임의의 로컬 인증들/요소들이 요청되었던 인증들의 정책들 및 신선도에 기초하여 수행되어야하는지의 여부를 결정한다. 도시된 예에 따라, MFAP(110)는 1270에서 서명된 표명을 생성한다. 1272에서, 서명된 표명은 브라우저(704)를 통해 MFAS(106)로 포워딩된다. 1274에서, MFAS(106)는 서명된 표명을 검증하고 요청된 AL이 달성되었는지를 검증한다. 1276에서, OID 프로토콜 다음에, 예를 들어, 서명된 표명을 포함하는 재지향 메시지가 제 2 RP(1204)(www.merrillynch.com)로 전송된다. 1280에서, 표명은 RP(1204)에 의해 검증된다. 1282에서, RP는 HTTP(200) Ok 메시지를 사용자에게 전송하고, 사용자(107)는 제 2 RP(1204)에 의해 제공된 요청된 서비스에 액세스할 수 있다. 따라서, 제 1 인증 동안 생성되는 PID는 다른 서비스 제공자들에 의해 제공된 서비스들에 대한 이음매 없고 자동화된 액세스를 사용자 개입 없이 얻기 위해 나중에 사용될 수 있다.
도 13 및 도 14를 참조하면, 제 1 신뢰의 원(CoT)(1302) 및 제 2 CoT(1304)가 UE(102)와 연관될 수도 있다. 각각의 CoT는 하나 이상의 신뢰 당사자들(1306)을 포함할 수도 있다. 일 예의 실시형태에서, RP들은 동일한 CoT에 있는 파트너들을 통해 다양한 서비스들을 제공할 수도 있다. 예를 들어 RP는 IdP 서비스들을 CoT 내의 다른 RP들(파트너들)에게 제공할 수도 있다. 몇몇 경우들에서, 사용자가 상호작용하는 제 1 RP는 CoT 내의 멤버들에 대한 IdP로서 역할을 할 수 있다. CoT 내의 사용자들을 위한 IdP로서 작동할 수도 있는 단일 또는 적은 수의 RP들만이 있는 것이 가능하다. 두 개의 CoT들, 특히 제 1 및 제 2 CoT들(1302 및 1304)에 접속되는 UE(102)가 도시되어 있지만, UE(102)는 원하는 대로 임의의 수의 CoT들과 접속될 수도 있다는 것이 이해될 것이다. 몇몇 경우들에서, UE/사용자(102)가 연관되는 다수의 CoT들에 RP가 속할 수도 있다. UE(102)는 각각의 CoT에 연관되는 아이덴티티를 가질 수도 있고, 각각의 아이덴티티는 서로에 대하여 고유할 수도 있다. 사용자 또는 UE가 CoT 내의 RP의 서비스들을 획득하고자 할 때, 당해 CoT와 연관되는 연관된 아이덴티티는 사용될 수도 있다. 아이덴티티 및 CoT 간의 관계는 디바이스 내에 미리 구성될 수도 있다. 도 14를 참조하면, 다중요소 인증일 수도 있는 인증이 UE/사용자(102)(UE@IdP1identity를 사용함) 및 RP(1304) 및 IdP1/MFAS(106)의 결합된 엔티티 간에 수행되었다면, 당해 인증 프로세스의 부분으로서 생성된 PID가 CoT(1302) 내의 다른 RP들(1306)과의 UE/사용자(102)에 의한 미래의 인증을 위해 사용된다. 예를 들어, PID에 연관된 유효성 또는 타임스탬프가 만료되었다면, IdP1/MFAS(106)와의 재인증이 수행될 수도 있다. 다른 예로서, 재인증은 유효한 인증들이 모든 시간에 이용가능한 것을 보장하기 위하여 연속적으로 수행될 수도 있다.
일 예의 실시형태에서, PID의 프라이버시는, 동일한 CoT 내의 RP들이 CoT 내의 다른 RP들의 각각과 연관된 사용자의 영구적 아이덴티티들에 관여하지 못하는 것을 보장한다. 몇몇 경우들에서, PID들만이 IdP(MFAS(106))로 수행된 인증을 식별하기 위해 사용된다. PID 및 연관된 CoT 및 RP 정보를 보안성있게 저장하는 브라우저 플러그인 또는 애플리케이션이, 예로서 제시되지만 제한으로서 제시되지는 않는 다음으로서 제시될 수도 있다:
[표 1]
Figure 112015115742954-pct00001
몇몇 경우들에서, 특정 사용자가 RP/IdP들의 각각에 연관된 대응 인증 크리덴셜들(예컨대, UID/PWD, 토큰들, 공개/개인 키들 등)을 갖는 사용자 프로파일을 가진다. 따라서, 인증 크리덴셜들은 CoT 내의 멤버들 간에 차이가 있을 수도 있다. 따라서, 각각의 RP/IdP가 동일한 CoT 내에 있을 수도 있더라도, 제 1 RP/IdP로 수행된 인증의 AL은 제 2 RP/IdP로 수행된 인증의 AL과는 상이할 수도 있다. 게다가, 메시지들 및 챌린지들/핸들이 고유한 서명 키들(RP<->사용자)로 서명될 수도 있는 한편, 동시에 표명들이 (사용자 <-> IdP/RP) 키들에 의해 서명될 수도 있다. 이는 보안의 부가적인 레벨을 제공할 수도 있다. 예의 키들은 표 2에서 제시된다.
[표 2]
Figure 112015115742954-pct00002
위에서 설명된 대로 구축 및 사용되는 의사 ID들은 서비스들에 대한 익명의 액세스를 가능하게 할 수도 있다. 하나의 실시형태에서, PID들은 일회성 식별자들이고 따라서 그것들은 PID들을 수신하는 RP들로부터 사용자가 개인화된 서비스들을 획득하는 것을 방지한다. 예를 들어, PID들은, 예를 들어, 이름 또는 PID의 부분인 다른 개인적으로 식별가능한 정보를 갖지 않고서도, 사용자가 특정 IdP의 CoT의 '멤버'임을 나타내는 유사 '멤버십 카드들'일 수도 있다.
일 예의 실시형태에 따라, PID들이 서로 링크 가능할 수 있기 때문에, 사용자가 일관된 서비스를 받을 수도 있다. 예를 들어, 특정 시퀀스에서 사용되는 PID들은 링크가능할 수 있다. 예로서, MFAP(110)는 액세스되는 각각의 RP에 대해 마지막 사용된 PID를 저장하고 그것을 현재 PID와 함께 특정 RP로 전송할 수도 있다. 리플레이 공격들의 확인 및 방지를 위해, 새로운 PID는, 예를 들어, 다음과 같이 구축될 수도 있다:
PID_new = HMAC-SHA-256(PIDKey, SessionString).
링크가능성(linkability)은 일 예의 실시형태에 따라 임의의 시간에 깨어질 수 있다. 예를 들어, 링크가능성은 사용자의 요청에 의해 또는, 예를 들면, 이전에 사용된 PID에 링크되지 않는 신선한 PID를 생성함으로써 깨어질 수도 있다.
아래에서 사용되는 바와 같이, "연합 타겟"이란 용어는 네트워크 인증 제공자 기능들(예컨대, OP/NAF들, BSF들 등), IdP 기술들(OpenID, Liberty, RADIUS, LDAP 등), 네트워크 인증 보안 앵커들(UICC, 스마트 카드, NFC 보안 엘리먼트, 토큰 등), 사용자 인증 방법들(PIN, 생체인식, OTP, 토큰, 다중요소 등), 온-디바이스 애플리케이션들(브라우저, 앱) 등을 지칭할 수도 있다. 다양한 예의 실시형태들에서, 사용자의 클라이언트 디바이스가 통상적인 것보다 더 미세한 세분화 구조를 갖고, 따라서 그 디바이스는, 그것들 자신이 연합 타겟들인, 예를 들어 보안 엘리먼트들 및 애플리케이션들과 같은 별개의 엔티티들을 포함할 수도 있다.
편이를 위해, 연합 타겟들의 일 예의 리스트가 표 3에서 제한이 아닌 예로서 제시된다.
[표 3]
Figure 112015115742954-pct00003
표 3을 참조하면, 디바이스 세계 및 네트워크 세계는 부분적 "거울 이미지" 대칭을 나타낼 수도 있다. 몇몇 경우들에서, 이 대칭은, 예를 들어 사용자 및 사용자가 등록되는 아이덴티티 제공자 간, 또는 네트워크 인증에 연관된 물리적 보안 앵커들 간 등의 신뢰 관계를 나타낼 수도 있다. 다른 경우들에서, 디바이스 및 네트워크 세계 간의 연결은, 예를 들어 수많은 WiFi 네트워크들에 대한 액세스를 용이하게 하는 포괄적 WiFi 클라이언트 애플리케이션과 같은 기능적인 것일 수도 있으며, 이 경우 이 애플리케이션 자체는 한 유형의 서비스들에 걸쳐 연합하는 수단의 부분이 될 수도 있다.
연합 타겟들은, 엔티티 클래스들로서 또는 그것들의 구체적인 인스턴스화물들로서, 아래에서 설명되는 예의 SSO 아키텍처들에서 나타난다. 그것들 외에, 하나 이상의 타겟 엔티티 클래스들에 대한 연합을 달성함에 있어서 수단이 될 수도 있는 기능적 구축 블록들이 또한 있을 수도 있다. 예를 들면, "SSO 프레임워크"라는 용어는 디바이스 상의 기능적 넥서스(nexus)를 지칭하는데, 이 넥서스는 사용자 인증 방법들, 애플리케이션들, 및 보안 앵커들을 연합함에 있어서 중심적인 역할을 담당할 수도 있다.
아래의 약어들은 위에서 소개된 엔티티 클래스들을 위해 사용될 수도 있다. 다음의 테이블은 몇몇 두문자어들을 열거한다. 본원에서 사용되는 다른 두문자어들은 잘 알려진 것일 수도 있다. 표 4를 참조하면, U 및 UID는 사용자들 및 식별자들로서 실시되는 그들의 아이덴티티들 간의 차이를 나타낼 수도 있다. 예를 들어, 하나의 사용자가 하나를 초과하는 아이덴티티를 가질 수도 있다.
[표 4]
Figure 112015115742954-pct00004
본원에서 사용되는 바와 같이 신뢰 당사자(RP)라는 용어는 사용자들에 대한 아이덴티티 표명들을 수락 및/또는 평가하는 엔티티를 지칭할 수도 있다. 서비스(SRV)가 서비스 제공자를 제한 없이 지칭할 수 있다. 게다가, 서비스가 RP일 수 있지만 RP일 필요는 없다.
배경으로서, 연합 아이덴티티 관리 시스템들을 통해, 서비스 제공자들은 인증 표명들을 위해 제 3 당사자에게 액세스하는 수단을 갖는다. 이는 사용자들이 제공자들(SRV)에게 액세스하기 위해 기억할 필요가 있는 크리덴셜들의 수를 제한함으로써 인증이 사용자들에 대해 더욱 사용자 친화적이게 한다. 그러나, 사용자들이 저가 서비스들로부터 고가 서비스들로의 가변 등급 서비스들에 액세스할 때, 인증의 강도는 세분화 패션으로 또한 가변할 수도 있다. 사용자들을 최고 인증 등급으로 귀찮게 하기 보다는, 필요할 때만 사용자들에게 부담을 주는 것이 유익할 수도 있다는 것이 본원에서 인식된다. 따라서, 연합 시스템들에 가변 등급 인증을 제공하는 것은 사용자들에 대한 인증 경험을 단순화시키면서도 필요할 때는 고 강도 인증을 여전히 제공할 수도 있다.
추가의 배경으로서, IdP들은 사용자 아이덴티티들(예컨대, 명명된 ID들, 이를테면 이메일 주소들) 및 사용자 특정 데이터(이를테면 결제(billing) 및 배송(shipping) 정보 또는 소비자 선호도들)를 종종 포괄적으로 제공한다. 하지만 IdP들 자체는 사용자 이름/패스워드보다는 더 강한 사용자 인증 방법들을 일반적으로 제공하지 않는다. 더 강한 인증 방법들을 채용하기 위한 IdP들에 의한 다양한 시도들은, 지금까지 산발적, 사유적, 및 프래그먼트식(이를테면 특수 암호 토큰들 또는 이차적인 채널을 사용하는 요소들로서 SMS OTP들을 채용함), 또는 규모상 고비용 구현(이를테면 키 포브들)인 채로 남아 있다. 그러므로, 현재 기술은 서비스 제공자들에게 유연하지 못하여, 서비스 제공자들은 사용자들에 대한 인증 방법들을 선택하는 것이 가능하지 않다. 또한, 인증 방법 기술들의 프래그먼트화는 확장성 및 전개 비용에 부정적으로 영향을 미친다.
현재 기술들은 서비스 제공자들이 체크아웃 및 지불과는 대조적으로 상이한 환경들, 예컨대, 웹 상점에 우선 로그온(first log-on to a Web shop)에서 사용자들의 다중요소 인증을 유연하게 통제하는 정책들을 기술하고 시행하는 것을 가능하지 않게 한다. 또한, 서비스 제공자들은 다수의 부가적인 인증 요소들에 액세스하기 위해, 예컨대, GBA를 사용한 3GPP 네트워크 인증과 같은 네트워크 기반 인증 방법들에 쉽사리 접속할 수 없다.
도 15를 참조하면, 예시된 실시형태에 따라, 일 예의 아키텍처(1500)가 서비스들(1502) 및 IdP들(IDP)(1504) 간에, 그리고 서비스들(1502) 및 네트워크 인증 엔티티들(NAE)(1506) 간에 중간 층을 제공한다. 중간 층은 연합 넥서스(federation nexus, FNX)(1508)라고 지칭될 수도 있다. FNX(1508)는, 고전적 아이덴티티 제공자 역할을 수행하는 것에 더하여, 서브 기능들의 클래스들로 간주될 수도 있는 브로커들 및 커넥터들(1510)을 제어하는 포괄 마스터 IdP 역할을 수행할 수도 있다. FNX(1508)는 MFAP(110) 또는 MFAS(106)(도 1 참조) 상에 상주하는 논리적 엔티티일 수도 있다.
여전히 도 15를 참조하면, 예시된 실시형태에 따라, 커넥터들(1510)은 다양한 표준화된 또는 사유 네트워크 기반 인증 방법들에 인터페이스들을 제공하는 NAE 커넥터들(1510a)일 수도 있다. 커넥터들(1510)은 사용자 식별자들 및 사용자 정보를 해제할 수도 있는 IDP들(1506)에게 인터페이스들을 제공하는 IDP 커넥터들(1510b)일 수도 있다. 커넥터들(1510)은 예를 들어 AAA와 같은 사용자 인증 및 관리를 위한 다양한 서비스들에 인터페이스들을 제공하는 서비스 커넥터들(1510c)일 수도 있다.
도 15를 여전히 참조하면, 일 예의 실시형태에 따라, 보증 레벨 브로커(ALB)(1512)가 FNX(1508)의 필수적 기능을 허용할 수도 있는 데이터베이스 및 로직 기능이다. ALB(1512)는 보증 레벨들을 위에서 설명된 바와 같이 매핑할 수도 있다. 보증 레벨들은, 예를 들어 보증 기관(1516)같은 어떤 기관에 의해 정의된 사용자 진위의 보증 레벨들의 열거물들을 지칭할 수도 있다. 따라서, ALB(1512)는 보증 레벨들을 인증 방법들과, 예를 들어, 인증의 신선도와 같은 보충적 조건들에 메핑할 수도 있다. 일 예의 실시형태에 따라, 인증 프런트 엔드(authentication front end, AFE) 브로커(AFB)(1514)가 사용자 인증을 지원하기 위해 맞춤화된 프런트 엔드들(예컨대, 자바스크립트들 또는 ActiveX 엘리먼트들과 같은 웹 페이지들 또는 액티브 웹 엘리먼트들)을 제공하는 브로커일 수도 있다. AFE(1514)는 (예컨대, EAP-SIM과 같은 NAE 인증이 이메일 주소와 같은 IDP 아이덴티티에 대한 인증을 위해 사용된다는 사용자로부터의 수락에 반영되고 및 그 수락을 요청하는) 결합된 인증들을 나타내는 맞춤화된 프런트 엔드들을 제공할 수도 있다.
이제 도 16을 참조하면, 일 예의 아키텍처(1600)가 서비스들(1502) 및 '백엔드' IdP들(1504) 간을 중재하고 인터페이싱하는 프록시 IdP(1602)를 포함한다. 예시된 실시형태에 따라, 프록시 IDP(1602)는 IDP(1504) 및 NAE(1506) 엔티티들로서 일반적으로 지칭될 수 있는 백엔드 인증 및 아이덴티티 서비스들과 서비스들(1502) 간에 중간 결집 계층을 확립할 수도 있다. 프록시 IDP(1602)는 다른 IdP들로의 연결들을 포함할 수도 있다. 프록시 IdP(1506)는 IdP들/NAE들에 대한 커스텀 연결들을 또한 가질 수도 있다.
예의 아키텍처(1600)는 예를 들어 구글 툴킷(1606) 또는 플러그인(1608)과 같은 인증 프런트 엔드들에 SRV(1502)를 연결하는 인증 프런트 엔드(AFRO) 결집기(1604)를 더 포함한다. AFRO 결집기(1604)는 AFRO로부터 프록시 IDP(1602)로의 정보 교환을 제공할 수도 있다. 따라서, 상이한 AFRO들이 다양한 IDP 및 NAE 방법들을 트리거하는데 사용될 수 있다. 또한, AFRO 결집기(1604)는 예를 들어 트리거들을 통해 인터-통신을 제공함으로써 다수의 SRV(1502)를 수반하는 사용 사례들을 용이하게 할 수도 있다.
프록시 IDP(1602)는 예를 들어 EAP-SIM, GBA, AKA, AKA' 등과 같은 다수의 상이한 NAE 프로토콜들에 대한 연결을 제공할 수도 있다. 프록시 IDP(1602)는 OpenID Connect 제공자들, SAML 기관들, X.509 CA들, RADIUS 및 LDAP 서버들 등과 같은 상이한 인터페이스들을 통해 IDP들에 대한 연결을 제공할 수도 있다. 프록시 IdP(1602)는 NAE 인증들을 트리거할 수도 있다. 프록시 IdP는 자신 소유의 매핑 데이터베이스를 사용함 또는 UE 상에 상주할 수도 있는 다른 엔티티에 의해 매핑을 트리거함 중 어느 하나를 함으로써 상이한 아이덴티티 도메인들 간에 UID를 매핑할 수 있다. 프록시 IDP(1602)는, 예를 들면 프로세스 동기화를 위해 AFRO 결집기(1604)와 통신할 수 있다. 프록시 IDP(1602)는 사용자 인증에 관한 정책들을 유지 및 시행할 수도 있다.
AFRO 결집기(1604)는 다양한 기능들을 수행할 수도 있다. 예로서, AFRO 결집기(1604)는 인증 트리거 엘리먼트들, 이를테면 자바스크립트 코드가 수반되는 버튼들을 동적으로 생성할 수도 있다. 결집기(1604)는 트리거 엘리먼트들을 서비스들 및/또는 사용자 디바이스들에게 전송할 수도 있다. 결집기(1604)는 사용자 디바이스에게 전송될 수 있는 코드 엘리먼트들을 동적으로 생성할 수 있다. 그 코드 엘리먼트들은, 예를 들어 NAE 또는 사용자 인증 방법들과 같은 인증 방법들을, 상호작용시키기, 예를 들면 트리거하기 위해 디바이스에 의해 사용될 수 있다. 도 16에 예시된 일부 엔티티들은 축소될 및/또는 다른 엔티티들의 역할과 통합될 수도 있다는 것이 이해될 것이다. 예를 들면, NAE가 또한 IdP일 수도 있다. 게다가, 프록시 IDP 및 AFRO 결집기가 일 예의 실시형태에 따라 서로 통합될 수도 있다. SRV(1502) 및 프록시 IDP(1602) 간의 인터페이스는 예를 들어 OpenID와 같은 미리 정의된 인터페이스일 수도 있다. 따라서, SRV(1502)는 프록시 IDP(1602)에서의 OP 기능에 직접적으로 연결될 수도 있다. 대안으로, 프록시 IDP(1602)는 SRV 선호도들에 따라 수많은 인터페이스들을 통합할 수도 있다.
일 예의 시나리오가 프록시 IDP(1602)에 의해 가능하게 되는 예의 유익한 기능들을 추가로 설명하기 위해 아래에서 설명된다. 예로서, 사용자가 자신의 랩톱 컴퓨터 상에서 대형 인터넷 IDP(예컨대 구글)에 의해 제공된 아이덴티티를 사용하여 온라인 상점에 로그인한다. 일단 그의 장바구니가 채워지면 그는 체크아웃으로 진행한다. 상점의 체크아웃 기능은 더 강한 요소, 이 예의 경우에 NAE(예컨대, OpenID/GBA를 사용함)에 의한 인증을 요구한다. 이를 수행하기 위해, 프록시 IDP(1602)는 사용자의 스마트폰 상의 OpenID/GBA 인증을 트리거한다. 전제조건으로서, 프록시 IDP(1602)는 인터넷 IDP로부터 NAE 제 2 요소 인증(예컨대, IMSI)을 위해 사용된 식별자로 사용자 아이덴티티를 매핑한다. 위에서 설명된 예에서, 프라이버시는 보존될 수도 있다. 예를 들어, 온라인 IDP가 사용자의 NAE 식별자를 아는 것이 필요하지 않다. 마찬가지로, NAE는 그 상점에 대해 사용된 온라인 UID를 알 필요가 없다. 위에서 설명된 온라인 IDP 및/또는 NAE는 그것들 간에 상호접속을 필요로 하는 일 없이, 예를 들어 결제와 같은 체크아웃에 부가적인 백엔드 기능들을 제공할 수도 있다. 게다가, 인증 요소들은 예를 들어 요건들에 따라 조율되고 결합될 수도 있다.
아래에서 설명되는 다른 예의 시나리오는 결정된 NAE 및/또는 사용자 인증 방법을 사용하여, 하나의 IDP로부터 다른 IDP로의 사용자의 일 예의 등록을 예시한다. 예로서, 사용자의 디바이스가 사용자가 연결하고 싶어하는 부근의 이전의 알려지지 않은 WiFi 핫스팟 네트워크를 발견할 수도 있다. 핫스팟 네트워크는, 사용자가 결제를 위해 MNO 가입을 또한 보여줄 수 있는 경우에, 사용자의 구글 메일 아이덴티티들을 수락한다고 통보한다. 프록시 IDP(1602)는 구글 메일 아이덴티티의 MNO 아이덴티티(예컨대, IMSI)로의 매핑에 의해, 또는 그러한 매핑의 트리거링에 의해 이 예의 사용 사례를 가능하게 할 수도 있다. 프록시 IDP(1602)는 사용자 선호사항들 및 핫스팟 네트워크 사용 정책들이 서로에 따르는지를 체크할 수도 있다. 프록시 IDP(1602)는 핫스팟 네트워크 약관(terms and conditions)을 사용자에게 디스플레이하고 사용자에 의한 그것의 수락을 획득하기 위해 AFRO 결집기(1604)를 통해 적합한 프런트엔드에 연결할 수도 있다. 게다가, 프록시 IdP는 핫스팟 네트워크에 의해 요구될 수도 있는 특정한 사용자 정보를 전송(또는 그러한 정보의 전송을 트리거)할 수도 있다.
이제 도 17을 참조하면, FNX(1508)는 예를 들어 인증 보증 레벨들에 대한 그들의 각각의 정책들에 기초하여 SRV(1502)에 의해 요청된 바와 같은 다수의 인증 요소들을 사용하여 인증들을 가능하게 할 수도 있다. 예시된 실시형태에 따라, 프록시 IdP(1602), 예를 들어 OpenID 제공자 인스턴스는, 기술적 엔드포인트이다. 따라서, 다중요소 인증에 대한 부가적인 로직, 이를테면 정책 협상 기능부(1702) 및 다중요소 표명 기능부(1704)가, SRV(1502)로부터 분리되고 숨겨질 수도 있다. 예시된 바와 같이, 부가적인 로직은 다중요소 조율기(multi-factor orchestrator, MFO)(1706)라고 지칭되는 조향 엔티티에 집중된다. MFO(1706)는 OP가 프런트 엔드로서 FNX(1508)와 통합되는 경우에 OP를 제어할 수도 있다.
다중요소 인증들을 수행하기 위해, OP는 전체 인증 프로시저를 개시하기 위해 및 완료하기 위해 부가적인 기능들을 요구할 수도 있다. 예를 들어, OP는, 정책 DB(1708)에 저장될 수도 있는 SRV(1502)에 의해 제기된 인증의 요건들과 사용자/UE 데이터베이스(1710)에 저장될 수도 있는 각각의 사용자 및 UE의 능력들/선호도들 간의 일치를 찾는 특정 정책 협상 기능, 예를 들어 정책 협상 기능부(1702)를 요구할 수도 있다.
여전히 도 17을 참조하면, 다중요소 표명 기능부(1704)는 일어났던 다중요소 인증들의 구체사항들을 준비 및 평가할 수도 있다. 도시된 바와 같이, MFO, 정책 협상, 표명 생성, 및 OP 엔드포인트는 긴밀하게 통합될 수도 있지만, 그것들은 또한 애플리케이션 계층 인터페이스들에 의해 느슨하게 커플링될 및 연결될 수도 있다. 실제, 단일 인증들은 그것들이 전체 다중요소 프로세스에 관해 각각이 얽매이지 않도록 투명 방식으로 수행될 수도 있다.
도 18을 대체로 참조하면, 디바이스 세계 연합 아키텍처는 네트워크 세계 아키텍처에 대해 대칭적으로 구축된다. 일 예의 경우, 디바이스가, 연합의 목적을 위해, 백엔드 엔티티, 특히 예를 들어 MFAS(106)에 의해 원격으로 제어되는 패시브 엔티티로 간주될 수 있다. 이 유형의 시나리오는 디바이스들 상으로의 연합 기술의 전개의 측면에서 최소의 요건들을 제기한다. 결과로서, 레벨 1 디바이스 측 아키텍처를 사용하는 현재의 연합 프로시저들은 '클라우드 연합(federation in the cloud)'에 집중한다. 따라서, 연합의 주요 태스크들, 이를테면 인증 요소들의 조합은, 네트워크 세계 엔티티들 MFAS 및 NAE들에 의해 생길 수도 있다.
도 18을 참조하면, 디바이스(102) 상에 미리 존재할 수도 있는 로컬 인증 기능들, 이를테면 UICC에서의 EAP-SIM 인증이, 브라우저들 및 다른 애플리케이션들에 의해 노출될 수도 있다. 이들 플러그인 엘리먼트들은 MFAS(106)를 통해 인증 NAD들 및 네트워크 백엔드 간에 단순화된 통신 인터페이싱을 수행할 수도 있다. 통신은 NAD 인증을 트리거한다.
다양한 인증 플러그인들, 이를테면 플러그인들(1802)이 특정한 인증 엔드포인트들(1804)을 통해 그것들의 각각의 NAD들을 동작시킬 수도 있다. 예를 들면, 인증 엔드포인트가 EAP-SIM 또는 AKA 프로토콜 스택으로 이루어질 수도 있다. 차례로 인증 엔드포인트들(1804)은 미리 정의된 인터페이스들을 통해 실제 NAD 인증에 액세스할 수도 있다. 몇몇 경우들에서, 다수의 인증 엔드포인트들 및 NAD들은, 예를 들면 안드로이드 운영 체제로부터 다양한 보안 엘리먼트들로의 액세스를 허용하는 OpenMobile API와 같은, 공통 API를 통해 액세스될 수도 있다.
특정 인증 요소들은 예를 들어 생체인식 요소들과 같은 로컬 사용자 인증 요소들을 포함할 수도 있다. 그것들의 인증 엔드포인트들 및 NAD들(생체인식 판독기들)이, BioKey의 웹키에 의해 제공된 바와 같은 사유 기술로 이루일 수도 있다. 일부 다른 인증 요소들은 사용자 상호작용 및/또는 로컬 사용자 인증을 또한 수반할 수도 있다. 몇몇 경우들에서, 이러한 상호작용들은 버튼을 누름 또는 PIN을 입력함으로써 인증 액션들을 수락하는 것으로 감소된다.
또한 도 19를 참조하면, 일 예의 아키텍처(1900)가 서브-측 MFAS(106)와 네트워킹할 수도 있는 디바이스(102) 상의 다중요소 인증을 위해 사용될 수 있다. 아키텍처(1900)는 다양한 방식들에서 위에서 설명된 패시브 디바이스 아키텍처와는 상이하다. 예를 들면, 아키텍처(1900)는 디바이스(102) 상에 MFAP(110)를 포함한다.
도 19를 참조하면, 일 예의 실시형태에 따라, 디바이스(102)의 신뢰성 있는 실행 환경(TEE)이, 중요한 데이터에 대한 부당변경(tampering)이 가능하지 않도록 아키텍처(1900)에서의 다양한 기능들을 보호할 수도 있다. 예의 보안 요건들에 대한 더욱 상세한 사항들은 아래에서 설명된다.
예를 위해, 다중요소 아키텍처(1900)의 예의 기능들이 안드로이드 플랫폼에 기초하여 설명되지만, 그 아키텍처는 다른 플랫폼들에 원하는 대로 또한 적용할 수도 있다는 것이 이해될 것이다. 정책 운용은, 안드로이드 OS 스키마 "soid.scheme://<method>.<factor>/<factor-data>"가 등록된 안드로이드 애플리케이션이 브라우저 에이전트(BA)(1902)를 사용하여 트리거될 때, MFAL(110)이라고도 또한 지칭될 수도 있는 다중요소 인증 프록시(110)에서 호출되는 제 1 활동일 수도 있다. 이 계층의 안드로이드 애플리케이션은 다중요소 인증에 대한 정책을 결정하고 필터링할 수도 있다. 예를 들어, 다양한 인증 요소들이 액세스 권한 정책에 기초하여 요구된다고 결정될 수도 있다. 디바이스-로컬 인증을 위해 정의된 정책에 기초하여, 상이한 로컬 인증 요소(local authentication factor, LAF)들(1904) 및 네트워크 인증 대리자(network authentication delegate, NAD)들(1906)이 인증 요청을 프로세싱하기 위해 호출된다. 상이한 인증 요소들은 안드로이드 애플리케이션에서의 상이한 활동들의 부분일 수도 있다.
MFAL(110)의 상태 및 로컬 인증 요소들(1904, LAF)은 안드로이드 OS의 애플리케이션 시스템 상태 애플리케이션으로 업데이트될 수도 있다. 이 시스템 상태 애플리케이션은, 가능하다면, TEE에서 실행해야 하는데, 그것이 인증 민감 정보, 이를테면 인증 요소들의 수, 인증 요소들의 상태(예컨대, 성공, 실패), 재시도 횟수, 세션 정보 등을 포함할 수도 있기 때문이다.
몇몇 경우들에서, LAF(19004)는 인증을 위해 UE(102)의 로컬 엔티티만을 요구하는 요소들일 수 있다. 예를 들어, 이러한 요소들은 로컬 데이터베이스, 로컬 지문 인증, 로컬 홍채 스캔, 행동 패턴 인증 등에 대한 로컬 패스워드 인증을 포함할 수도 있다.
네트워크 인증 대리자(NAD)(1906)는 내부/외부 네트워크의 서버들과의 통신을 요구할 수도 있다. 예의 인증들은 MNO 인증, SIM 기반 디바이스 인증, 지문 인증 등을 포함한다.
예시된 MFAL(110)에 포함된 로컬 표명 엔티티(local assertion entity, LAE)(1908)는 국소적으로 실행된 인증들에 관한 표명들을 발행하는 중심 지점일 수도 있다. 로컬 인증 시나리오(예컨대, 위에서 설명된 로컬 인증 + 네트워크 표명 시나리오)에서도, 네트워크 상에 LAE가 있을 수도 있다. LAE(1908)는, MFAS(106)로부터 수신된 바와 같은 로컬 인증들에 대한 성공적으로 실행된 인증 정책을 MFAL 정책 프로세서(1912)가 가진 후에, 표명들을 피어 MFAS(1906)에게 발행할 수도 있다.
사용자 인증과 같은 신뢰성 있는 기능들을 부여받은 사용자 디바이스(102) 상에 기능들, 로직, 및 데이터를 부여할 때, 보안이 필수적인 것이라고 본원에서는 인식된다. 아래에서 설명되는 것은 예의 아키텍처(1900) 상에 보안을 구현하는 몇몇 실시형태들이다.
하나의 실시형태에서, 단일 인증 요소들의 기능은 TEE에 반드시 포함될 필요는 없는데, 각각의 요소의 보안이 따로따로 평가될 수도 있기 때문이다. 따라서, 디바이스 상에서 국소적으로 수행되는 인증 요소들은 소프트 크리덴셜 저장소들을 사용하는 소프트웨어 보안 레벨들을 가질 수도 있다. 게다가, 인증 요소들은 스마트 카드들에 의해 제공된 하드웨어 보안을 가질 수도 있다. 다른 예로서, 로컬 인증 요소들은 중간 레벨들을 가질 수 있어, 예를 들면 보안 지문 판독기가 사용자 공간에서 실행하는 소프트웨어 매칭 알고리즘과 결합될 수도 있다. 게다가, 특정 인증 요소들은 다양한 실시형태들에 따라 TEE 자원들을 사용할 수도 있다.
인증 요소 NAD들(1906) 및 LAF들(1904)로부터의 데이터 경로들은 TEE 자원들, 예를 들면 암호화된/무결성 보호된 메시징에 의해 보안화될 수도 있다. 또한, LAF/NAD에 대한 사용자로부터의/사용자로의 데이터 경로들이 TEE 자원들에 의해 보안화될 수도 있다. 덧붙여서, 인증 결과들이 MFAL(110) 및 MFAS(106) 간에 전송되는 데이터 경로들은 일 예의 실시형태에서 보호된다.
데이터베이스들은 TEE-보호된 스토리지에 포함될 필요는 없지만, 예를 들어 적어도 무결성에 대해, TEE 자원들에 의해 보호될 수도 있다. 몇몇 경우들에서, 사용자/UE 데이터를 포함하는 DB들은 프라이버시를 위해 암호화된다.
MFAL(110)이 로컬 표명 생성 엔티티를 포함한다면, 예를 들어, 그것의 로직은 TEE 내부에서 보호될 수도 있다. 더욱이, 근본 크리덴셜들과 국소 발생된 표명들의 실제 서명 프로세스는 TEE에 의해 또는 LA에 대한 SE로서 표시될 수도 있는 별도의 보안 엘리먼트에 의해 보호될 수도 있다. SE는 장기 비밀(Long Term Secret, LTS)을 가질 수도 있다.
도 20을 참조하면, 일 예의 서브릿 아키텍처(2000)가 일 예의 실시형태에 따라 도시되어 있다. 예의 아키텍처(2000)는 OpenID 서브릿(2002), 다중요소 조율기(MFO)(1706), 및 개개의 인증 모듈들(2004)로 이루어진다. 컴포넌트들은 모듈화를 유지하여서, 현존 기본 시스템에 대한 추가의 확장들이 구현될 수 있다. 구현된 모듈러 및 느슨하게 커플링된 설계는 새로운 인증 모듈(2004)로서 본원에서 설명되는 정책 시스템, 또는 부가적인 인증 요소와 같은 부가적인 기능을 추가할 가능성을 제공한다. 개발 및 전개 관점에서, 아키텍처(2000)는 이점을 제공하는데, 다른 시스템들이 비교적 최소 노력으로 현존 시스템과 통합할 수도 있기 때문이다.
예시된 실시형태에 따라, OpenID 서브릿(2002)은 OpenID 프로토콜 기능을 포함한다. OpenID 서브릿(2002)은 RP(104)와의 OpenID 연관을 생성하는 그리고 OpenID 서명된 표명들을 생성하는 책임이 있을 수도 있다. MFO 조율기(1706)는 OpenID 서브릿(2002)에 대해 인터페이싱하고 다중요소 인증 기능을 제공한다. 예를 들어, OpenID 서브릿(2002)은 MFO(1706)를 트리거함으로써 다중요소 인증을 호출할 수도 있다. 이들 독립적인 서브릿들을 가짐으로써, 예를 들어, OpenID 프로토콜의 기능들 및 다중요소 인증의 기능들은 코드 의존성을 줄이기 위해 서로 분리된 채로 유지될 수도 있다.
MFO(1706)는 다중요소 인증을 위한 핵심 기능 컴포넌트일 수도 있다. 일 예의 실시형태에서, MFO(1706)는 인증 요소들을 페치하는 것, 개개의 요소들의 프로세싱을 순서화하는 것, 인증 모듈들에 대한 퇴출(exit) 조건들을 결정하는 것, 및 기초를 이루는 정책들에 기초하여 개개의 인증 결과들을 통합하는 것을 포함하는 다양한 기능들을 수행할 수 있다. 높은 레벨에서, MFO(1706)는 OpenID 서브릿(2002) 및 인증 모듈들(2004) 간의 게이트웨이로서 간주될 수 있다. MFO(1706)는 대부분의 인증의 주요 기능들이 이 모듈 내에 구현될 수 있을 때 현존 시스템의 추가의 확장의 가능성을 제공한다.
예시된 실시형태에 따라, 인증 모듈(2004)은 인증 요소의 유형(예컨대, 패스워드 인증(auth) 모듈, Biokey 인증 모듈, 스마트 OpenID 인증 모듈)에 기초한 다양한 인증 컴포넌트들을 포함한다. 예의 실시형태에 따라, MFO(1706)는, JSON 오브젝트로서 저장될 수도 있는, 각각의 사용자의 프로파일을 페치하고, 사용자가 수행할 수 있는 인증 요소들의 유형을 결정한다. 게다가, MFO(1706)는 인증 요소들이 수행될 순서를 결정할 수도 있다. 대응 인증 요소(예컨대, Biokey, 스마트 OpenID, EAP SIM)를 구현하는 인증 모듈(2004)은 MFO(1706)에 의해 트리거된다. 하나의 예의 실시형태에서, 일단 하나의 인증 요소에 특유한 코드의 실행이 완료되면, 제어는 MFO(1706)로 다시 되돌아가며, 그 MFO는 당해 사용자에 대한 필요한 인증 요소들의 모두에 걸쳐 반복하기까지 동일한 프로시저를 반복한다. 따라서, 다중요소 인증 프로세스는 인증 요소들 중 적어도 하나, 예를 들면 모두가 사용자에 의해 성공적으로 완료될 때 종료될 수도 있다.
JSON 텍스트 파일(2006)이 대응 키/값 쌍들을 갖는 오브젝트를 포함할 수도 있는데, 사용자이름 식별자를 오브젝트로 하고 대응 사용자 데이터를 JSON 스니펫(snippet)에서 보일 수 있는 키/값으로 한다. 하나의 실시형태에서, 그것은, 예를 들어 다음과 같은 다양한 정보를 저장하는 사용자 데이터베이스일 수도 있다:
{
"janesmith": {
"email":"janesmithnovalyst@gmail.com",
"nickname": "jane",
"fullname": "Jane Smith",
"dob": "27-07-2012",
"gender": "F",
"postcode": " 12345",
"country": "US",
"language": "us",
"timezone": "America/Los_Angeles",
"biokeylD": "janesmith",
"authF actors": "/biokey/password"
}
}
위의 예의 JSON 스니펫을 참조하면, 그 JSON 스니펫은 OpenID 식별자, 이 특정 사용자에 대한 인증을 위해 사용되는 인증 요소의 유형, 각각의 사용자에 대한 인증 요소들의 실행의 순서(이는 인증 요소들이 JSON 파일에서 특정되는 순서일 수도 있음), 및 Biokey 사람 ID를 포함하는 OpenID 프로토콜 정보를 포함할 수도 있다. JSON 스니펫은, 예를 들어 전체 이름, 이메일, 도시 등과 같은 사용자에 연관된 다양한 정보를 또한 포함할 수도 있다.
여전히 도 20을 참조하면, 예시된 인증 모듈들(2004)은 외부 모듈들이 아니고, MFAS(110)의 필수적인 부분이다. 몇몇 경우들에서, 모듈들(2004)은 그것들의 작업을 완료하기 위해 JSON 사용자 DB(2006)로부터의 정보를 사용할 수도 있다. 예를 들면, BioKey를 이용한 생체인식 인증의 경우, 인증 모듈(2004)은 반환된 BioKey ID를 사용자의 Biokey ID에 일치시키기 위해 DB를 사용할 수도 있다.
특정 인증 요소에 대한 재시도 및 신선도 정보가 인증 결과 오버젝트 내에 또한 저장될 수도 있다. 사용자들에 대한 인증 요소들로의 보증 레벨 매핑이 사용자 프로파일에 바인딩된 채로 또한 유지될 수도 있다.
도 21을 참조하면, 하나의 실시형태에 따라, MFAS(106)를 사용하는 각각의 사용자는 서버(106) 내에서내부적으로 동작들을 위해 사용되는 내부 DB40 사용자 레코드를 가질 수도 있다. 일 예의 실시형태에서, 도 21을 참조하면, MFAS(106)는 오픈 소스 라이브러리를 이용하는 동작 모듈을 통해 LDAP(2102)와 상호작용한다. 따라서, MFAS(106)는 (2102)에 접속하고 LDAP(2102)로부터 사용자 ID에 기초하여 사용자 정보를 페치하는 동작들을 포함할 수도 있다. 예를 들어, 일반 브라우저를 사용하고 있는 UE(102)는 신뢰 당사자의 URL을 누르고 자신의 OpenID 식별자를 입력할 수도 있다. 신뢰 당사자는 OpenID 식별자에 기초하여 OpenID 프로토콜을 실행하기 위해 MFAS(106)를 트리거한다. MFAS(106) 상의 DB4O 동작 모듈이 LDAP(2102)로부터 페치되는 사용자 프로파일 정보를 채울 수도 있다. DB40 동작들은 사용자 프로파일 정보를 저장, 판독, 및 업데이트하는 기능을 포함할 수도 있다. 예시된 바와 같이, LDAP 서버(2102)는 LDAP 접속을 확립함으로써 MFAS 서버(106)에 의해 도달가능한 외부 엔티티일 수도 있다. 오라클 데이터베이스(2104)가 Biokey 셋업의 부분일 수도 있는 외부 엔티티이다. 오라클 데이터베이스(2104)는 오라클 데이터베이스 접속을 확립함으로써 웹키 서버(2106)에 의해 도달가능할 수도 있다.
여전히 도 21을 참조하면, 예시된 실시형태에 따라, 클라이언트 머신(102)에는 지문 등록 및 식별 목적들을 위한 드라이버들이 설치된다. 클라이언트 머신(102)은 HTTP를 통해 RP(102), MFAS(106), 웹키 서버(2106), 및 웹키 애플리케이션 서버에 도달할 수 있다. MFAS 서버(106) 및 웹키 서버(2106) 간의 통신은 HTTP를 통할 수도 있다.
도 22 및 도 20을 참조하면, 예시된 실시형태에 따라, 2202에서, 사용자(107)는 OpenID URL/사용자이름을 입력한다. 2204에서, 신뢰 당사자(104)는 OpenID 제공자(106)를 발견하고 연관을 확립한다. 2206에서, RP(104)는 사용자 장비(102)를 OP(106)로 재지향시킨다. 2208에서, 사용자(102/107)는 Open ID 제공자(106)로의 재지향을 추종한다. OpenID 제공자(106)는 UE(102)의 인증을 위해 제어를 MFO(1706)에게 넘겨준다. OpenID 서브릿(2002)은 사용자 식별자의 존재를 체크하기 위해 사용자 DB JSON 파일(2006)에 액세스한다. 다중요소 조율(MFO)(1706)은 사용자에 대한 인증 요소들을 포함하는 요청된 사용자 정보를 JSON 파일(2006)로부터 페치하고, 개개의 인증 요소를 프로세싱한다. MFO(1706)는 인증 요소들 및 실행의 순서를 사용자를 위한 JSON 파일로부터 판독한다. 2209에서, MFO(1706)는 패스워드 모듈들, biokey 모듈들 EAP-SIM 모듈들 등과 같은 개개의 인증 모듈들(2004)에게 제어를 넘겨준다. 2211에서, 각 개개의 인증 요소가 실행된 후, 그것은 제어를 MFO(1706)로 반환하고, MFO는 다음의 인증 요소를 트리거한다. 따라서, 단계들(2209 및 2211)은 특정 사용자에 대한 모든 요소들이 완료되기까지 각각의 인증 요소에 대해 반복될 수도 있다. 2213에서, 일단 모든 인증 요소들이 예를 들어 프로세싱되었다면, 다중요소 조율기(MFO)(1706)는 개개의 인증 요소 결과들을 사용하여 통합된 다중요소 사용자 인증 결과를 프로세싱한다. 2210에서, 일단 사용자에 대한 다중요소 인증 결과가 성공하면, 예를 들어, OpenlD 서브릿(2002)은 OpenlD 서명된 표명을 생성한다. 2212에서, HTTP 재지향을 추종함으로써, 사용자(107)는 RP(104)에 대해 이 서명된 표명을 취한다. 따라서, 2214에서, 사용자(107) 및 UE(102)는 RP(104)에 의해 제공된 서비스들에 액세스할 수 있다.
도 20을 참조하면, OpenlD 서브릿(2002) 및 MFO(1706)는 일 예의 실시형태에서 구현되는 부가적인 특징들에 대한 통합 포인트들을 포함한다. 예를 들어, OpenlD 서브릿(2002)은 RP와의 협상을 가능하게 할 수 있는 정책 협상 기능을 더 포함할 수도 있다. OpenlD 서브릿은 그것이 개개의 인증 요소들에 대한 다중요소 인증 표명들을 생성 및 서명할 수 있도록 표명 생성 기능을 또한 구비할 수도 있다. MFO(1706)는, 그것이 신선도를 체크하며, 인증 재시도들을 추적하며, 정책들을 시행하고, 예를 들어 Biokey 식별자들과 같은 요소들로부터 반환되는 속성들을 평가하는 것을 허용하는 기능을 더 포함할 수도 있다.
이제 도 23을 참조하면, 일 예 정책 기반 인증 아키텍처(2300)가 도시되어 있다. 아키텍처(2300)는, 예를 들어, 다중요소 인증을 위해 사용될 수도 있는 위에서 설명된 OpenlD 식별자들 및 다른 사용자 속성들과 같은 다양한 사용자 정보를 포함할 수도 있는 사용자 DB(2302)를 포함한다. 아키텍처(2300)는 정책 정보 포인트(policy information point, PIP)(2306)라고도 또한 지칭될 수도 있는 정책 저장소(2306)와, 정책 결정 포인트(2304)라고도 또한 지칭될 수도 있는 정책 엔진(2304)을 더 포함할 수도 있다.
하나의 실시형태에서, PIP(2306)는 다양한 내부 또는 외부 엔티티들로부터 정보를 수집하는 정보 포인트의 소스로서 역할을 한다. OpenID 서브릿(2002)은 RP와의 정책 협상에 대한 정보를 PIP(2306)에게 피드(feed)하는 엔티티로서 역할을 할 수도 있다. 따라서, RP는 요청된 인증에 대해 사용자 디바이스 능력들을 식별할 수 있다. 결정을 하는 정책 엔진(2304)에 영향을 미치는 부가적인 엔티티들이 있을 수도 있다. 정책 엔진(2304)은 특정 사용자에 관해 또는 정책들에 관해 PIP(2306)로부터 관련 정보를 수집하는 의사 결정 포인트이다. 하나의 실시형태에서, 정책 엔진(2304)은 시행 정책들로 태스크가 주어지는 하나 이상의 정책 시행 포인트(policy enforcement point, PEP)들에게 정책 결정들을 게시한다. 예를 들어, MFO(1706)는 재시도 횟수, 신선도 체크들 등에 기초하여 정책들을 시행할 수 있는 PEP일 수도 있다.
이제 도 24를 참조하면, 예의 시스템(2400)이 스마트 OpenID에 기초하여 다중요소 인증을 구현한다. 도 24는 UE(102)의 일 예의 아키텍처를 도시한다. 2402에서, 예시된 실시형태에 따라, UE(102)는 RP(104)로부터 서비스를 요청한다. 2404에서, RP(104)는 OPSF(106)와 발견 및 연관을 수행한다. UE(102)는 2406 및 2408에서 OPSF(106)로 재지향된다. 2410에서, OPSF는 로컬 사용자 인증을 개시한다. 인증이 UE(102) 상에서 로컬 인증 에이전트들 중 하나를 사용하여 수행되고, 2412에서, 인증 결과가 브라우저(704)로 전송된다. 브라우저(704)는 2414에서 인증 결과를 OPSF(106)로 포워딩한다. OPSF(106)는 2416에서 인증 보증을 브라우저(704)로 제공한다. 2418에서, UE(102)는, 표명에 기초하여, RP(104)에 의해 제공된 서비스에 대한 액세스를 수신할 수 있다.
이제 도 25를 참조하면, 일 예의 다중요소 인증(2500)이 도시되어 있다. 그 애플리케이션이 안드로이드 애플리케이션으로서 예시되지만, 다중요소 애플리케이션은 대안적 플랫폼 상에서 원하는 대로 구현될 수도 있다는 것이 이해될 것이다. 애플리케이션(2500)은 주 활동(2502)에 의해 인증 요소들로서 착수될 수 있는 하나 이상의 활동들을 포함한다. 하나 이상의 활동들은 심 인증 활동(Sim Auth activity, 2504), 스마트 OpenID 활동(2506), 및 Biokey 활동(2508)을 포함한다. 활동들(2504, 2506, 및 2508)의 각각은 인증 요소 활동들이라고 또한 지칭될 수 있다. 인증 요소 활동들은 각각이 상태 애플리케이션(2510)에 대한 자신의 스테이터스를 업데이트할 수 있다. 스테이터스들의 예들은 인증을 포함하지만 인증되지 않는다. 예시된 실시형태들에 따라, 요소들의 각각이 디바이스의 인증을 위해 수행된 후, 제어는 도 25에 도시된 바와 같은 완료 활동에 주어진다. 이 완료 활동은 도 24에 도시된 바와 같이, 인증 결과를 OPSF(106)에게 전송할 수도 있다. 인증/완료 서브릿이 인증 결과를 수신한 다음 디바이스를 인증할 수도 있다.
이제 도 26a 내지 도 26c를 참조하면, 일 예의 인증 시스템(2600)은 사용자(2602), 웹키 클라이언트(2604), 브라우저 에이전트(2606), RP(2610), OP(2612), 및 패스워드 서버(PWD)(2614), 애플리케이션 서버(2616), 및 웹키 서버(2618)를 포함한다. 웹키 클라이언트(2604) 및 브라우저 에이전트(2606)는 사용자(2602)의 부분일 수도 있다. 사용자(2602), RP(2610), OP(2612), PWD(2614), 앱 서버(2616), 및 웹키 서버(2618)는 네트워크를 통해 서로 통신할 수도 있다.
또한 도 15 및 도 17를 대체로 참조하면, 패스워드 기반 사용자 인증은 FNX(1508)를 통해 지문 기반 식별 및 인증과 통합될 수도 있다. 예를 들어, 생체인식 NAE 커넥터(예컨대, 웹키(2604))는 FNX(1508)와 병치(co-location)될 수도 있다. FNX(1508)는 특정 사용자가 지원하는 인증 방법들을 저장하는 데이터베이스에 액세스할 수도 있다. 몇몇 경우들에서, 서비스 제공자(RP)가 OpenID PAPE 확장을 사용하여 자신의 원하는/요청된 인증 방법을 FNX(1508)에게 전달할 수 있다.
일 예의 실시형태에서, RP(2610)는 요청된 인증 정책에 관한 결정을 하는데, 예를 들어, RP(2610)는 자신이 제공하는 서비스에 대해 어떤 인증 강도가 요구되어야 하는지를 가장 잘 알 수도 있기 때문이다. RP(2610)는 이 요구된 정책을, 예를 들어, PAPE를 사용하여 FNX(1508)에게 전달할 수 있다. FNX(1508)는 당해 정책에 기초하여 그리고 사용자/UE(2602)의 능력들에 기초하여 인증을 실행할 수도 있다. 예로서, 표 5는 능력들 및 정책들의 일 예의 매핑을 보여준다. 표 5를 참조하면, 네 개의 상이한 인증 스크린들이 네 개의 상이한 결과들을 랜더링하지만, 임의의 수의 결과들이 원하는 대로 랜더링될 수 있다는 것이 이해될 것이다. 도시된 예에 따라, FNX(1508)는, 패스워드 인증이 필요한, 생체인식 인증이 필요한, 패스워드 및 생체인식 인증 양쪽 모두가 필요한, 또는 사용자(102)가 서비스에 액세스할 수 없는 정책 및 능력들을 결정할 수도 있다. 따라서, 패스워드를 요청하는, 지문을 요청하는, 패스워드 및 지문을 요청하는, 또는 서비스에 액세스할 수 없음을 사용자에게 알리는, UE(102) 상의 스크린이 디스플레이될 수도 있다(표 5 참고).
표 5
_
도 26a를 특히 참조하여, 2620에서, 예시된 실시형태에 따라, 사용자(2602)는 브라우저(2608)를 열며, RP 웹페이지(2610)에 방문하고, 자신의 OpenID 식별자(URL)를 OpenID 로그인 필드에 입력한다. 2622에서, RP(2610)는 로컬 정책 데이터베이스를 체크하고 생체인식 인증이 이 지정 사용자를 위해 요구된다고 결정한다. 2624에서, RP(2610)는 OpenID 발견 및 연관 단계들을 실행하고 OP(2612)로부터의 공유된 키를 연관의 결과로서 검색한다. 일 예의 실시형태에서, OP(2612)는 Yadis 발견을 위해 지원된 인증 정책들을 사용자의 XRDS 문서에 추가함으로써 발견 페이즈에서 특정 인증 정책들에 대한 지원을 알릴 수 있다. 2626에서, RP(2610)는 UE(2602)를 OP(2612)로 재지향함으로써 OpenID 인증 요청을 시작한다(간접 요청). RP(2610)는, 예를 들어 PAPE 확장을 사용하여, 현재 표명을 위한 인증 정책에 대한 자신의 선호도들을 기술하는 임의의 필요한 파라미터들을 포함할 수 있다. 예를 들어, RP(2610)는 자신이 패스워드 및 biokey 인증을 요구함을 표시할 수도 있다. 2628에서, UE 브라우저(2608)는 RP(2610)로부터 수신된 재지향을 추종하고 OP(2612)에게 요청을 발행한다. 일 예의 실시형태에서, 단계 2628 후 및 단계 2630 전, 정책 계층 및 다중요소 인증 계층은, 위에서 설명된 바와 같이 인증들을 트리거하는 임의의 필요한 인증 인터페이스들을 결정할 수도 있다. 이 예에서, 정책 계층은 BIOkey 및 패스워드 인증 양쪽 모두가 수행되어야 한다고 결정하고, 그 다음에 정책 계층은 인증 방법들 양쪽 모두를 실행하기 위해 다중요소 인증 계층을 트리거한다. 2630에서, OP(2612)사용자 데이터베이스라고 또한 지칭될 수 있는 PWD(2614)로 체크하여, 사용자가 DB 내에 존재하는지를 검증한다. 사용자가 데이터베이스 내에 존재한다면 OP(2612)는 진행할 수도 있다. 그렇지 않으면 OP는 PWD(2614)에 등록하기 위한 사용자에 대한 등록/가입 페이지(구현예의 경우 OOS)를 제시할 수도 있다. 2632에서, OP(2612)는, 패스워드에 대해 사용자에게 요청한다. 2634에서, 사용자는 패스워드를 입력하고 패스워드의 다이제스트가 OP(2612)로 다시 전송된다. 2636에서, OP(2612)는 수신된 패스워드를 검증하기 위해 수신된 패스워드 다이제스트를 패스워드 데이터베이스(2614)로 체크한다. 패스워드가 올바르다면, OP(2612)는 진행할 수도 있다. OP(2612)는 세션 식별자를 사용하여 내부적으로 현재 세션의 추적을 유지할 수도 있다.
특히 도 26b를 참조하면, 예시된 실시형태에 따라, 2638에서, OP(2612)는, 예를 들어 인증 요청으로부터의 사용자이름에 기초하여(단계 2626 참고), 필요한 키 및 식별자들을 검색하여, 앱 서버(2616)라고 일반적으로 지칭되는 BIOkey 생체인식 인증 서브시스템을 트리거할 수 있다. Biokey 기술은 상이한 식별자들을 내부적으로 사용할 수도 있으며 그래서 이 단계는 OP(2612)가 입력된 OpenID 사용자이름을 BIOkey 서브시스템 사용자이름에 매핑하는 것을 또한 포함할 수도 있다. 왕복 통신들이, 예를 들어 구현되는 BIOkey 기술에 기초하여, 2640 및 2642에서 발생할 수도 있다. 따라서, UE(2602) 상의 BIOkey 클라이언트는 OP(2612)에서 애플리케이션 서버(2616)로부터의 인증을 요청할 수도 있다. 2643에서, 위에서 설명된 바와 같은 OP(2612)의 컴포넌트일 수도 있는 BIOkey 애플리케이션 서버는, BIOkey 인증 요청을 BIOkey 웹키 서버(2618)로 발행한다. 이러한 요청은 애플리케이션 키(Ka)를 사용하여 암호화될 수도 있다. 2635에서, BIOkey 웹키 서버는 구성 데이터를 클라이언트 특정 키(Kc)로 암호화할 수도 있고 애플리케이션 키(Ka)를 사용하여 메시지를 암호화할 수도 있다. 예시된 실시형태에 따라, 암호화된 메시지는 애플리케이션 서버(2616)로 반환된다. 2644에서, 애플리케이션 서버(2616)는 사용자 디바이스(2602) 상의 BIOkey 클라이언트를 트리거하고 클라이언트 키(Kc)를 사용하여 암호화된 구성 데이터를 전송한다. 2646에서, UE(102) 상의 웹키 클라이언트(2604)는 지문 판독기 디바이스와 상호작용하여 지문 이미지를 스캔할 수도 있다. 2648에서, 웹키 클라이언트(2604)는 지문 데이터를 다시 애플리케이션 서버(2618)로 전송한다. 2650에서, 애플리케이션 서버(2616)는 수신된 지문 데이터를 웹키 서버(2618)로 포워딩한다.
도 26c를 특히 참조하면, 예시된 실시형태에 따라, 2652에서, 웹키 서버(2618)는 지문을 체크한 다음 성공적인 일치가 있을 때 성공 메시지로 애플리케이션 서버(2616)에 응답한다. 2654에서, 애플리케이션 서버(2616)는 성공 메시지를 OP(2612)로 포워딩한다. 몇몇 경우들에서, 표명을 생성하기 전, 위에서 설명된 정책 계층 및 다중요소 인증 계층은 인증이 성공했다고 결정할 수도 있고, 인증 결과들이 요구된 정책을 충족하기 때문에, OP(2612)는 서명된 표명 메시지를 생성하기 위해 진행할 수 있다. 2656에서, OP(2612)는 서명된 표명 메시지를 생성한다. 2658에서, OP(2612)는 UE(2602)를 다시 RP(2610)로 재지향시킨다. 2-요소 인증이 일어났음을 표명하는 서명된 표명은 이 재지향 메시지에 포함될 수 있다. 2660에서, UE(2602)는 RP(2610)로의 재지향을 추종한다. 2662에서, RP(2610)는 표명 메시지를 수신하고 단계 2624에서 확립된 공유된 키를 사용하여 표명 서명을 유효성 검사한다. 2664에서, 표명이 유효하다면, 사용자(2602)는 RP(2610)에서 인증되고 RP 서비스는 사용자(2602)에게 제공될 수 있다. 하나의 실시형태에서, 단계 2626 후, OP(2616)는 사용자가 패스워드 데이터베이스(2614) 내에 존재하는지를 체크한다. 만약 그렇다면, OP(2612)는 패스워드 기반 인증을 수행한다. OP(2612)는 패스워드 다이제스트를 검증하기 위해 패스워드 데이터베이스와 통신(상호작용)할 수도 있고, 패스워드가 올바르다면, OP(2612)는 2632에서 BIOkey 웹 클라이언트를 트리거할 수도 있다.
이제 도 27을 참조하면, 시스템(100a)은 도 1에 묘사된 시스템(100)과 유사하지만, 시스템(100a)은 UE(102)의 부분인 생체인식 인증 모듈(2704) 및 저장된 템플릿(2706)을 추가로 보여준다. 시스템(100a)에서의 UE(102)는 UE(102) 상에서 OpenID 기반 인증을 국소적으로 수행하도록 구성되는 모듈인 로컬 OP(2702)를 더 포함한다.
도 28a 및 도 28b를 참조하면, 일 예의 인증 시스템(2800)은 사용자(2802), VST-유사 기능 및 캐시로서 구성될 수도 있는 웹키 인증 클라이언트(2804), 스마트 OpenID(SOID) 클라이언트(2808), RP(2810), 및 IdP/OPSF(2812)를 포함한다. 일 예의 실시형태에서, SOID 클라이언트(2808) 및 웹키 클라이언트(2808), 및 웹키 인증 기능이 UE(2808) 상에 상주한다. 따라서, SOID 클라이언트(2808)는 도 27에서 참조되는 로컬 OP(2702)와 유사할 수도 있다. 2814에서, 예시된 실시형태에 따라, 사용자(2802)는, OpenlD-인식 클라이언트 또는 브라우저를 통해 사용자의 등록된 아이덴티티를 사용하여, SP(2810)라고 지칭될 수도 있는 RP(2810)에게 서비스를 요청한다. 2816에서, RP(2810)는 OID/OIDC 프로토콜을 준수하여 사용자의 아이덴티티와 연관되는 IdP(2812)와 발견 및 연관을 수행한다. 2818에서, 예시된 실시형태에 따라, 사용자(102)에 의해 요청된 사용자의 아이덴티티 및/또는 유형 서비스에 기초하여, RP(2810)는 다중요소 인증이 요구되는지를 결정한다. RP(2810)는 인증 요건을 충족하는 인증 요소들을 추가로 결정 또는 선택할 수도 있다. 2818에서, RP(2810)에서의 정책들에 기초하여, RP(2810)는 인증이 요청되는 요소들의 유형을 결정하고 요청된 요소들을 사용자/SOID 클라이언트(2802)에게 전달한다. 2820에서, 사용자 및 생체인식 인증들이 요구된다면, SOID(2808)는 로컬 사용자 인증을 개시한 다음 생체인식 인증을 트리거한다. 2822에서, 성공적인 로컬 사용자 인증 시, SOID(2808)는 웹-키 클라이언트(2806)에 대한 트리거(예컨대, API 호출)를 사용하여 생체인식 인증 요청을 개시한다.
도 28b를 특히 참조하여, 예시된 실시형태에 따라, 2824에서, 웹-키 클라이언트(2806)는 스마트 카드 내에서 보호될 수도 있는 국소적으로 저장된 캐시로부터 커맨드 데이터를 획득할 것을 요청한다. 2826에서, 커맨드 데이터는 캐시로부터 웹-키 클라이언트(2806)로 전송된다. 그 데이터는 OpenMobile API와 같은 메커니즘들을 사용하여 획득될 수도 있다. 2828에서, 커맨드 데이터를 사용하여, 웹-키 클라이언트(2806)는 사용자의 지문들을 스캔하는 프로세스를 개시할 것을 판독기/사용자(2802)에게 지시한다. 다양한 예의 요건들이 요구된 품질 및 번호의 손가락들을 포함한다. 스캐닝을 위해 사용되는 이러한 요건들은 커맨드 데이터의 부분일 수도 있거나, 또는 그것들은 RP(2810)로부터의 명령들에 기초하여 맞춤될 수도 있다. 2830에서, 스캐닝된 이미지는 판독기, 따라서 UE(2802)로부터 읽히고, 웹-키 클라이언트(2806)로 전송된다. 2832에서, 웹-키 클라이언트(2806)는 지문 모델을 웹-키 서버(2804)로 전송하여 사용자의 지문들을 인증(검증)할 것을 요청한다. 2834에서, 로컬 생체인식 인증이 성공이면, 웹-키(2804)는 표명을 연관된 보증 정보(예컨대, 이미지의 품질, 사용된 손가락 수 등) 및 연관된 신선도 정보와 함께 스마트 OID 클라이언트(2808)로 전송한다. 2836에서, 스마트 OID 클라이언트(2808)는 웹-키 클라이언트(2806)에 의해 제공된 정보 및 이전에 수행되었던 로컬 사용자 인증 정보를 사용하여 단일 표명을 생성한다. 2838에서, 스마트 OID 클라이언트(2808)는 결합된 표명을 RP(2810)로 전송하여서 사용자(2802)는 표명의 결과들에 기초하여 서비스에 대한 액세스를 획득할 수 있다.
이제 도 29a 내지 도 29d를 참조하면, 예의 시스템(2900)은 네트워크를 통해 서로 통신하는 사용자(2902) 및 UE(2901), 제 1 RP(2912), 마스터 IdP/MFAS(2916), 및 제 2 RP(1106)를 포함한다. 네트워크는 PWD 서버(2918) 및 웹-키 서버(2920)를 더 포함할 수도 있다. 사용자(2902)는 도 29a 내지 도 29d에서 "제인"이라고 지칭된다. UE(2901)는 로컬 바이오-키 클라이언트(2905) 및 브라우저(2910)를 포함할 수도 있다. 예의 시스템(2900)은 개시된 요지의 설명을 용이하게 하기 위해 단순화되고 본 개시물의 범위를 제한하도록 의도되지 않는다는 것이 이해될 것이다. 다른 디바이스들, 시스템들, 및 구성들이 시스템(2900)과 같은 시스템에 부가하여, 또는 그 대신에, 본원에 개시된 실시형태들을 구현하는데 사용될 수도 있고, 모든 이러한 실시형태들은 본 개시물의 범위 내인 것으로서 생각된다. 게다가, 제 1 RP(2912) 및 제 2 RP(2914)가 페이스북 및 뱅크 오브 아메리카로서 각각 묘사되지만, 이 묘사는 예의 목적들을 위한 것이고 제 1 및 제 2 RP들은 원하는 대로 임의의 적합한 서비스 제공자들일 수도 있다는 것이 이해될 것이다.
예시된 실시형태에 따라, 2922에서, 사용자(2902)는 제 1 RP(2912)에 연관된 사용자 식별자를 입력한다. 2924에서, 예시된 실시형태에 따라, 제 1 RP(2912)는, 예를 들어 RP(2912)의 정책에 기초하여, 사용자/UE가 RP(2912)에 의해 제공되는 요청된 서비스에 액세스하기 위하여 요구되는 보증 레벨(AL)을 결정한다. 2929에서, RP(2912)는 MFAS(2916)를 발견하고 MFAS(2916)와 연관시킨다. 2928에서, 예시된 실시형태에 따라, RP(2912)는 자신의 보증 레벨 요건을 브라우저(2910)에게 전달한다. 2930에서, 브라우저(2910)는 MFAS(2916)의 서비스들을 호출한다. 2930에서의 메시지는 요구된 보증 레벨을 포함할 수도 있다.
2932에서, 서비스에 액세스하기 위해 요구되는 보증 레벨에 기초하여, 예를 들어, MFAS(2916)는 요구된 보증 레벨을 달성하기 위해 수행될 수 있는 인증 요소들의 유형들 및 강도들을 결정한다. MFAS는 사용자 프로파일 DB(2929)로부터 사용자(2902) 및 UE(2901)에 연관된 정보(예컨대, 인증 능력들)를 검색할 수도 있다. 예에 따라, 2932에서, MFAS는 패스워드 인증만이 RP(2012)로부터의 서비스들에 액세스하기 위해 요구된다고 결정할 수도 있다. 2934에서, MFAS(2916)는 패스워드를 입력할 것을 사용자에게 프롬프트하는 HTTP 메시지를 사용자(2902)에게 전송함으로써 패스워드 인증을 트리거할 수도 있다. 2936에서, 사용자는 패스워드를 입력한다. 2938에서, MFAS(2916)는 패스워드 및 UID를 패스워드 인증을 위해 PWD 서버(2918)로 전송한다. PWD 서버(2918)는 사용자에 대한 입력된 패스워드가 사용자에 대한 저장된 패스워드와 일치함을 확인함으로써 패스워드 인증을 수행한다. 2940에서, PWD 서버(2918)는 패스워드들이 일치함을 MFAS(2916)에게 알린다. 이러한 메시지는 인증 결과라고 지칭될 수도 있다.
도 29b를 특히 참조하면, 예를 들어 제 1 표명과 같은 표명이 MFAS(2916)에 의해 생성되고 브라우저(2910)로 전송될 수도 있다. 브라우저(2910)는 그 표명을 RP(2912)로 전송할 수도 있고, RP(2912)는 2946에서 성공 메시지를 반환할 수도 있다. 따라서, 2948에서, 사용자는 RP(2912)에 의해 제공된 서비스에 액세스할 수도 있다.
도 29c를 특히 참조하면, 예시된 실시형태에 따라, 2950에서, 사용자(2902)는 사용자가 제 2 RP(2912)에 의해 제공된 서비스에 액세스할 수 있도록 제 2 RP(2912)에 연관된 사용자 식별자를 입력한다. 2924에서, 예시된 실시형태에 따라, 제 2 RP(2914)는, 예를 들어 RP(2914)의 정책에 기초하여, 사용자/UE가 RP(2914)에 의해 제공되는 요청된 서비스에 액세스하기 위하여 요구되는 보증 레벨(AL)을 결정한다. 2954에서, 예시된 실시형태에 따라, 제 2 RP(2914)는 자신의 보증 레벨 요건을 브라우저(2910)로 전달한다. 2956에서, 브라우저(2910)는 MFAS(2916)의 서비스들을 호출한다. 2956에서의 메시지는 요구된 보증 레벨을 포함할 수도 있다. 2958에서, 서비스에 액세스하기 위해 요구되는 보증 레벨에 기초하여, 예를 들어, MFAS(2916)는 요구된 보증 레벨을 달성하기 위해 수행될 수 있는 인증 요소들의 유형들 및 강도들을 결정한다. 이 결정은, 제 2 RP(2914)의 정책에 따라 리프레시될 수도 있는 위에서 설명된 과거의 패스워드 인증에 기초할 수도 있다. MFAS(2916)는 사용자 프로파일 DB(2929)로부터 사용자(2902) 및 UE(2901)에 연관된 정보(예컨대, 인증 능력들)를 검색할 수도 있다. 예에 따라, 2932에서, MFAS는 생체인식 인증이 제 2 RP(2014)로부터의 서비스들에 액세스하기 위해 요구된다고 결정할 수도 있다. 2969에서, MFAS(2916)는 메시지를 웹-키 서버(2920)로 전송함으로써 생체인식 인증을 개시할 수도 있다. 응답하여, 2962에서, 웹키 서버(2920)는 구성 데이터를 MFAS(2916)로 전송한다. 2964에서, MFAS(2916)는 HTTPS 메시지를 브라우저(2910)로 전송함으로써 생체인식 인증을 트리거한다. 2966에서, 브라우저(2910)는 클라이언트(2904)가 사용자(2902)에게 자신의 스캔된 지문을 가질 것을 프롬프트하도록 로컬 바이오-키 클라이언트(2904)를 호출한다. 따라서, 지문 모델이, 2968에서, 클라이언트(2904)에 의해 획득된다. 2970에서, 지문 모델은 브라우저(2910)로 전송된다. 2972에서, 지문 모델은 MFAS(2916)로 전송된다. 2974에서, MFAS(2916)는 지문 모델을 생체인식 인증을 위해 웹-키 서버(2920)로 전송한다. 서버(2920)는 사용자로부터의 수신된 지문 모델이 사용자의 저장된 지문과 일치함을 확인함으로써 생체인식 인증을 수행한다. 2976에서, 서버(2920)는 지문들이 일치함을 MFAS(2916)에게 알린다. 이러한 메시지는 인증 결과라고 지칭될 수도 있다. 2978에서, MFAS(2916)는 패스워드 인증 및 생체인식 인증으로부터의 인증 결과들에 기초하여 표명을 생성한다. 그 표명은 이전의 (신선한) 패스워드 인증 및 생체인식 인증의 보증 레벨을 포함하는 연관된 보증 레벨을 가질 수도 있다. 2980에서, 연관된 보증 레벨을 포함할 수도 있는 표명은, 브라우저(2910)로 전송된다. 2982 및 2984에서, 표명은 제 2 RP(2914)에게 표명되고, 성공 메시지는 제 2 RP(2914)로부터 브라우저(2910)로 전송된다. 따라서, 2986에서, 사용자/UE는 제 2 RP(2914)에 의해 제공되는 요청된 서비스에 액세스할 수 있다. 게다가, 신선한 인증 요소가 제 2 RP에 의해 제공되는 서비스에 액세스하기 위해 활용됨으로써, 효율적인 인증을 용이하게 한다.
이제 도 30a 내지 도 30d를 참조하면, 일 예의 시스템(3000)은 시스템(2900)에 의해 수행되는 다중요소 인증과 유사한 다중요소 인증을 수행한다. 도 30a 내지 도 30e는 동일한 RP가 상이한 서비스들을 제공하고 따라서 상이한 보증 레벨이 그 RP에 의해 제공된 상이한 서비스들에 액세스하기 위해 요구될 수도 있는 실시형태를 도시한다. 예를 들어, 도 30c를 참조하면, 2950에서, 사용자(2902)는, RP(2912)에 의해 제공된 제 1 서비스에 대한 액세스를 수신한 후(2948 참조), RP(2912)에 의해 제공된 제 2 서비스에 대한 액세스를 요청한다. 2952a에서, RP(2912)는, 예를 들어 정책에 기초하여, 이전에 획득된 것보다 높은 보증 레벨이 제 2 서비스에 액세스하기 위해 요구된다고 결정한다. 예를 들어, 제 2 서비스는 금전 거래를 포함할 수도 있는 반면, 제 1 서비스는 웹페이지에 대한 액세스만을 포함할 수도 있다. 제 2 서비스가 보안 관점에서 제 1 서비스보다 더욱 민감할 수도 있기 때문에, 더 높은 보증 레벨이 제 2 서비스를 위해 요구될 수도 있다. 따라서, 도 30c 내지 도 30e를 참조하면, 사용자가 RP(2912)의 제 1 서비스에 이미 액세스했더라도, 사용자(102)는 RP(2912)의 제 2 서비스를 평가하기 위해 생체인식 인증을 받는다. 도 30a 내지 도 30d에 묘사된 예 실시형태는 원하는 대로 임의의 수의 신뢰 당사자들을 사용하여 구현될 수 있다는 것이 이해될 것이다.
일 예의 실시형태에서, URI의 URL 부분에서의 로케이션 정보는 특정 인증 요소를 트리거하는데 사용된다. 일 예의 URL은 다음을 포함한다:
soid. scheme://simple.password/?salted-digest=<SALTED_DIGEST_VALUE>,salt=<SALT_VALUE>
soid.scheme://biometric.fingerprint-biokey/...
위의 예에서, 패스워드 기반 인증이 생체인식 인증에 의해 트리거된다.
타임스탬프를 포함하는 인증 표명을 갖는 2-요소(패스워드 및 생체인식) 인증을 위한 OpenID AX 쿼리 응답의 일 예가 다음을 포함할 수도 있다: openid.ax.mode=fetch_response
openid.ax.type.mauthitem=http://multi-factor.org/schema/multi-auth-listing
openid.ax.type.mauth_signed=http://multi-factor.org/schema/generic-signed
openid.ax.value.name=John Doe
openid.ax.type.auth_time=http://multi-factor.org/schema/timestamp
openid.ax.type.auth_time=2013-04-31Τ15:07:38.6875000-05:00
openid.ax.count.mauth=2
openid.ax.value.mauth.1=password
openid.ax.value.mauth.2=biometric.BIO-Key
openid.ax.value.mauth_sig=iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyb1AAAHE1EQVQI12P4==
위에서 도시된 바와 같이, 페치 요청에 대한 응답은 수행된 두 개의 인증들의 리스트를 포함할 수도 있다. 예를 들어 서명 속성 라인을 제외한 전체 응답은, OP에 의해 서명될 수도 있다. 서명은 동일한 서명 키를 사용하여 그것을 서명함으로써 원래의 OpenID 표명에 바인딩될 수도 있다. 이는 RP가 응답을 즉시 검증하는 것을 또한 허용할 수도 있다.
일 예의 실시형태에서, 인증 요소들은, 가장 약한 인증 요소로 시작하는 순차적 순서로 루프화된다.
MFAS는, 위에서 설명된 바와 같이, 인증 보증에 대한 다수의 상이한 요건들을 갖는 서비스 제공자들에 대한 인증 정책들의 이음매 없는 구현예를 허용할 수도 있다. 예를 들어, 서비스 제공자들은 그들이 제공하는 상이한 서비스들에 기초한 상이한 인증 요건들을 갖는다. 예로서, 전자 상거래 사이트들(예컨대, 아마존)이 웹사이트에 로그인하기 위한 제 1 인증 요건(사용자이름/패스워드) 과, 상품을 구매하기 위한 제 2 인증 요건(생체인식)을 가질 수도 있다. 현재 체크아웃하는 접근법들은 불완전하다. 예를 들어, 종종 사용자이름들 및 패스워드들이 체크아웃에서 단순히 재입력되는데, 이는, 이를테면 브라우저들 내에 저장되어 있는 크리덴셜들에 대해 다양한 이유들로 보안 취약점들을 유발할 수도 있다. 위에서 설명된 MFAS의 일 예의 실시형태에 따라, 사용자가 쇼핑 사이트를 방문하며, 카탈로그를 훑어보고, 아이템들을 쇼핑 카트에 추가할 수도 있다. 체크아웃에 도달할 때, 쇼핑 사이트 페이지는 체크아웃에 대한 특정 인증 정책을 사용하는 MFAS를 사용하여 로그인을 트리거할 수도 있다.
이 예의 시나리오는, 서비스 제공자 인테그레이션을 느슨하게 커플링된 채로 유지하면서도, 지불 정보를 관리하고 지불들을 허가하는 MFAS의 유연성을 또한 입증할 수도 있다.. 동일한 신뢰성 있는/알려진 인터페이스를 사용자에게 제시함으로써, 사용자는 자신의 지불들이 보안성있게 진행될 것을 보장받을 수 있고 상점으로부터 상품을 구매할 가능성이 높다. 상점은 지불 프로세스에서 사용자와, MFAS를 동작시킬 수도 있는 모바일 네트워크 오퍼레이터(MNO) 간의 현존 결제 관계를 활용한다. 모바일 네트워크 오퍼레이터는 상점들이 가입자 베이스에 액세스하는 방법을 제공하고 사용자들이 쉽게 참여하는 간소화된(streamlined) 지불 방법 및 프로세스를 제공할 수 있다. MNO의 그것의 가입자들과의 현존 결제 관계는 활용될 수 있고 전자상거래 플랫폼들과 같은 비 MNO 운영식 서비스들로 확장될 수 있다. 다음의 표는 위에서 설명된 예의 시나리오로부터 생겨날 수도 있는 몇몇 예의 장점들을 도시한다.
사용자서비스(전자상거래)MNO장점들_ MNO가 지불을 처리한다면 서비스에 대한 더 높은 프라이버시
_ 간소화된 지불 프로세스로 인한 더 높은 사용자 만족
_ 서비스 보안, 피싱 방지에서 더 높은 신뢰
_ 증가된 보안으로 더 쉽고 더 빠른 체크아웃
_ 신뢰성 있는 지불 프로세싱으로 인한 증가된 고객 충성도
_ 사용 편의, 매번 유사한 지불 모드를 사용할 수 있음(특정 서비스들에 대해 페이팔 계정 및 비자카드를 지녀야 할 것을 걱정하지 않음)_ 단순화된 서명 및 지불 프로세스로 인한 더 높은 전환율(사이트 방문자 대 구매자)
_ 지불(own payment) 인프라스트럭처를 구현할 필요 없음
_ 지불 프로세스에서 더 높은 보안 및 더 높은 사용자 인증 레벨
_ MNO로부터의 검증된 지불 정보로 인한 사기 방지
_ MNO와의 제휴로 고객 선호도 데이터에 액세스할 기회_ 현존 데이터의 화폐화(monetization)(검증된 지불 및 연락처/배송 데이터) 및 인프라스트럭처, 예컨대, 현존 결제 인프라스트럭처의 재사용
_ '신뢰 앵커(trust anchor)' 및 '지불 보안 제공자'로서의 서비스들 및 사용자들에 대한 더 높은 지명도(visibility)
_ 긍정적인 브랜딩/마케팅 효과, 공동 브랜딩에 대한 기회
_ MNO 체크아웃/인증 서비스 사용량에 대한 사용자들 또는 웹 서비스들의 과금에 의한 증가된 매출
_ 서비스들에 대한 중심적 지불 프로세싱 엔티티로서 서비스할 수 있음
_ 서비스들에 대한 파트너십 관계를 위한 기회다른 예로서, 사용자가 예를 들어 소셜 네트워킹 사이트와 같은 제 1 사이트로 브라우즈할 수도 있는데, 그러한 제 1 사이트에서 사용자는 자신의 MNO에 의해 제공된 MFAS 로그인을 사용하여, 예를 들어 자신의 패스워드와 같은 자신의 보통의 크리덴셜로 로그인한다. 당해 사이트 상의 얼마간의 활동 후, 사용자는 예를 들어 아마존과 같은 전자상거래 사이트에서 얼마간의 쇼핑을 하기 위해 이동할 것을 결정한다. 거기서, 사용자는 자신의 MNO에 의해 제공된 MFAS 서비스들을 사용하여 로그인하기 위한 (소셜 네트워킹 사이트 상에서와 같은) 옵션을 제시받는다. 전자상거래 사이트 및 MFAS 간에 합의된 인증 정책은 소셜 네트워킹 사이트와의 이전의 인증을, 그것이 충분히 신선하다는 것을 전제로, 크리덴셜로서 사용하는 것을 허용할 수도 있다. 따라서, 사용자가 전자상거래 사이트에 연관되는 자신의 ID를 입력한 후(브라우저 기능들 또는 플러그인들에 의해 종종 자동화된 단계), MNO의 MFAS 시스템은 대응 정책을 발견하며, 소셜 네트워크 사이트와의 이전의 인증 요소의 신선도를 체크하고, 성공인 경우, 성공적 인증을 전자상거래 사이트에 표명할 수도 있다. 사용자는 그 다음에 자신을 위한 몇몇 쇼핑 권장사항들을 보여주는 자신의 개인 로그인 페이지로 이음매 없이 이동된다.
이 예를 계속하여, 사용자는 자신의 쇼핑 바구니를 채우고 특정한 포인트에서 그 쇼핑 바구니 내의 상품을 구매할 것을 결정할 수도 있다. 그는 '체크아웃으로 진행' 버튼을 누른다. 체크아웃에 대한 전자 상거래 사이트의 정책은 전자상거래 사이트에 대한 로그인을 위해 사용된 것보다 더 강한 요소를 사용하는 별도의 인증을 요구할 수도 있다. 예를 들면, 체크아웃은 진정한 2-요소 인증으로서 폰 SIM 카드 더하기 사용자에 의한 생체인식 인증을 사용한 오퍼레이터 기반 인증을 요구할 수도 있다. 적어도 생체인식 인증은 신선할 것임(즉, 생체인식 요소를 사용한 이전의 사용자 인증이 유효한 것으로 간주되지 않음)이 또한 요구될 수 있다. SIM 카드를 사용한 제 1 요소 인증이 사용자 디바이스 및 오퍼레이터 MFAS 시스템 간의 백그라운드에서 진행하지만, 생체인식 요소는 명시적 사용자 상호작용을 요구하며, 예컨대, 사용자는 자신의 손가락을 폰의 지문 센서 상에서 스위핑해야 한다.
오퍼레이터 MFAS가 전자 상거래 사이트의 체크아웃에 대한 정책에 따라 성공적인 결합된 인증을 표명한 후, 사용자는 자신의 배송 및/또는 지불 세부사항들을 자신이 확인/선택/편집할 수도 있는 보통의 체크아웃 페이지로 이동된다. 위에서 설명된 MFAS 실시형태들을 사용하여, 이러한 사용자 세부사항들은 MFAS 또는 클라이언트 디바이스로부터 쇼핑 사이트로 애드 혹으로 전송될 수도 있다.
전자상거래 로그인 사이트 및 전자 상거래 체크아웃 사이트 간의 인증 정책들의 구별은 각각 amazon.com/login 또는 checkout.amazon.com과 같은 서브도메인 이름들 또는 사이트 URL들을 사용함으로써 유효해질 수 있다. 이들 URL들의 각각에 대해, 단일 사용자가 동일한 또는 상이한 서비스들에 액세스하기 위해 다수의 디바이스들을 소유 및 사용할 가능성이 매우 높다. 모든 디바이스들이 동일한 인증 능력들을 나타내는 것이 아닐 수도 있다. 그러나, 동일한 사용자 및 동일한 사용자 식별자는 서비스를 대신하여 FNX에 의해 인증될 수도 있다. 그러므로, FNX는 다수의 디바이스들을 단일 사용자에게 등록 및 매핑하기 위해 위에서 설명된 메커니즘들을 지원하고, FNX는 상이한 디바이스들로부터 결합될 인증을 지원할 수 있다. 예시의 목적을 위해 제시된 일 예의 시나리오에서, 사용자가 자신의 랩톱 상에서 자신의 전자금융(eBanking) 웹사이트를 브라우즈할 수도 있다. 그 웹사이트에 로그인하기 위하여, 그 웹사이트는 FNX로부터 생체인식 인증을 요청한다. FNX는 그러면 사용자의 랩톱과의 생체인식 인증을 트리거한다. 사용자가 자신의 지문을 스캔한 후, FNX는 은행업무 웹사이트를 향해 필요한 표명을 생성하고, 액세스는 권한 부여된다. 사용자가 다음으로 거래를 하기 원할 때, 은행업무 웹사이트는 FNX로부터 생체인식 더하기 SMS 인증을 요청할 수도 있다. FNX는 그 요청을 평가하고 사용자의 등록된 스마트폰으로부터 SMS가 가능함을 검출할 수도 있다. FNX는 SMS를 사용자의 폰으로 전송하기 위해 필요한 NAE 커넥터들을 트리거할 수도 있다. 사용자는 SMS 인증을 완료하기 위해 당해 SMS를 FNX로 다시 전송한다. 정책들에 따르면, 마지막 생체인식 인증은 사용자가 로그인할 때 바로 일어나므로, FNX는 생체인식 요소를 재인증할 필요가 없을 수도 있다. 예를 들어, FNX는 두 개의 인증들에 대한 결합된 표명에 신선도 문(statement)을 대신 추가할 수도 있다. 은행 거래는 그 뒤에 수행될 수도 있다. 위의 예의 시나리오에서, 서비스가 자신 소유의 생체인식 및 SMS 인증 인프라스트럭처를 구현하는 일 없이 이음매 없고 통합된 방식으로 인증을 실행할 수 있다는 것은 FNX에 의한 인증 요소들 양쪽 모두의 지식을 통해서이다.
위의 예의 시나리오를 가능하게 하기 위하여, FNX는, 디바이스 등록 동안 사용자가 소유하는 각각의 디바이스를 구성하는데 사용될 수도 있는 부가적인 디바이스 커넥터를 가질 수도 있다. 등록 프로토콜의 부분으로서, 하나의 실시형태에 따라, 사용자는 이 디바이스를 FNX에 등록하고, 그 디바이스 특정 능력들을 FNX 매핑에 추가한다. 로컬 FNX의 경우, 로컬 FNX는 로컬 디바이스의 디바이스 능력들에 관해서만 알 수도 잇다. 그러나, 네트워크 FNX는 디바이스 정보를 사용자의 모든 로컬 FNX 인스턴스들로 배포할 수도 있어서, 예를 들어, 모바일 폰 로컬 FNX는 자신이 사용자의 랩톱 상에서 생체인식 인증을 트리거할 수 있다는 것을 안다. 예를 들어, 디바이스 능력들을 포함하는 정책은 MFAS에서의 대응 사용자 프로파일에 저장될 수도 있다.
이제 도 31을 참조하면, 예의 아키텍처(3200)는 FIDO를 소개하는 아키텍처들 및 위에서 설명된 MFAS 기능들이 서로 협동할 수도 있는 방법의 일 예를 도시한다.
도 31에 도시된 FIDO 사용자 디바이스는 FIDO 인증을 하기 위한 필요한 컴포넌트들을 갖는 디바이스들을 말하는 FIDO-가능 사용자 디바이스를 지칭한다. 일 예의 실시형태에서, FIDO-가능 사용자 디바이스는 다중요소 인증에서의 인증 요소들의 하나로서의 FIDO 인증기의 사용을 가능하게 하는 부가적인 다중요소 인증 계층을 또한 갖는다. FIDO 아키텍처의 부분으로서, 일 예의 FIDO 사용자 디바이스는 FIDO 클라이언트, 인증 추상화 계층, 및 FIDO 인증기들로 이루어진다.
FIDO 클라이언트가 implements FIDO 프로토콜들의 클라이언트 측을 구현하고 FIDO 인증기 API를 통해 FIDO 인증기 추상화 계층과 인터페이싱한다. FIDO 인증기 추상화 계층은 인증기 기반 암호 서비스들의 이용을 가능하게 하는 균일한 API를 상위(upper) 계층들에 제공한다. 그것은 다중 벤더 인증기들 및 그것들의 필수 드라이버들의 채용을 용이하게 하는 균일한 하위(lower)-계층 "인증기 플러그인" API를 제공한다.
FIDO 인증기는 FIDO 사용자 디바이스들에 부착되는 또는 그것들 내에 수용되는 보안 엔티티일 수도 있다. 신뢰 당사자들에 의해 키 재료를 원격으로 준비하는 것이 가능할 수도 있고, 그러면 암호적으로 강한 인증 프로토콜들에 참여할 수 있다. 예를 들어, FIDO 인증기는 키 재료에 기초하여 암호화 챌린지 응답을 제공할 수도 있고 따라서 그것 자체를 인증할 수도 있다.
디바이스 측에서, 예를 들어, FIDO 사용자 디바이스는 위에서 설명된 MFAP를 수용할 수도 있고, 그 MFAP는 위에서 설명된 MFAS와 상호작용하고 따라서 다중요소 인증에서의 인증 요소들 중 하나로서의 FIDO의 사용을 가능하게 한다. MFAP는 두 단계 로컬 인증(들)의 바인딩(암호화 또는 다른 수단)을 용이하게 할 수도 있는데, 두 단계 로컬 인증(들)은 네트워크의 인증 프로토콜로, FIDO 인증기(들)에 의해 통상 수행된다. MFAP는 인증 요소들의 신선도 양태들과 전체 다중요소 인증 및 가변 등급 인증 보증을 도출하는 정책들을 포함하는, MFAaaS 서비스의 충만도를 고려할 수도 있다.
일 예의 실시형태에서, MFAaaS 서비스는 MFAS의 제어를 가질 수도 있고 FIDO 서버 및 FIDO 검정 서비스를 또한 가질 수도 있거나, 또는 이들 FIDO 컴포넌트들에 대한 외부 접속이 준비될 수도 있다. FIDO 서버는 다양한 기능들을 가질 수도 있다. 예를 들어, FIDO 서버는 FIDO 인증기 검정들을 유효성 검사하기 위해 FIDO 검정 서비스와 통신하는 FIDO 프로토콜들의 서버 부분을 구현하고, FIDO 인증기 데이터를 업데이트하기 위해 FIDO 검정 서비스와 통신할 수도 있다. FIDO 인증 서비스는 FIDO 인증기들 및 FIDO 서버 간의 루프를 닫기 위해 사용될 수도 있다. FIDO 인증 서비스의 책무들은, 예를 들어, FIDO 인증기들을 보증하는 것, FIDO 인증기 검증들을 유효성 검사하는 것, 및 FIDO 인증기들의 폐기 데이터를 FIDO 서버에게 제공하는 것을 포함할 수도 있다.
일 예의 실시형태에 따라, 위에서 설명된 MFAS에서, FIDO 요소를 위한 인증 모듈이 추가된다. 이 모듈이 호출될 때, 그 모듈은 FIDO 인증기에 기초하여 로컬 인증을 하도록 MFAP에게 지시할 수도 있다. 이 인증은 by FIDO 서버에 의해 검정 서비스를 사용하여 유효성 검사될 수 있다. 따라서, FIDO 인증 아키텍처는, 일 예의 실시형태에 따라, 상이한 유형들의 네트워크 및 로컬 인증 벡터들이 다양한 신뢰 당사자들에 대한 인증을 위해 상이한 소망의 방식들로 결합될 수도 있는 MFAaaS와 연계하여 작업하도록 수정될 수도 있다.
도 32a는 하나 이상의 개시된 실시형태들이 구현될 수도 있는 일 예의 통신 시스템(50)의 도면이다. 통신 시스템(50)은 콘텐츠, 이를테면 음성, 데이터, 비디오, 메시징, 브로드캐스트 등을 다수의 무선 사용자들에게 제공하는 다중 액세스 시스템일 수도 있다. 통신 시스템(50)은 다수의 무선 사용자들이 무선 대역폭을 포함한 시스템 자원들의 공유를 통해 이러한 콘텐츠에 액세스하는 것을 가능하게 할 수도 있다. 예를 들어, 통신 시스템들(50)은 하나 이상의 채널 액세스 방법들, 이를테면 코드 분할 다중 접속(code division multiple access, CDMA), 시분할 다중 접속(time division multiple access, TDMA), 주파수 분할 다중 접속(frequency division multiple access, FDMA), 직교 FDMA(OFDMA), 단일 반송파 FDMA(SC-FDMA) 등을 채용할 수도 있다.
도 32a에 도시된 바와 같이, 통신 시스템(50)은 무선 송수신 유닛들(WTRU들)(52a, 52b, 52c, 52d), 무선 액세스 네트워크(radio access network, RAN)(54), 코어 네트워크(56), 공중전화망(public switched telephone network, PSTN)(58), 인터넷(60), 및 다른 네트워크들(62)을 포함할 수도 있지만, 개시된 실시형태들은 임의의 수의 WTRU들, 기지국들, 네트워크들, 및/또는 네트워크 엘리먼트들에 생각이 이르고 있다는 것이 이해될 것이다. WTRU들(52a, 52b, 52c, 52d)의 각각은 무선 환경에서 동작 및/또는 통신하도록 구성된 임의의 유형의 디바이스일 수도 있다. 예로서, WTRU들(52a, 52b, 52c, 52d)은 무선 신호들을 송신 및/또는 수신하도록 구성될 수도 있고 사용자 장비(UE), 이동국, 고정식 또는 모바일 가입자 유닛, 페이저, 셀룰러 전화기, 개인 정보 단말기(personal digital assistant, PDA), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 소비자 가전기기들 등을 포함할 수도 있다.
통신 시스템들(50)은 기지국(64a)과 기지국(64b)을 또한 포함할 수도 있다. 기지국들(64a, 64b)의 각각은 하나 이상의 통신 네트워크들, 이를테면 코어 네트워크(56), 인터넷(60), 및/또는 네트워크들(62)에 대한 액세스를 용이하게 하기 위해 WTRU들(52a, 52b, 52c, 52d) 중 적어도 하나와 무선으로 인터페이싱하도록 구성된 임의의 유형의 디바이스일 수도 있다. 예로서, 기지국들(64a, 64b)은 기지국 트랜시버(base transceiver station; BTS), 노드-B, eNode B, 홈 노드 B, 홈 eNode B, 사이트 제어기, 액세스 포인트(AP), 무선 라우터 등일 수도 있다. 기지국들(64a, 64b)이 각각 단일 엘리먼트로서 묘사되지만, 기지국들(64a, 64b)은 임의의 수의 상호접속된 기지국들 및/또는 네트워크 엘리먼트들을 포함할 수도 있다.
기지국(64a)은 RAN(54)의 일부일 수도 있는데, 이 RAN은 다른 기지국들 및/또는 네트워크 엘리먼트들(미도시), 이를테면 기지국 제어기(base station controller, BSC), 무선 네트워크 제어기(radio network controller, RNC), 릴레이 노드들 등을 또한 포함할 수도 있다. 기지국(64a) 및/또는 기지국(64b)은 셀(미도시)이라고 지칭될 수도 있는 특정 지리적 지역 내에서 무선 신호들을 송신 및/또는 수신하도록 구성될 수도 있다. 그 셀은 셀 섹터들로 더욱 세분될 수도 있다. 예를 들어, 기지국(64a)에 연관된 셀은 3 개의 섹터들로 나누어질 수도 있다. 따라서, 일 실시형태에서, 기지국(64a)은 3 개의 트랜시버들을, 즉, 셀의 각각의 섹터마다 하나씩 포함할 수도 있다. 일 실시형태에서, 기지국(64a)은 다중 입력 다중 출력(multiple-input multiple output, MIMO) 기술을 채용할 수도 있고, 그러므로, 셀의 각각의 섹터에 대해 다수의 트랜시버들을 이용할 수도 있다.
기지국들(64a, 64b)은 에어 인터페이스(66)를 통해 WTRU들(52a, 52b, 52c, 52d) 중 하나 이상과 통신할 수도 있는데, 에어 인터페이스는 임의의 적합한 무선 통신 링크(예컨대, 무선 주파수(radio frequency, RF), 마이크로파, 적외선(infrared, IR), 자외선(ultraviolet, UV), 가시광선 등)일 수도 있다. 에어 인터페이스(66)는 임의의 적합한 무선 접속 기술(radio access technology, RAT)을 사용하여 확립될 수도 있다.
더 구체적으로는, 위에서 언급했듯이, 통신 시스템(50)은 다중 액세스 시스템일 수도 있고, 하나 이상의 채널 액세스 체계들, 이를테면 CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등을 채용할 수도 있다. 예를 들어, RAN(54)에서의 기지국(64a)과 WTRU들(52a, 52b, 52c)은 범용 이동 통신 시스템(Universal Mobile Telecommunications System, UMTS) 지상파 라디오 액세스(Terrestrial Radio Access, UTRA)와 같은 라디오 기술을 구현할 수도 있는데, 이 라디오 기술은 광대역 CDMA(WCDMA)를 사용하여 에어 인터페이스(66)를 확립할 수도 있다. WCDMA는 고속 패킷 액세스(High-Speed Packet Access, HSPA) 및/또는 진화형 HSPA(HSPA+)와 같은 통신 프로토콜들을 포함할 수도 있다. HSPA는 고속 다운링크 패킷 액세스(High-Speed Downlink Packet Access, HSDPA) 및/또는 고속 업링크 패킷 액세스(HSUPA)를 포함할 수도 있다.
일 실시형태에서, 기지국(64a)과 WTRU들(52a, 52b, 52c)은 진화형 UMTS 지상파 라디오 액세스(Evolved UMTS Terrestrial Radio Access, E-UTRA)와 같은 라디오 기술을 구현할 수도 있는데, 이 라디오 기술은 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 에어 인터페이스(66)를 확립할 수도 있다.
다른 실시형태들에서, 기지국(64a)과 WTRU들(52a, 52b, 52c)은 IEEE 802.16(즉, WiMAX(Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, 잠정 표준 2000(IS-2000), 잠정 표준 95(IS-95), 잠정 표준 856(IS-856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GSM EDGE(GERAN) 등과 같은 라디오 기술들을 구현할 수도 있다.
도 32a에서의 기지국(64b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 펨토 셀 기지국, 또는 액세스 포인트일 수도 있고, 국소화된 영역, 이를테면 사업장, 홈, 차량, 캠퍼스 등에서 무선 접속을 용이하게 하기 위해 임의의 적합한 RAT를 이용할 수도 있다. 일 실시형태에서, 기지국(64b)과 WTRU들(52c, 52d)은 무선 로컬 영역 네트워크(wireless local area network, WLAN)를 확립하기 위해 IEEE 802.11과 같은 라디오 기술을 구현할 수도 있다. 일 실시형태에서, 기지국(64b)과 WTRU들(52c, 52d)은 무선 개인 영역 네트워크(wireless personal area network, WPAN)를 확립하기 위해 IEEE 802.15와 같은 라디오 기술을 구현할 수도 있다. 또 다른 실시형태에서, 기지국(64b)과 WTRU들(52c, 52d)은 피코셀 또는 펨토셀을 확립하기 위해 셀룰러 기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수도 있다. 도 32a에 도시된 바와 같이, 기지국(64b)은 인터넷(60)에 대한 직접 접속을 가질 수도 있다. 따라서, 기지국(64b)은 코어 네트워크(56)를 통해 인터넷(60)에 액세스하는 것이 필요하지 않을 수도 있다.
RAN(54)은 코어 네트워크(56)와 통신할 수도 있는데, 이 코어 네트워크는 음성, 데이터, 애플리케이션들, 및/또는 VoIP(voice over internet protocol) 서비스들을 WTRU들(52a, 52b, 52c, 52d) 중 하나 이상에게 제공하도록 구성된 임의의 유형의 네트워크일 수도 있다. 예를 들어, 코어 네트워크(56)는 호출 제어, 빌링 서비스들, 모바일 로케이션 기반 서비스들, 선불 전화, 인터넷 접속성, 비디오 분배 등을 제공하며 그리고/또는 하이-레벨 보안 기능들, 이를테면 사용자 인증을 수행할 수도 있다. 도 32a에 도시되진 않았지만, RAN(54) 및/또는 코어 네트워크(56)는 RAN(54)과는 동일한 RAT 또는 상이한 RAT를 채용하는 다른 RAN들과 직접 또는 간접 통신할 수도 있다는 것이 이해될 것이다. 예를 들어, E-UTRA 라디오 기술을 이용하고 있을 수도 있는 RAN(54)에 접속되는 것 외에도, 코어 네트워크(56)는 GSM 라디오 기술을 채용하는 다른 RAN(미도시)과 또한 통신할 수도 있다.
코어 네트워크(56)는 PSTN(58), 인터넷(60), 및/또는 다른 네트워크들(62)에 액세스하기 위한 WTRU들(52a, 52b, 52c, 52d)에 대한 게이트웨이로서 또한 역할을 할 수도 있다. PSTN(58)은 기존 전화 서비스(plain old telephone service, POTS)를 제공하는 회선 교환식 전화기 네트워크들을 포함할 수도 있다. 인터넷(60)은 공통 통신 프로토콜들, 이를테면 TCP/IP 인터넷 프로토콜 스위트에서의 송신 제어 프로토콜(transmission control protocol, TCP), 사용자 데이터그램 프로토콜(user datagram protocol, UDP) 및 인터넷 프로토콜(internet protocol, IP)을 사용하는 상호접속된 컴퓨터 네트워크들 및 디바이스들의 글로벌 시스템을 포함할 수도 있다. 네트워크들(62)은 다른 서비스 제공자들에 의해 소유된 및/또는 동작되는 유선 또는 무선 통신 네트워크들을 포함할 수도 있다. 예를 들어, 네트워크들(62)은 하나 이상의 RAN들에 접속된 다른 코어 네트워크를 포함할 수도 있는데, 이 하나 이상의 RAN들은 RAN(54)과는 동일한 RAT 또는 상이한 RAT를 채용할 수도 있다.
통신 시스템(800)에서의 WTRU들(52a, 52b, 52c, 52d) 중 일부 또는 전부는 다중-모드 능력들을 구비할 수도 있으며, 즉, WTRU들(52a, 52b, 52c, 52d)은 상이한 무선 링크들을 통해 상이한 무선 네트워크들과 통신하기 위해 다수의 트랜시버들을 구비할 수도 있다. 예를 들어, 도 32a에 도시된 WTRU(52c)는 셀룰러 기반 라디오 기술을 채용할 수도 있는 기지국(64a)과 그리고 IEEE 802 라디오 기술을 채용할 수도 있는 기지국(64b)과 통신하도록 구성될 수도 있다.
도 32b는 일 예의 WTRU(52)의 시스템도이다. 도 32b에 도시된 바와 같이, WTRU(52)는 프로세서(68), 트랜시버(70), 송수신 엘리먼트(72), 스피커/마이크로폰(74), 키패드(76), 디스플레이/터치패드(78), 비-착탈식 메모리(80), 착탈식 메모리(82), 전력원(84), 글로벌 포지셔닝 시스템(global positioning system, GPS) 칩셋(86), 및 다른 주변기기들(88)을 포함할 수도 있다. WTRU(52)는 전술한 엘리먼트들의 임의의 하위조합을 포함하면서도 일 실시형태와 일치하게 유지할 수도 있다는 것이 이해될 것이다.
프로세서(68)는 범용 프로세서, 특수 목적 프로세서, 기존의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서들, DSP 코어에 연관된 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, 주문형 집적회로들(ASIC들), 필드 프로그램가능 게이트 어레이(FPGA) 회로들, 임의의 다른 유형의 집적회로(IC), 상태 기계 등일 수도 있다. 프로세서(68)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입출력 프로세싱, 및/또는 WTRU(52)가 무선 환경에서 동작하는 것을 가능하게 하는 임의의 다른 기능을 수행할 수도 있다. 프로세서(68)는 트랜시버(70)에 커플링될 수도 있는데, 그 트랜시버는 송수신 엘리먼트(72)에 커플링될 수도 있다. 도 32b가 프로세서(68)와 트랜시버(70)를 별개의 컴포넌트들로서 묘사하지만, 프로세서(68)와 트랜시버(70)는 전자 패키지 또는 칩 내에 함께 통합될 수도 있다는 것이 이해될 것이다. 프로세서(68)는 애플리케이션-계층 프로그램들(예컨대, 브라우저들) 및/또는 라디오 액세스-계층(RAN) 프로그램들 및/또는 통신들을 수행할 수도 있다. 프로세서(68)는 예를 들어 액세스-계층 및/또는 애플리케이션 계층에서 인증, 보안 키 협약, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수도 있다.
송수신 엘리먼트(72)는 에어 인터페이스(66)를 통해 신호들을 기지국(예컨대, 기지국 64a)으로 송신하거나 또는 그 기지국으로부터 신호들을 수신하도록 구성될 수도 있다. 예를 들어, 하나의 실시형태에서, 송수신 엘리먼트(72)는 RF 신호들을 송신 및/또는 수신하도록 구성된 안테나일 수도 있다. 일 실시형태에서, 송수신 엘리먼트(72)는, 예를 들어, IR, UV, 또는 가시광선 신호들을 송신 및/또는 수신하도록 구성된 송출기(emitter)/검출기일 수도 있다. 또 다른 실시형태에서, 송수신 엘리먼트(72)는 RF 신호 및 광 신호 양쪽 모두를 송신 및 수신하도록 구성될 수도 있다. 송수신 엘리먼트(72)는 무선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수도 있다는 것이 이해될 것이다.
덧붙여서, 비록 송수신 엘리먼트(72)는 도 32b에서 단일 엘리먼트로서 묘사되지만, WTRU(52)는 임의의 수의 송수신 엘리먼트들(72)을 포함할 수도 있다. 더 구체적으로는, WTRU(52)는 MIMO 기술을 채용할 수도 있다. 따라서, 일 실시형태에서, WTRU(52)는 에어 인터페이스(66)를 통해 무선 신호들을 송신 및 수신하기 위한 둘 이상의 송수신 엘리먼트들(72)(예컨대, 다수의 안테나들)을 구비할 수도 있다.
트랜시버(70)는 송수신 엘리먼트(72)에 의해 송신될 신호들을 변조하도록 그리고 송수신 엘리먼트(72)에 의해 수신되는 신호들을 복조하도록 구성될 수도 있다. 위에서 언급했듯이, WTRU(52)는 다중-모드 능력들을 가질 수도 있다. 따라서, 트랜시버(70)는 WTRU(52)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT들을 통해 통신하는 것을 가능하게 하는 다수의 트랜시버들을 포함할 수도 있다.
WTRU(52)의 프로세서(68)는 스피커/마이크로폰(74), 키패드(76), 및/또는 디스플레이/터치패드(78)(예컨대, 액정 디스플레이(LCD) 디스플레이 유닛 또는 유기 발광 다이오드(OLED) 디스플레이 유닛)에 커플링될 수도 있고 그것들로부터 사용자 입력 데이터를 수신할 수도 있다. 프로세서(68)는 사용자 데이터를 스피커/마이크로폰(74), 키패드(76), 및/또는 디스플레이/터치패드(78)로 또한 출력할 수도 있다. 덧붙여서, 프로세서(68)는 임의의 유형의 적합한 메모리, 이를테면 비-착탈식 메모리(80) 및/또는 착탈식 메모리(82)로부터 정보를 액세스하고 데이터를 그 메모리에 저장할 수도 있다. 비착탈식 메모리(80)는 랜덤-액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수도 있다. 착탈식 메모리(82)는 가입자 식별 모듈(subscriber identity module, SIM) 카드, 메모리 스틱, 보안 디지털(secure digital, SD) 메모리 카드 등을 포함할 수도 있다. 다른 실시형태들에서, 프로세서(68)는 WTRU(52) 상에, 이를테면 서버 또는 홈 컴퓨터(미도시) 상에 물리적으로 위치되지 않은 메모리로부터 정보를 액세스하고 데이터를 그 메모리에 저장할 수도 있다.
프로세서(68)는 전력원(84)으로부터 전력을 받을 수도 있고, WTRU(52)에서의 다른 컴포넌트들에게 전력을 분배하며 그리고/또는 그 컴포넌트들을 제어하도록 구성될 수도 있다. 전력원(84)은 WTRU(52)에게 전력을 공급하는 임의의 적합한 디바이스일 수도 있다. 예를 들어, 전력원(84)은 하나 이상의 건전지 배터리들(예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리듐이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수도 있다.
프로세서(68)는 GPS 칩셋(86)에 또한 커플링될 수도 있는데, 이 GPS 칩셋은 WTRU(52)의 현재 로케이션에 관한 로케이션 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수도 있다. GPS 칩셋(86)으로부터의 정보 외에도, 또는 그 정보 대신에, WTRU(52)는 기지국(예컨대, 기지국들(64a, 64b))으로부터 에어 인터페이스(816)를 통해 로케이션 정보를 수신하며 그리고/또는 둘 이상의 인근 기지국들로부터 수신되고 있는 신호들의 타이밍에 기초하여 자신의 로케이션을 결정할 수도 있다. WTRU(52)는 임의의 적합한 로케이션-결정 방법에 의해 로케이션 정보를 획득하면서도 일 실시형태와 일치하게 유지할 수도 있다는 것이 이해될 것이다.
프로세서(68)는 다른 주변기기들(88)에 추가로 커플링될 수도 있는데, 이 다른 주변기기들은 부가적인 특징들, 기능성 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈들을 포함할 수도 있다. 예를 들어, 주변기기들(88)은 가속도계, e-나침반, 위성 트랜시버, 디지털 카메라(사진들 또는 비디오용), 유니버셜 직렬 버스(universal serial bus, USB) 포트, 진동 디바이스, 텔레비전 트랜시버, 핸즈 프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수도 있다.
도 32c는 일 실시형태에 따른 RAN(54) 및 코어 네트워크(806)의 시스템도이다. 위에서 언급했듯이, RAN(54)은 에어 인터페이스(66)를 통해 WTRU들(52a, 52b, 52c)과 통신하는 UTRA 라디오 기술을 채용할 수도 있다. RAN(54)은 코어 네트워크(806)와 또한 통신할 수도 있다. 도 32c에 도시된 바와 같이, RAN(54)는, 에어 인터페이스(66)를 통해 WTRU들(52a, 52b, 52c)과 통신하는 하나 이상의 트랜시버들을 각각 구비할 수도 있는 eNode-B들(90a, 90b, 90c)을 포함할 수도 있다. Node-B들(90a, 90b, 90c)은 각각이 RAN(54) 내의 특정 셀(미도시)과 연관될 수도 있다. RAN(54)은 RNC들(92a, 92b)을 또한 포함할 수도 있다. RAN(54)은 일 실시형태와 일치하게 유지하면서도 임의의 수의 Node-B들 및 RNC들을 포함할 수도 있다는 것이 이해될 것이다.
도 32c에 도시된 바와 같이, Node-B들(90a, 90b)은 RNC(92a)와 통신하고 있을 수도 있다. 덧붙여, Node-B(90c)는 RNC(92b)와 통신하고 있을 수도 있다. Node-B들(90a, 90b, 90c)은 Iub 인터페이스를 통해 각각의 RNC들(92a, 92b)과 통신할 수도 있다. RNC들(92a, 92b)은 Iur 인터페이스를 통해 서로 통신하고 있을 수도 있다. RNC들(92a, 92b)의 각각은 자신이 접속된 각각의 Node-B들(90a, 90b, 90c)을 제어하도록 구성될 수도 있다. 덧붙여서, RNC들(92a, 92b)의 각각은 외부 루프 전력 제어, 부하 제어, 입허가(admission) 제어, 패킷 스케줄링, 핸드오버 제어, 매크로다이버시티(macrodiversity), 보안 기능들, 데이터 암호화 등과 같은 다른 기능들을 수행 및/또는 지원하도록 구성될 수도 있다.
도 32c에 도시된 코어 네트워크(56)는 미디어 게이트웨이(MGW)(844), 모바일 교환국(MSC)(96), 서빙 GPRS 지원 노드(SGSN)(98), 및/또는 게이트웨이 GPRS 지원 노드(GGSN)(99)를 포함할 수도 있다. 전술한 엘리먼트들의 각각이 코어 네트워크(56)의 부분으로서 묘사되지만, 이들 엘리먼트들 중 어느 것이라도 코어 네트워크 오퍼레이터 이외의 엔티티에 의해 소유되며 그리고/또는 동작될 수도 있다는 것이 이해될 것이다.
RAN(54)에서의 RNC(92a)는 코어 네트워크(56)에서의 MSC(96)에 IuCS 인터페이스를 통해 접속될 수도 있다. MSC(96)는 MGW(94)에 접속될 수도 있다. MSC(96)와 MGW(94)는, WTRU들(52a, 52b, 52c)과 전통적인 지상선 통신 디바이스들 간의 통신들을 용이하게 하기 위해, 회선 교환식 네트워크들, 이를테면 PSTN(58)에 대한 액세스를 WTRU들(52a, 52b, 52c)에게 제공할 수도 있다.
RAN(54)에서의 RNC(92a)는 코어 네트워크(806)에서의 SGSN(98)에 IuPS 인터페이스를 통해 또한 접속될 수도 있다. SGSN(98)은 GGSN(99)에 접속될 수도 있다. SGSN(98)과 GGSN(99)은, WTRU들(52a, 52b, 52c)과 IP 가능 디바이스들 간의 통신들을 용이하게 하기 위해, 패킷 교환식 네트워크들, 이를테면 인터넷(60)에 대한 액세스를 WTRU들(52a, 52b, 52c)에게 제공할 수도 있다.
위에서 언급된 바와 같이, 코어 네트워크(56)는 네트워크들(62)에 또한 접속될 수도 있는데, 그 네트워크들은 다른 서비스 제공자들에 의해 소유된 그리고/또는 동작되는 다른 유선 또는 무선 네트워크들을 포함할 수도 있다.
비록 특징들과 엘리먼트들이 위에서 특정 조합들로 설명되어 있지만, 당업자는 각각의 특징 또는 엘리먼트가 단독으로 또는 다른 특징들 및 엘리먼트들과의 임의의 조합으로 사용될 수 있다는 것이 이해될 것이다. 덧붙여, 본 명세서에서 설명되는 실시형태들은 예시적인 목적들만을 위해 제공된다. 더욱이, 본원에서 설명되는 실시형태들은 컴퓨터 프로그램, 소프트웨어, 또는 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터 판독가능 매체에 통합된 펌웨어에서 구현될 수도 있다. 컴퓨터-판독가능 매체들의 예들은 (유선 또는 무선 접속들을 통해 송신되는) 전자 신호들 및 컴퓨터-판독가능 저장 매체들을 포함한다. 컴퓨터-판독가능 저장 매체들의 예들은, 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스들, 내장형 하드 디스크들 및 착탈식 디스크들과 같은 자기 매체들, 자기-광 매체들, 그리고 CD-ROM 디스크들 및 디지털 다기능 디스크들(DVD들)과 같은 광 매체들을 포함하지만 그것들로 제한되지 않는다. 소프트웨어에 관련한 프로세서가 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서의 사용을 위해 무선 주파수 트랜시버를 구현하는데 사용될 수도 있다.

Claims (21)

  1. 프로세서에 의해 수행되고, 무선 송수신 유닛(wireless transmit/receive unit, WTRU) - 상기 WTRU는 서비스 제공자(service provider, SP)를 더 포함하는 통신 네트워크 내에 있음 - 을 동작시키는 사용자의 인증을 용이하게 하는 방법에 있어서,
    서비스 제공자(SP)에 의해 제공되는 제1 서비스에 액세스하기 위해 상기 SP에 의해 요구되는 인증 보증 레벨(authentication assurance level)을 결정하는 단계;
    상기 WTRU의 하나 이상의 인증 능력을 발견하는 단계 - 각각의 인증 능력은 인증 요소와 보안 특성을 정의하고, 상기 보안 특성은 상기 인증 요소 및 상기 WTRU에 연관됨 - ;
    각각의 인증 요소 및 상기 WTRU에 연관된 상기 보안 특성에 기초하여, 상기 발견된 인증 능력 중에서 상기 SP에 의해 요구되는 상기 인증 보증 레벨을 충족시키는 하나 이상의 인증 요소를 결정하는 단계; 및
    상기 발견된 하나 이상의 인증 능력에 연관된 상기 하나 이상의 인증 요소를 사용하는 상기 사용자의 인증을 트리거하는 단계
    를 포함하는, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  2. 제1항에 있어서,
    상기 하나 이상의 인증 요소에 연관된 하나 이상의 인증 결과에 기초하여, 상기 SP에 의해 요구되는 상기 인증 보증 레벨을 달성하는 통합된(consolidated) 결과를 생성하는 단계; 및
    상기 통합된 결과를 상기 SP로 전송함으로써, 상기 WTRU가 상기 제1 서비스에 액세스하는 것을 가능하게 하는 단계
    를 더 포함하는, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  3. 제2항에 있어서,
    상기 통합된 결과는 암호화 방식으로 함께 바인딩(binding)된 하나 이상의 인증 결과를 포함하며, 상기 통합된 결과는 함께 바인딩된 상기 하나 이상의 인증 결과를 식별하는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  4. 제3항에 있어서,
    상기 통합된 결과는 결집(aggregate) 인증 보증 레벨 및 결집 인증 신선도(freshness) 레벨을 더 포함하며, 상기 결집 인증 보증 레벨 및 상기 결집 인증 신선도 레벨은 상기 하나 이상의 인증 결과에 연관되는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  5. 제2항에 있어서,
    상기 통합된 결과는 상기 하나 이상의 인증 요소 중에서 각각의 인증 요소를 사용한 각각의 인증 동안 공유되는 논스(nonce)에 의해 바인딩된 상기 하나 이상의 인증 결과를 포함하는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  6. 제1항에 있어서,
    상기 하나 이상의 인증 요소 중 선택한 하나의 인증 요소에 연관된 신선도 레벨을 결정하는 단계;
    상기 SP의 정책에 기초하여, 상기 선택한 하나의 인증 요소에 연관된 신선도 레벨이 문턱 레벨을 충족시키는지의 여부를 결정하는 단계; 및
    상기 신선도 레벨이 상기 문턱 레벨을 충족시킨다면, 상기 하나의 인증 요소의 이전의 인증 결과를 표명(assert)하고, 이에 따라 상기 하나의 인증 요소를 사용하는 새로운 인증을 수행하는 것을 그만두는 단계
    를 더 포함하는, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  7. 제1항에 있어서,
    상기 하나 이상의 인증 요소를 사용하는 상기 인증을 트리거하는 단계는,
    네트워크 인증 엔티티(entity)에게 챌린지(challenge)를 전송하는 단계; 및
    상기 챌린지에 응답하여, 상기 네트워크 인증 엔티티로부터 응답을 수신하는 단계
    를 포함하는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  8. 제1항에 있어서,
    상기 방법은 상기 WTRU 상에서 동작하는 논리적 엔티티에 의해 수행되는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  9. 제1항에 있어서,
    상기 방법은 상기 WTRU 및 상기 SP와 통신하고 있는 상기 네트워크에서 동작하는 논리적 엔티티에 의해 수행되는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  10. 삭제
  11. 제1항에 있어서,
    발견된 인증 능력의 하나 이상의 인증 요소가 상기 인증 보증 레벨을 충족시킬 수 없다고 결정하는 단계;
    하나 이상의 인증 요소가 상기 인증 보증 레벨을 충족시킬 수 없다고 결정한 것에 응답하여, 제2 인증 보증 레벨을 달성할 수 있는 하나 이상의 인증 요소를 선택하는 단계;
    상기 제2 인증 보증 레벨을 달성할 수 있는 상기 하나 이상의 인증 요소를 사용하는 상기 사용자의 제2 인증을 트리거하는 단계;
    상기 제2 인증 보증 레벨을 달성하는 제2 통합된 결과를 생성하는 단계; 및
    상기 제2 통합된 결과를 상기 SP에게 전송하고, 이에 따라 상기 WTRU가 상기 SP에 의해 제공되는 제2 서비스에 액세스하는 것 - 상기 제2 서비스에의 액세스는 상기 제1 서비스에 액세스하기 위해 요구되는 상기 인증 보증 레벨보다 더 낮은 보증 레벨을 요구함 - 을 가능하게 하는 단계
    를 더 포함하는, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  12. 삭제
  13. 제1항에 있어서,
    상기 하나 이상의 발견된 인증 능력은 생체인식 능력을 포함하며,
    상기 방법은,
    상기 생체인식 능력을 사용한 생체인식 인증이 상기 인증 보증 레벨을 충족시킬 수 있다고 결정하는 단계를 더 포함하는, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  14. 제13항에 있어서,
    상기 하나 이상의 인증 요소 중 하나는 생체인식 요소이며, 상기 생체인식 요소는 유일한 인증 요소인 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  15. 제1항에 있어서,
    상기 하나 이상의 인증 요소 중 제1 인증 요소는 생체인식 요소이고, 상기 하나 이상의 인증 요소 중 제2 인증 요소는 패스워드 요소인 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  16. 제1항에 있어서,
    상기 하나 이상의 인증 능력을 발견하는 단계는,
    상기 WTRU의 등록 동안 상기 WTRU의 적어도 하나의 능력을 수신하는 단계;
    상기 WTRU의 식별자와 함께 상기 WTRU의 상기 적어도 하나의 능력을 저장하는 단계; 및
    상기 식별자에 기초하여, 상기 WTRU가 상기 제1 서비스에 대한 액세스를 시도할 때 상기 적어도 하나의 능력을 검색하는(retrieving) 단계
    를 포함하는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  17. 제1항에 있어서,
    상기 하나 이상의 인증 요소 중 적어도 하나의 인증 요소를 사용하여 트리거되는 상기 인증은 상기 SP 또는 아이덴티티 제공자(identity provider, IdP)에서 발생하는 것인, WTRU를 동작시키는 사용자의 인증을 용이하게 하는 방법.
  18. 무선 송수신 유닛(wireless transmit/receive unit, WTRU) 및 서비스 제공자(service provider, SP)를 더 포함하는 통신 네트워크에서의 네트워크 서버에 있어서,
    실행가능 명령어들을 포함하는 메모리; 및
    프로세서
    를 포함하며,
    상기 프로세서는, 상기 실행가능 명령어들을 실행할 때,
    상기 SP에 의해 제공되는 제1 서비스에 액세스하기 위한 인증 요건을 결정하는 동작;
    상기 WTRU의 하나 이상의 인증 능력을 발견하는 동작 - 각각의 인증 능력은 인증 요소와 보안 특성을 정의하고, 상기 보안 특성은 상기 인증 요소 및 상기 WTRU에 연관됨 - ;
    각각의 인증 요소 및 상기 WTRU에 연관된 상기 보안 특성에 기초하여, 상기 발견된 하나 이상의 인증 능력 중에서 상기 인증 요건을 달성할 수 있는 하나 이상의 인증 요소를 결정하는 동작; 및
    상기 인증 능력에 연관된 하나 이상의 인증 요소 중 적어도 하나의 인증 요소를 사용하는 상기 WTRU의 사용자의 인증을 트리거하는 동작
    을 실시하는 것인, 네트워크 서버.
  19. 제18항에 있어서,
    상기 하나 이상의 인증 요소 중 적어도 하나의 인증 요소를 사용하는 상기 인증은 상기 SP에서 발생하는 것인, 네트워크 서버.
  20. 제18항에 있어서,
    상기 네트워크 서버는 아이덴티티 제공자(identity provider, IdP)이고, 상기 하나 이상의 인증 요소 중 적어도 하나의 인증 요소를 사용하는 상기 인증은 상기 IdP에서 발생하는 것인, 네트워크 서버.
  21. 제18항에 있어서,
    상기 SP에 의해 제공되는 상기 제1 서비스에 액세스하기 위한 상기 인증 요건을 결정하는 동작은, 상기 SP로부터 상기 인증 요건 - 상기 인증 요건은 인증 보증 레벨을 나타냄 - 을 수신하는 동작을 포함하는 것인, 네트워크 서버.
KR1020157033829A 2013-04-26 2014-04-25 요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증 KR101924683B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361816446P 2013-04-26 2013-04-26
US61/816,446 2013-04-26
US201361832509P 2013-06-07 2013-06-07
US61/832,509 2013-06-07
PCT/US2014/035517 WO2014176539A1 (en) 2013-04-26 2014-04-25 Multi-factor authentication to achieve required authentication assurance level

Publications (2)

Publication Number Publication Date
KR20160004363A KR20160004363A (ko) 2016-01-12
KR101924683B1 true KR101924683B1 (ko) 2018-12-03

Family

ID=50942315

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157033829A KR101924683B1 (ko) 2013-04-26 2014-04-25 요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증

Country Status (7)

Country Link
US (1) US20160087957A1 (ko)
EP (1) EP2989770A1 (ko)
JP (1) JP6307593B2 (ko)
KR (1) KR101924683B1 (ko)
CN (1) CN105144656A (ko)
TW (1) TW201541977A (ko)
WO (1) WO2014176539A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220163704A (ko) * 2021-06-03 2022-12-12 중부대학교 산학협력단 쌍토큰을 이용한 tls 세션 복구 방법

Families Citing this family (294)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7609402B2 (en) 2001-01-19 2009-10-27 Flexiworld, Inc. Methods for universal data output
US10860290B2 (en) 2000-11-01 2020-12-08 Flexiworld Technologies, Inc. Mobile information apparatuses that include a digital camera, a touch sensitive screen interface, support for voice activated commands, and a wireless communication chip or chipset supporting IEEE 802.11
US11204729B2 (en) 2000-11-01 2021-12-21 Flexiworld Technologies, Inc. Internet based digital content services for pervasively providing protected digital content to smart devices based on having subscribed to the digital content service
US20020051200A1 (en) 2000-11-01 2002-05-02 Chang William Ho Controller for device-to-device pervasive digital output
US10915296B2 (en) 2000-11-01 2021-02-09 Flexiworld Technologies, Inc. Information apparatus that includes a touch sensitive screen interface for managing or replying to e-mails
WO2002041107A2 (en) 2000-11-20 2002-05-23 Flexiworld Technologies, Inc. Systems and methods for mobile and pervasive output
US9203835B2 (en) * 2013-03-01 2015-12-01 Paypal, Inc. Systems and methods for authenticating a user based on a biometric model associated with the user
US20160048846A1 (en) * 2013-03-15 2016-02-18 Capital One Financial Corporation System and method for digital authentication
US9396320B2 (en) 2013-03-22 2016-07-19 Nok Nok Labs, Inc. System and method for non-intrusive, privacy-preserving authentication
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US10270748B2 (en) * 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
US10069811B2 (en) * 2013-10-17 2018-09-04 Arm Ip Limited Registry apparatus, agent device, application providing apparatus and corresponding methods
US10032008B2 (en) 2014-02-23 2018-07-24 Qualcomm Incorporated Trust broker authentication method for mobile devices
US20150242605A1 (en) * 2014-02-23 2015-08-27 Qualcomm Incorporated Continuous authentication with a mobile device
US10049202B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Strong authentication using authentication objects
US10050787B1 (en) * 2014-03-25 2018-08-14 Amazon Technologies, Inc. Authentication objects with attestation
US9680812B1 (en) * 2014-03-27 2017-06-13 EMC IP Holding Company LLC Enrolling a user in a new authentication procdure only if trusted
US10069868B2 (en) * 2014-03-28 2018-09-04 Intel Corporation Systems and methods to facilitate multi-factor authentication policy enforcement using one or more policy handlers
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
GB201408539D0 (en) * 2014-05-14 2014-06-25 Mastercard International Inc Improvements in mobile payment systems
US9264419B1 (en) * 2014-06-26 2016-02-16 Amazon Technologies, Inc. Two factor authentication with authentication objects
KR102191017B1 (ko) * 2014-07-19 2020-12-15 삼성전자주식회사 eSIM 프로비저닝 방법과 이를 지원하는 서버 장치
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US10740447B2 (en) 2014-09-08 2020-08-11 Tessera Advanced Technologies, Inc. Using biometric user-specific attributes
US9740841B2 (en) * 2014-09-08 2017-08-22 Tessera Advanced Technologies, Inc. Using biometric user-specific attributes
WO2016040744A1 (en) 2014-09-12 2016-03-17 Id. Me, Inc. Systems and methods for online third-party authentication of credentials
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US10560418B2 (en) * 2014-10-02 2020-02-11 Facebook, Inc. Techniques for managing discussion sharing on a mobile platform
US10225245B2 (en) * 2014-11-18 2019-03-05 Auth0, Inc. Identity infrastructure as a service
WO2016118304A1 (en) * 2014-12-31 2016-07-28 Imageware Systems, Inc. Cloud-based biometric enrollment, identification and verification through identity providers
US20170374070A1 (en) * 2015-01-09 2017-12-28 Interdigital Technology Corporation Scalable policy based execution of multi-factor authentication
CN104660416B (zh) * 2015-02-13 2018-08-28 飞天诚信科技股份有限公司 一种语音认证系统和设备的工作方法
US11171941B2 (en) 2015-02-24 2021-11-09 Nelson A. Cicchitto Mobile device enabled desktop tethered and tetherless authentication
US11122034B2 (en) 2015-02-24 2021-09-14 Nelson A. Cicchitto Method and apparatus for an identity assurance score with ties to an ID-less and password-less authentication system
US9565183B2 (en) * 2015-03-13 2017-02-07 Apollo Education Group, Inc. Location and device based student access control
CN106161365B (zh) * 2015-04-03 2020-02-18 腾讯科技（深圳）有限公司 一种数据处理方法、装置及终端
US10298563B2 (en) 2015-04-29 2019-05-21 Hewlett Packard Enterprise Development Lp Multi-factor authorization for IEEE 802.1x-enabled networks
CN106211152B (zh) * 2015-04-30 2019-09-06 新华三技术有限公司 一种无线接入认证方法及装置
US9866543B2 (en) * 2015-06-03 2018-01-09 Paypal, Inc. Authentication through multiple pathways based on device capabilities and user requests
US10009329B2 (en) 2015-06-23 2018-06-26 Microsoft Technology Licensing, Llc Learned roving authentication profiles
US10757104B1 (en) 2015-06-29 2020-08-25 Veritas Technologies Llc System and method for authentication in a computing system
US9736169B2 (en) 2015-07-02 2017-08-15 International Business Machines Corporation Managing user authentication in association with application access
CN106487511B (zh) * 2015-08-27 2020-02-04 阿里巴巴集团控股有限公司 身份认证方法及装置
JP5951094B1 (ja) * 2015-09-07 2016-07-13 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
US10135801B2 (en) * 2015-09-09 2018-11-20 Oath Inc. On-line account recovery
US9779230B2 (en) * 2015-09-11 2017-10-03 Dell Products, Lp System and method for off-host abstraction of multifactor authentication
JP6122924B2 (ja) 2015-09-11 2017-04-26 ヤフー株式会社 提供装置、端末装置、提供方法、提供プログラム及び認証処理システム
US10616196B1 (en) * 2015-09-24 2020-04-07 EMC IP Holding Company LLC User authentication with multiple authentication sources and non-binary authentication decisions
US10348709B2 (en) * 2015-09-25 2019-07-09 Mcafee, Llc Cumulative authentication for step-up increased authentication factors
JP6505573B2 (ja) * 2015-10-07 2019-04-24 Kddi株式会社 認証システム、認証サーバ、事業者サーバ及び利用者端末
CN105187450B (zh) * 2015-10-08 2019-05-10 飞天诚信科技股份有限公司 一种基于认证设备进行认证的方法和设备
ES2609836B2 (es) * 2015-10-15 2018-08-16 Universidad Rey Juan Carlos Procedimiento y sistema para la validación de una petición de autenticación/autorización de un usuario
CN105472125B (zh) * 2015-11-16 2019-11-26 联想(北京)有限公司 一种信息处理方法及电子设备
WO2017096214A1 (en) 2015-12-04 2017-06-08 Cernoch Dan Systems and methods for scalable-factor authentication
US11232187B2 (en) * 2016-01-13 2022-01-25 American Express Travel Related Services Company, Inc. Contextual identification and information security
CN108781216B (zh) * 2016-01-25 2021-03-16 瑞典爱立信有限公司 用于网络接入的方法和设备
WO2017134632A1 (en) * 2016-02-03 2017-08-10 Averon Us, Inc. Method and apparatus for facilitating frictionless two-factor authentication
JP2017152947A (ja) * 2016-02-25 2017-08-31 京セラ株式会社 携帯端末
CN105721480A (zh) * 2016-03-02 2016-06-29 北京九州云腾科技有限公司 基于fido硬件的用户操作方法及系统
US10693855B1 (en) * 2016-03-31 2020-06-23 EMC IP Holding Company LLC Fraud detection
US10305901B2 (en) * 2016-05-06 2019-05-28 Blackberry Limited System and method for multi-factor authentication
CN109196500B (zh) * 2016-05-13 2022-11-01 移动熨斗公司 对基于云的服务的基于统一vpn和身份的认证
US10523660B1 (en) 2016-05-13 2019-12-31 MobileIron, Inc. Asserting a mobile identity to users and devices in an enterprise authentication system
JP6570480B2 (ja) * 2016-06-07 2019-09-04 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
US10447736B1 (en) * 2016-06-09 2019-10-15 Symantec Corporation Systems and methods for providing security in smart buildings
US11625502B2 (en) 2016-06-10 2023-04-11 OneTrust, LLC Data processing systems for identifying and modifying processes that are subject to data subject access requests
US11354435B2 (en) 2016-06-10 2022-06-07 OneTrust, LLC Data processing systems for data testing to confirm data deletion and related methods
US11586700B2 (en) 2016-06-10 2023-02-21 OneTrust, LLC Data processing systems and methods for automatically blocking the use of tracking tools
US20220035945A1 (en) * 2016-06-10 2022-02-03 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US11392720B2 (en) 2016-06-10 2022-07-19 OneTrust, LLC Data processing systems for verification of consent and notice processing and related methods
US11188615B2 (en) 2016-06-10 2021-11-30 OneTrust, LLC Data processing consent capture systems and related methods
US11651106B2 (en) 2016-06-10 2023-05-16 OneTrust, LLC Data processing systems for fulfilling data subject access requests and related methods
US10997318B2 (en) 2016-06-10 2021-05-04 OneTrust, LLC Data processing systems for generating and populating a data inventory for processing data access requests
US11354763B2 (en) * 2016-07-05 2022-06-07 Idemia Identity & Security USA LLC Communication flow for verification and identification check
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10291609B2 (en) * 2016-08-23 2019-05-14 Reavire, Inc. Vault appliance for identity verification and secure dispatch of rights
US11050758B2 (en) 2016-08-23 2021-06-29 Reavire, Inc. Controlling access to a computer network using measured device location
WO2018051236A1 (en) 2016-09-13 2018-03-22 Silverfort Ltd. Protection of authentication tokens
US10282537B2 (en) * 2016-09-20 2019-05-07 International Business Machines Corporation Single prompt multiple-response user authentication method
US10122706B2 (en) * 2016-10-27 2018-11-06 Ca, Inc. Authenticating identity for password changes
US10789386B2 (en) 2016-11-09 2020-09-29 Reavire, Inc. Dispatching identity information from secure hardware appliance
US11017404B1 (en) 2016-11-15 2021-05-25 Wells Fargo Bank, N.A. Event based authentication
US20180145984A1 (en) * 2016-11-24 2018-05-24 Rajender Duggal System and method for providing security solutions to protect enterprise critical assets
US10027662B1 (en) * 2016-12-06 2018-07-17 Amazon Technologies, Inc. Dynamic user authentication
US20180167383A1 (en) * 2016-12-12 2018-06-14 Qualcomm Incorporated Integration of password-less authentication systems with legacy identity federation
US10049673B2 (en) * 2016-12-19 2018-08-14 Bank Of America Corporation Synthesized voice authentication engine
US10446157B2 (en) 2016-12-19 2019-10-15 Bank Of America Corporation Synthesized voice authentication engine
CN108243115B (zh) * 2016-12-26 2021-06-29 新华三技术有限公司 报文处理方法及装置
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
DE102017000768A1 (de) 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
US10977345B2 (en) 2017-02-17 2021-04-13 TwoSesnse, Inc. Authentication session extension using ephemeral behavior detection
JP6581611B2 (ja) * 2017-02-21 2019-09-25 日本電信電話株式会社 認証鍵共有システムおよび認証鍵共有方法
US10565591B2 (en) * 2017-02-23 2020-02-18 Paypal, Inc. Bridge for communicating data outside of a mobile application
CN107172008B (zh) * 2017-04-01 2019-10-18 北京芯盾时代科技有限公司 一种在移动设备中进行多系统认证及同步的系统和方法
US10630668B2 (en) 2017-04-28 2020-04-21 Amazon Technologies, Inc. Single sign-on registration
US9882918B1 (en) * 2017-05-15 2018-01-30 Forcepoint, LLC User behavior profile in a blockchain
JP6759152B2 (ja) * 2017-05-24 2020-09-23 キヤノン株式会社 画像処理装置、方法、プログラム及びシステム
US10462120B2 (en) 2017-05-25 2019-10-29 Barclays Services Corporation Authentication system and method
EP3631662A4 (en) * 2017-05-25 2020-10-28 Barclays Services Corporation AUTHENTICATION SYSTEM AND METHOD
KR102413638B1 (ko) * 2017-05-30 2022-06-27 삼성에스디에스 주식회사 인증 서비스 시스템 및 방법
CN110710178B (zh) * 2017-06-01 2021-07-06 诺基亚通信公司 无线接入网络中的用户认证
EP3643001B1 (en) 2017-06-19 2023-08-02 Silverfort Ltd. Actively monitoring encrypted traffic by inspecting logs
US11544356B2 (en) * 2017-06-19 2023-01-03 Citrix Systems, Inc. Systems and methods for dynamic flexible authentication in a cloud service
WO2019014928A1 (zh) * 2017-07-21 2019-01-24 北京小米移动软件有限公司 一种控制可操控设备接入网络的方法及装置
CN107483419B (zh) * 2017-07-28 2020-06-09 深圳市优克联新技术有限公司 服务器认证接入终端的方法、装置、系统、服务器及计算机可读存储介质
DK3665860T3 (da) 2017-08-11 2021-08-09 Kobil Gmbh Multifaktorautentificering
US10097538B1 (en) * 2017-08-12 2018-10-09 Growpath, Inc. User authentication systems and methods
US10476870B2 (en) * 2017-08-25 2019-11-12 Microsoft Technology Licensing, Llc Local claim-based security service with cross-browser compatibility
WO2019045639A1 (en) * 2017-08-29 2019-03-07 Home Control Singapore Pte Ltd DISCRETE USER RECOGNITION
CN107395644B (zh) * 2017-09-01 2020-05-12 北京知道创宇信息技术股份有限公司 一种多协议认证系统及方法
WO2019061514A1 (zh) * 2017-09-30 2019-04-04 深圳大学 安全的无线通信物理层斜率认证方法和装置
WO2019088985A1 (en) * 2017-10-30 2019-05-09 Visa International Service Association Data security hub
US10764270B2 (en) 2017-11-20 2020-09-01 Allstate Insurance Company Cryptographically transmitting and storing identity tokens and/or activity data among spatially distributed computing devices
US10798103B2 (en) 2017-11-21 2020-10-06 VWware, Inc. Adaptive device enrollment
US10749870B2 (en) * 2017-11-21 2020-08-18 Vmware, Inc. Adaptive device enrollment
US10972468B2 (en) 2017-11-21 2021-04-06 Vmware, Inc. Adaptive device enrollment
US10986078B2 (en) * 2017-11-21 2021-04-20 Vmware, Inc. Adaptive device enrollment
JP7091057B2 (ja) * 2017-11-22 2022-06-27 キヤノン株式会社 情報処理装置、情報処理装置における方法、およびプログラム
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11349665B2 (en) * 2017-12-22 2022-05-31 Motorola Solutions, Inc. Device attestation server and method for attesting to the integrity of a mobile device
EP3503492A1 (en) * 2017-12-22 2019-06-26 Deutsche Telekom AG Techniques for establishing data communication based on user identification
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
SG10201800338TA (en) * 2018-01-15 2019-08-27 Mastercard International Inc User authentication systems and methods
US11367323B1 (en) 2018-01-16 2022-06-21 Secureauth Corporation System and method for secure pair and unpair processing using a dynamic level of assurance (LOA) score
CA3089255A1 (en) * 2018-02-01 2019-08-08 Equifax Inc. Verification of access to secured electronic resources
US11625473B2 (en) * 2018-02-14 2023-04-11 Samsung Electronics Co., Ltd. Method and apparatus with selective combined authentication
GB2573262B (en) * 2018-03-08 2022-04-13 Benefit Vantage Ltd Mobile identification method based on SIM card and device-related parameters
US10911464B2 (en) * 2018-04-27 2021-02-02 Oracle International Corporation Framework for multi-level and multi-factor inline enrollment
US11328115B2 (en) * 2018-05-10 2022-05-10 Microsoft Technology Licensing, Llc. Self-asserted claims provider
US11240220B2 (en) * 2018-06-13 2022-02-01 Paypal, Inc. Systems and methods for user authentication based on multiple devices
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US10911234B2 (en) * 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11271930B2 (en) 2018-07-02 2022-03-08 Mastercard International Incorporated System architecture and database for context-based authentication
US11172349B2 (en) 2018-07-05 2021-11-09 Mediatek Inc. Efficient file identifiers (FIDs) and short file identifiers (SFIs) under universal subscriber identity module (USIM) application dedicated file (ADF)
US10993110B2 (en) * 2018-07-13 2021-04-27 Nvidia Corp. Connectionless fast method for configuring Wi-Fi on displayless Wi-Fi IoT device
US11800351B2 (en) 2018-07-17 2023-10-24 Telefonaktiebolaget Lm Ericsson (Publ) Multi-X key chaining for Generic Bootstrapping Architecture (GBA)
US11100204B2 (en) * 2018-07-19 2021-08-24 Motorola Mobility Llc Methods and devices for granting increasing operational access with increasing authentication factors
US11778469B2 (en) 2018-08-20 2023-10-03 Telefonaktiebolaget Lm Ericsson (Publ) First node, second node, third node, and methods performed thereby for managing data in a database in a communications network
US11544409B2 (en) 2018-09-07 2023-01-03 OneTrust, LLC Data processing systems and methods for automatically protecting sensitive data within privacy management systems
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
US10783519B2 (en) 2018-10-02 2020-09-22 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
SG11202101221WA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
CA3115107A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10748138B2 (en) 2018-10-02 2020-08-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
MX2021003138A (es) 2018-10-02 2021-05-14 Capital One Services Llc Sistemas y metodos para autentificacion criptografica de tarjetas sin contacto.
SG11202101874SA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
AU2019354421A1 (en) 2018-10-02 2021-04-29 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072440A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10733645B2 (en) 2018-10-02 2020-08-04 Capital One Services, Llc Systems and methods for establishing identity for order pick up
AU2019355436A1 (en) 2018-10-02 2021-04-15 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072529A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3115142A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072552A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3112585A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11822637B2 (en) * 2018-10-18 2023-11-21 Oracle International Corporation Adaptive authentication in spreadsheet interface integrated with web service
WO2020092131A1 (en) * 2018-10-30 2020-05-07 Valimail Inc. Signed message header storing sender account authentication method
US11159517B2 (en) * 2018-11-21 2021-10-26 Citrix Systems, Inc. Self-federation in authentication systems
US11227036B1 (en) * 2018-11-27 2022-01-18 Amazon Technologies, Inc. Determination of authentication assurance via algorithmic decay
US11233788B1 (en) * 2018-11-27 2022-01-25 Amazon Technologies, Inc. Determining authentication assurance from historical and runtime-provided inputs
US10958661B2 (en) * 2018-11-28 2021-03-23 Bank Of America Corporation Multi-layer authentication system with selective level access control
US20200220948A1 (en) * 2019-01-04 2020-07-09 Byton North America Corporation Unique id for correlating services across regions
WO2020144518A1 (en) * 2019-01-10 2020-07-16 Silverfort Ltd. Using virtual tokens to extend authentication protocols
US11361302B2 (en) 2019-01-11 2022-06-14 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US11451532B2 (en) * 2019-01-25 2022-09-20 Dell Products L.P. Behavioral biometrics and machine learning to secure website logins
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
KR20200100481A (ko) * 2019-02-18 2020-08-26 삼성전자주식회사 생체 정보를 인증하기 위한 전자 장치 및 그의 동작 방법
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US11531736B1 (en) 2019-03-18 2022-12-20 Amazon Technologies, Inc. User authentication as a service
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110138736B (zh) * 2019-04-11 2022-05-13 泉州信息工程学院 物联网多重动态随机加密的身份认证方法和装置及设备
US12022295B2 (en) * 2019-04-29 2024-06-25 Sonicwall Inc. Streamlined creation and expansion of a wireless mesh network
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US11336682B2 (en) * 2019-07-09 2022-05-17 Nice Ltd. System and method for generating and implementing a real-time multi-factor authentication policy across multiple channels
US11265305B2 (en) * 2019-07-12 2022-03-01 International Business Machines Corporation Managing anonymous network connections
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US10862689B1 (en) * 2019-07-23 2020-12-08 Cyberark Software Ltd. Verification of client identities based on non-distributed data
US11991181B2 (en) * 2019-07-31 2024-05-21 Coronet Cyber Security Ltd. Multi factor authentication
US11096059B1 (en) 2019-08-04 2021-08-17 Acceptto Corporation System and method for secure touchless authentication of user paired device, behavior and identity
US20210056193A1 (en) * 2019-08-20 2021-02-25 Microsoft Technology Licensing, Llc Permitted authentication types for account access
DE102019125959A1 (de) * 2019-09-26 2021-04-01 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Bereitstellen einer Kommunikationsfunktion in einem Fortbewegungsmittel
CN114746913A (zh) 2019-10-02 2022-07-12 第一资本服务有限责任公司 使用非接触式传统磁条数据的客户端设备认证
JP7367443B2 (ja) * 2019-10-09 2023-10-24 富士通株式会社 本人確認プログラム、管理装置及び本人確認方法
US10685137B1 (en) * 2019-10-16 2020-06-16 Capital One Services, Llc Methods and systems for leveraging existing user data to verify user credentials
US11171945B2 (en) 2019-10-16 2021-11-09 Capital One Services, Llc Time-based token trust depreciation
US11722481B2 (en) * 2019-10-31 2023-08-08 Citrix Systems, Inc. Multiple identity provider authentication system
US10951606B1 (en) * 2019-12-04 2021-03-16 Acceptto Corporation Continuous authentication through orchestration and risk calculation post-authorization system and method
EP3840322A1 (en) * 2019-12-20 2021-06-23 Thales Dis France Sa Method to facilitate user authenticating in a wireless network
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
CN111091387A (zh) * 2019-12-31 2020-05-01 中国银行股份有限公司 一种认证方法、装置及系统
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US11258779B2 (en) 2020-01-14 2022-02-22 Cisco Technology, Inc. Wireless LAN (WLAN) public identity federation trust architecture
CN111404933B (zh) * 2020-03-16 2022-04-15 维沃移动通信有限公司 鉴权方法、电子设备及鉴权服务器
TWI768307B (zh) * 2020-03-18 2022-06-21 傑睿資訊服務股份有限公司 開源軟體整合方法
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US20210377051A1 (en) * 2020-05-26 2021-12-02 Motorola Solutions, Inc. Method of establishing a future 2-way authentication between a client application and an application server
US20210385183A1 (en) * 2020-06-06 2021-12-09 Fortinet, Inc. Multi-factor authentication for accessing an electronic mail
CA3185242A1 (en) * 2020-07-08 2022-01-13 James A. Austin Peer-to-peer secure communication system, apparatus, and method
EP4179435A1 (en) 2020-07-08 2023-05-17 OneTrust LLC Systems and methods for targeted data discovery
TWI759968B (zh) * 2020-08-06 2022-04-01 美商動信安全股份有限公司 安全金鑰裝置、安全認證系統以及安全認證方法
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
FR3113753B1 (fr) * 2020-08-25 2023-05-12 Idemia France Procédé de vérification d’une carte à microcircuit, procédé de personnalisation d’une carte à microcircuit, carte à microcircuit et dispositif électronique associé
US11329998B1 (en) 2020-08-31 2022-05-10 Secureauth Corporation Identification (ID) proofing and risk engine integration system and method
US12003506B2 (en) * 2020-10-07 2024-06-04 Arris Enterprises Llc Biometrics based access controls for network features
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11687528B2 (en) 2021-01-25 2023-06-27 OneTrust, LLC Systems and methods for discovery, classification, and indexing of data in a native computing system
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11775348B2 (en) 2021-02-17 2023-10-03 OneTrust, LLC Managing custom workflows for domain objects defined within microservices
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US11621957B2 (en) 2021-03-31 2023-04-04 Cisco Technology, Inc. Identity verification for network access
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
US20220385660A1 (en) * 2021-05-28 2022-12-01 Microsoft Technology Licensing, Llc Client device capable of dynamically routing authentication requests to a backup authentication system
US11855979B2 (en) 2021-05-28 2023-12-26 Microsoft Technology Licensing, Llc Proxy configured to dynamically failover authentication traffic to a backup authentication system
US11968242B2 (en) 2021-07-01 2024-04-23 Cisco Technology, Inc. Differentiated service in a federation-based access network
JPWO2023062809A1 (ko) * 2021-10-15 2023-04-20
US12003499B2 (en) * 2021-11-24 2024-06-04 Gerald Sindell Universal, hierarchally-outsourced multi-phased authentication framework with a central global database
US20230198973A1 (en) * 2021-12-16 2023-06-22 Microsoft Technology Licensing, Llc Service to service authentication in computing systems
JP7466807B2 (ja) 2022-02-10 2024-04-12 三菱電機株式会社 負荷特定装置、負荷特定方法及び負荷特定プログラム
TWI824517B (zh) * 2022-05-12 2023-12-01 技嘉科技股份有限公司 身分驗證方法及身分驗證系統
KR102654983B1 (ko) * 2023-12-29 2024-04-05 한국과학기술정보연구원 다요소 인증 방법 및 시스템

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172431A (ja) * 2005-12-26 2007-07-05 Hitachi Ltd 認証システムおよび認証方法
WO2013003535A1 (en) * 2011-06-28 2013-01-03 Interdigital Patent Holdings, Inc. Automated negotiation and selection of authentication protocols

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU4005999A (en) * 1998-05-21 1999-12-06 Equifax, Inc. System and method for authentication of network users and issuing a digital certificate
JP2003091509A (ja) * 2001-09-17 2003-03-28 Nec Corp 携帯通信機器の個人認証方法およびそれを記述したプログラム
US20030115142A1 (en) * 2001-12-12 2003-06-19 Intel Corporation Identity authentication portfolio system
JP2003248661A (ja) * 2002-02-25 2003-09-05 Sony Corp 認証処理装置および認証処理方法、情報処理装置および情報処理方法、認証処理システム、記録媒体、並びにプログラム
US20040039909A1 (en) * 2002-08-22 2004-02-26 David Cheng Flexible authentication with multiple levels and factors
US7207058B2 (en) * 2002-12-31 2007-04-17 American Express Travel Related Services Company, Inc. Method and system for transmitting authentication context information
US20050177724A1 (en) * 2004-01-16 2005-08-11 Valiuddin Ali Authentication system and method
KR20060131169A (ko) * 2005-06-15 2006-12-20 삼성전자주식회사 통신 시스템에서 인증 수행 시스템 및 방법
US7966489B2 (en) * 2006-08-01 2011-06-21 Cisco Technology, Inc. Method and apparatus for selecting an appropriate authentication method on a client
JP2008117326A (ja) * 2006-11-08 2008-05-22 Fuji Xerox Co Ltd サービス利用認可システム、コンテンツ利用認可システム、サービス利用認可プログラム、コンテンツ利用認可プログラムおよびサービス利用認可方法
CN100530213C (zh) * 2006-11-08 2009-08-19 华为技术有限公司 一种确定生物认证系统的安全级别的方法和设备
US8978117B2 (en) * 2007-11-19 2015-03-10 Avaya Inc. Authentication frequency and challenge type based on environmental and physiological properties
US9122895B2 (en) * 2008-06-25 2015-09-01 Microsoft Technology Licensing, Llc Authorization for transient storage devices with multiple authentication silos
JP2010067124A (ja) * 2008-09-12 2010-03-25 Nec Corp 認証管理装置および認証管理方法ならびにそのプログラム
JP5459583B2 (ja) * 2009-03-25 2014-04-02 日本電気株式会社 認証方法及びその認証システム並びにその認証処理プログラム
CN101853360A (zh) * 2009-04-02 2010-10-06 同方股份有限公司 一种用于移动存储设备的认证系统
JP2011145906A (ja) * 2010-01-15 2011-07-28 Hitachi Omron Terminal Solutions Corp 取引処理装置および取引処理方法
US8756650B2 (en) * 2010-03-15 2014-06-17 Broadcom Corporation Dynamic authentication of a user
US8839346B2 (en) * 2010-07-21 2014-09-16 Citrix Systems, Inc. Systems and methods for providing a smart group
CN107070843A (zh) * 2011-04-28 2017-08-18 交互数字专利控股公司 一种用户设备以及在用户设备中的方法
CN102780674A (zh) * 2011-05-09 2012-11-14 同方股份有限公司 一种具有多因素认证方法的网络业务处理方法及系统
EP2725835A1 (en) * 2012-10-24 2014-04-30 Gemalto SA Method for authenticating a user
US20140157401A1 (en) * 2012-11-30 2014-06-05 Motorola Mobility Llc Method of Dynamically Adjusting an Authentication Sensor
US20150319156A1 (en) * 2012-12-12 2015-11-05 Interdigital Patent Holdings Inc. Independent identity management systems
US9219732B2 (en) * 2012-12-28 2015-12-22 Nok Nok Labs, Inc. System and method for processing random challenges within an authentication framework
US9172687B2 (en) * 2012-12-28 2015-10-27 Nok Nok Labs, Inc. Query system and method to determine authentication capabilities
GB2510120A (en) * 2013-01-24 2014-07-30 Ibm User authentication based on dynamically selected service authentication levels
US10270748B2 (en) * 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9426183B2 (en) * 2013-07-28 2016-08-23 Acceptto Corporation Authentication policy orchestration for a user device
US9444824B1 (en) * 2014-02-28 2016-09-13 Intuit Inc. Methods, systems, and articles of manufacture for implementing adaptive levels of assurance in a financial management system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172431A (ja) * 2005-12-26 2007-07-05 Hitachi Ltd 認証システムおよび認証方法
WO2013003535A1 (en) * 2011-06-28 2013-01-03 Interdigital Patent Holdings, Inc. Automated negotiation and selection of authentication protocols

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220163704A (ko) * 2021-06-03 2022-12-12 중부대학교 산학협력단 쌍토큰을 이용한 tls 세션 복구 방법
KR102577882B1 (ko) 2021-06-03 2023-09-12 중부대학교 산학협력단 쌍토큰을 이용한 tls 세션 복구 방법

Also Published As

Publication number Publication date
EP2989770A1 (en) 2016-03-02
JP2016525807A (ja) 2016-08-25
CN105144656A (zh) 2015-12-09
JP6307593B2 (ja) 2018-04-04
KR20160004363A (ko) 2016-01-12
US20160087957A1 (en) 2016-03-24
WO2014176539A1 (en) 2014-10-30
TW201541977A (zh) 2015-11-01

Similar Documents

Publication Publication Date Title
KR101924683B1 (ko) 요구된 인증 보증 레벨을 달성하기 위한 다중요소 인증
US20170374070A1 (en) Scalable policy based execution of multi-factor authentication
US9237142B2 (en) Client and server group SSO with local openID
US9185560B2 (en) Identity management on a wireless device
EP2534810B1 (en) Method and apparatus for trusted federated identity
KR101670973B1 (ko) 무선 유닛의 사용자를 인증하는 방법들 및 시스템들
US20160050234A1 (en) Seamless authentication across multiple entities
US20150319156A1 (en) Independent identity management systems
US20130125226A1 (en) Sso framework for multiple sso technologies
US9467429B2 (en) Identity management with generic bootstrapping architecture
JP2018525722A (ja) リソース駆動動的承認フレームワーク
US20180013782A1 (en) Continuous device/uicc based authentication for lte systems
TW201225697A (en) Identity management on a wireless device
US20190018979A1 (en) Protection of private information through privacy-centric storage and processing
Curie IdeNtity verifiCatiOn with privacy-preservinG credeNtIals for anonymous access To Online services

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant