KR101730459B1 - 로컬 기능을 갖는 아이덴티티 관리 - Google Patents

로컬 기능을 갖는 아이덴티티 관리 Download PDF

Info

Publication number
KR101730459B1
KR101730459B1 KR1020167017358A KR20167017358A KR101730459B1 KR 101730459 B1 KR101730459 B1 KR 101730459B1 KR 1020167017358 A KR1020167017358 A KR 1020167017358A KR 20167017358 A KR20167017358 A KR 20167017358A KR 101730459 B1 KR101730459 B1 KR 101730459B1
Authority
KR
South Korea
Prior art keywords
user
token
access
request
access token
Prior art date
Application number
KR1020167017358A
Other languages
English (en)
Other versions
KR20160079153A (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 KR20160079153A publication Critical patent/KR20160079153A/ko
Application granted granted Critical
Publication of KR101730459B1 publication Critical patent/KR101730459B1/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
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • 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/081—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying self-generating credentials, e.g. instead of receiving credentials from an authority or from another peer, the credentials are generated at the entity itself

Abstract

사용자 장비(UE)는 이를 테면, UE 내에 상주하는 신뢰 모듈 상에서 국부적으로 기능들을 수행할 수 있다. 예를 들어, UE는 예를 들어, 로컬 아이덴티티 제공자 기능을 통해 오픈 연결과 같은 단일 사인-온 프로토콜과 연관된 기능들을 수행할 수 있다. 예를 들어, UE는 아이덴티티 정보 및/또는 사용자 속성들과 같은 사용자 정보를 탐색하기 위해 서비스 제공자에 의해 이용될 수 있는 아이덴티티 토큰들 및 액세스 토큰들을 생성할 수 있다. 사용자 속성들은 네트워크 엔티티 상에 또는 UE 상에 국부적으로 상주할 수 있는 사용자 정보 종단점을 통해 탐색될 수 있다. 서비스 제공자는 그것이 토큰들을 이용하여 탐색하는 정보에 기초하여 서비스에 대한 액세스를 사용자에 승인할 수 있다.

Description

로컬 기능을 갖는 아이덴티티 관리{IDENTITY MANAGEMENT WITH LOCAL FUNCTIONALITY}
관련 출원들에 대한 상호참조
본 출원은 2012년 1월 20일 출원된 미국 가출원 번호 제61/589,125호를 우선권으로 주장하며, 그에 의해 상기 가출원의 내용물들은 그 전체가 인용에 의해 포함된다.
모바일 디바이스들은 점점 인터넷 서비스에 액세스하는데 이용된다. 종종, 인터넷 서비스들은 민감 데이터(sensitive data)를 보호하기 위해 안전 거래를 요구한다. 이러한 보안 조치들은 종종 사용자 이름들, 핀들, 및/또는 패스워드들과 같은 데이터 요건들의 형태로 사용자에게 아이덴티티 및 인증 부담들을 부과한다. 무선 원격통신 네트워크들은 다양한 형태들의 인증을 구현할 수 있다. 서비스 제공자들은 또한 사용자를 인증하고, 사용자를 식별하고 및/또는 웹 서비스에 대한 사용자의 액세스 레벨을 결정하도록 다양한 사용자 속성들을 탐색할 수 있다.
싱글 사인-온(Single sign-on; SSO) 해결책들은 사용자 인증을 사용자에 대해 덜 번잡하게 하는 것을 목적으로 제안되었다. 오픈ID(OpenID) 프로토콜들은 싱글 사인-온을 가능하게 하는 프로토콜의 일 예이다. 오픈ID 2.0 프로토콜 및 보다 최근의 오픈ID 연결 프로토콜은 오픈ID 프로토콜들 중 가장 일반적이다. 이하, 용어 "오픈ID 프로토콜"이 단독으로 사용되면 오픈ID 2.0 및 오픈ID 연결을 포함하는 다양한 형태들의 오픈ID 프로토콜들 중 임의의 것을 커버하는 것으로 의도된다. 특정한 프로토콜이 논의되는 경우, 그것은 구체적으로 식별될 것이다.
종종 오픈ID 프로토콜들과 같은 SSO에 대한 현재의 접근법들은 다양한 SSO 매커니즘들을 구현하기 위해 네트워크 아이덴티티 제공자를 요구한다. 이들 접근법들은 그것이 SSO 아이덴티티 제공자에 의해 처리되면 사용자의 아이덴티티 정보에 관한 사용자 제한 제어를 제공할 수 있고, 보안 공격들에 취약한 사용자 데이터 및 통신들을 초래할 수 있다.
시스템들, 방법들 및 장치 실시예들은 예를 들어, 사용자 장비(UE) 상에서 오픈ID 연결 프로토콜과 연관되는 매커니즘들과 같은 아이덴티티 관리 매커니즘들을 구현하기 위해 본 명세서에서 설명된다. 예시적인 실시예에서, 사용자 장비(UE) 및 서비스 제공자(SP)는 네트워크를 통해 통신할 수 있다. UE의 사용자는 SP에 의해 제공되는 서비스에 대한 액세스를 요청할 수 있다. SP는 UE 및/또는 사용자의 아이덴티티를 인증하기 위해 아이덴티티(ID) 토큰을 요청할 수 있다. UE는 요청에 따라 ID 토큰을 생성할 수 있다. 예를 들어, ID 토큰은 UE 내에 상주하는 신뢰 환경에서 안전하게 생성될 수 있다. 이러한 신뢰 환경은 유니버셜 집적 회로 카드(universal integrated circuit card; UICC), 신뢰 모듈, 안전 환경 등 또는 이들의 임의의 절절한 결합에 의해 구현될 수 있다. UE는 예를 들어, 신뢰 환경을 통해, SP에 ID 토큰을 발행할 수 있다. ID 토큰은 SP에 의해 제공되는 서비스에 대한 UE 액세스를 제공하기 위해 검증될 수 있다. UE는 또한 사용자에 의해 승인되는 인가 요청의 수신에 응답하여 액세스 토큰을 생성할 수 있다. 액세스 토큰은 SP로부터 UE에 의해 요청되는 서비스에 관련될 수 있다. 따라서, 액세스 토큰은 인가 요청의 사용자 승인과 연관될 수 있다. 예를 들어, SP는 예를 들어, 사용자 속성과 같이 사용자에 관한 부가적인 정보를 수신하기 위해 인가 요청을 발행할 수 있다. UE는 SP에 액세스 토큰을 발행할 수 있고, SP는 액세스 토큰의 검증 시에 그것이 요청한 사용자 속성들을 수신할 수 있다. ID 토큰들 및 액세스 토큰들은 오픈ID 연결 프로토콜에 따라 UE에서 생성될 수 있다. 예를 들어, 토큰은 UE 내에 상주하는 신뢰 모듈에서 안전하게 생성될 수 있다.
다른 예시적인 실시예에서, UE는 SP에 의해 요청되는 서비스에 관련되는 액세스 토큰을 준비(provision)할 수 있다. 이러한 액세스 토큰은 요청된 서비스를 제공하도록 SP에 의해 보완(redeem)될 수 있다. UE는 사용자 데이터에 대한 요청의 수신에 응답하여 액세스 토큰을 생성할 수 있다. 액세스 토큰은 사용자 정보 종단점의 위치를 나타내는 정보를 포함할 수 있다. 예를 들어, SP는 사용자 정보 종단점으로부터 사용자 데이터를 검색하도록 위치를 이용할 수 있다. 사용자 정보 종단점은 액세스 토큰의 검증 시에 SP에 요청된 사용자 속성을 제공할 수 있다. 사용자 정보 종단점은 UE 내의 신뢰 모듈, 네트워크를 통해 SP와 통신하는 네트워크 엔티티 또는 이들의 결합 상에 위치될 수 있다. 예를 들어, UE는 UE의 사용자 및 서비스와 연관되는 제 1 액세스 토큰 및 제 2 액세스 토큰을 생성할 수 있다. 제 1 액세스 토큰은 제 1 액세스 토큰의 검증 시에 SP에 제 1 요청된 사용자 속성을 제공하는 제 1 사용자 정보 종단점의 위치를 나타내는 정보를 포함할 수 있다. 제 2 액세스 토큰은 제 2 액세스 토큰의 검증 시에 SP에 제 2 요청된 사용자 속성을 제공하는 제 2 사용자 정보 종단점의 위치를 나타내는 정보를 포함할 수 있다. 제 1 사용자 정보는 예를 들어, 신뢰 모듈 상에서와 같이 UE 상에 위치될 수 있고, 제 2 사용자 정보는 네트워크를 통해 SP와 통신하는 네트워크 엔티티 상에 위치될 수 있다. 예를 들어, 제 1 사용자 정보 종단점에 의해 제공된 제 1 요청된 사용자 속성은 사용자에 의해 기밀 데이터로서 분류될 수 있고 제 2 사용자 정보 종단점에 의해 제공되는 제 2 요청된 사용자 속성은 사용자에 의해 비-기밀 데이터로서 분류될 수 있다. UE/사용자를 서빙하기 위해, SP는 그 각각의 사용자 정보 종단점들로부터 획득되고 상이한 보안 분류들을 갖는 제 1 및 제 2 사용자 속성들을 결합할 수 있다.
대안적인 실시예에서, 액세스 토큰은 SP 외에 또는 추가적으로, 토큰을 수신하는 다른 당사자들에 의해 보완될 수 있다.
보다 상세한 이해는 첨부 도면들과 함께 예로서 주어지는 다음의 설명으로부터 이루어질 수 있다.
도 1은 네트워크의 예시적인 인터페이스들을 예시하는 블록도이다.
도 2는 예시적인 실시예에 따라 HTTP 리디렉트 메시지들을 이용하는 오픈ID 프로토콜의 흐름도이다.
도 3은 오픈ID 연결 프로토콜의 예시적인 구현에 따라 예시적인 발견 프로세스를 예시하는 흐름도이다.
도 4는 구성 정보를 검색하기 위한 예시적인 프로토콜 흐름을 예시하는 흐름도이다.
도 5는 예시적인 등록 프로토콜 흐름을 예시하는 흐름도이다.
도 6은 오픈ID 연결 프로토콜의 예시적인 구현의 흐름도이다.
도 7은 인가 요청을 이용한 예시적인 오픈ID 연결 호 흐름의 흐름도이다.
도 8은 예시적인 실시예에 따라 로컬 토큰 생성에 관한 예시적인 호 흐름의 도면이다.
도 9는 예시적인 실시예에 따라 미리-설정된 공유 시크릿(S)을 공유하는 로컬 OP와의 예시적인 프로토콜 흐름의 흐름도를 도시한다.
도 10은 예시적인 실시예에 따라 사용자 정보 종단점이 UE 상에 국부적으로 상주하는 오픈ID 프로토콜의 호 흐름이다.
도 11은 예시적인 실시예에 따라 사용자 데이터가 국부적으로 저장되고 사용자 데이터가 네트워크 엔티티 상에 저장되는 오픈ID 프로토콜의 호 흐름이다.
도 12a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 통신 시스템의 시스템도이다.
도 12b는 도 12a에서 예시되는 통신 시스템 내에서 이용될 수 있는 예시적인 무선 송/수신 유닛(WTRU)의 시스템도이다.
도 12c는 도 12a에서 예시된 통신 시스템 내에서 이용될 수 있는 예시적인 라디오 액세스 네트워크 및 예시적인 코어 네트워크의 시스템도이다.
다음의 상세한 설명은 예시적인 실시예들을 예시하도록 제공되며, 본 발명의 범위, 응용성 또는 구성을 제한하도록 의도되는 것은 아니다. 다양한 변경들이 본 발명의 사상 및 범위로부터 벗어남 없이 엘리먼트들 및 단계들의 기능 및 배열에서 이루어질 수 있다.
사용자 및/또는 사용자 장비(UE)의 아이덴티티(identity)를 관리하기 위한 다양한 방법들 및 시스템들이 본 명세서에서 설명된다. 본 명세서에서의 실시예들이 오픈ID 연결 프로토콜의 맥락에서 설명될 수 있지만, 실시예들은 오픈ID 연결 프로토콜을 구현하는 것으로 제한되지 않고, 예를 들어, 다른 싱글 사인-온(single sign-on; SSO) 프로토콜들 및/또는 연합 아이덴티티 프로토콜들을 구현할 수 있다. 유사하게, 오픈ID 엔티티들이 본 명세서에서 참조로서 이용될 수 있지만, 실시예들은 오픈ID 엔티티들로 제한되지 않고, 오픈ID 엔티티들은 오픈ID 엔티티들과 동일하거나 유사한 기능들을 수행하는 다른 엔티티들로 확장 가능할 수 있다. 예를 들어, 본 명세서에서 이용되는 바와 같이, 의존자(relying party; RP) 및 클라이언트란 용어들은 서비스 웹사이트와 같은 서비스 제공자(서비스 제공자; SP)를 지칭할 수 있다. 오픈ID 아이덴티티 제공자(OpenID identity provider; OP) 및 인가 서버란 용어들은 네트워크 아이덴티티 제공자(network identity provider; IdP) 또는 인증 종단점(authentication endpoint; AEP)을 지칭할 수 있다. 사용자 장비(user equipment; UE)란 용어는 본 명세서에서 추가로 설명되는 바와 같이 임의의 적절한 무선 송/수신 유닛(transmit/receive unit; WTRU)을 지칭할 수 있다.
일 예시적인 실시예에서, 인증 종단점(예를 들어, OP 서버)의 인증 기능은 UE 내에 상주하는 로컬 보안 모듈에 의해 구현될 수 있다. 예를 들어, 모바일 디바이스의 로컬 에이전트(예를 들어, 보안 모듈, 신뢰 모듈 등과 같은 신뢰 환경(trusted environment))는 네트워크 측 아이덴티티 제공자에 대한 프록시로서 작동할 수 있다. 로컬 보안 모듈은 UE의 종단 사용자를 인증 및/또는 인가할 수 있는 기능들을 수행하는데 이용될 수 있다. 로컬 보안 모듈은 로컬 아이덴티티 제공자로서 지칭될 수 있고, 예를 들어, 오픈ID 연결과 같은 오픈ID 프로토콜에 기초하여 종단 사용자를 인증하는데 이용될 수 있다. 로컬 오픈ID란 용어는 SSO 및/또는 아이덴티티 관리의 구현이 예를 들어, 오픈ID 연결과 같은 오픈ID 프로토콜에 따르는 로컬 SSO 구현들의 서브세트를 표시하는데 이용될 수 있다. 예를 들어, 로컬 오픈ID는 국부적으로 위치된 엔티티 또는 신뢰 환경에 의해 수행될 수 있는 OP의 기능을 표시하는데 이용될 수 있다. 로컬 OP는 디바이스 상에서 국부적으로 오픈ID 서버(예를 들어, 인가 서버)의 기능들 또는 기능들의 서브세트를 수행하는 엔티티 또는 모듈을 표시하는데 이용될 수 있는 용어이다.
로컬 OP는 예시적인 실시예에 따라 토큰들에 기초하는 프로토콜 흐름들을 활용할 수 있다. 이러한 토큰들은 SP(예를 들어, RP)에 발행될 수 있다. 토큰들은 아이덴티티 제공자로부터 및/또는 사용자 정보 종단점들로부터 사용자에 대한 정보(예를 들어, 속성들)를 검색하는데 이용될 수 있다. 본 명세서에서 이용된 바와 같이, 사용자 속성은 사용자와 연관되는 임의의 정보 엘리먼트를 지칭할 수 있다. 예시적인 사용자 정보(예를 들어, 속성들)는 제한 없이, 사용자의 나이 및 주소를 포함하며, 이러한 속성들은 토큰들을 이용하여 SP에 의해 검색될 수 있다. 예를 들어, SP는 정보를 전달하는 토큰들 없이 토큰들을 이용하여 정보를 검색할 수 있다.
본 명세서에서 설명되는 실시예들은 인증을 위해 토큰들을 이용할 수 있다. 예를 들어, URL들 및/또는 이메일 어드레스들과 같은 다양한 식별자들이 이용될 수 있다. 예를 들어, 오픈ID 연결과 같은 인증 프로토콜들은 사용자 속성들 및/또는 아이덴티티 정보의 안전한 교환을 용이하게 할 수 있다.
도 1은 예시적인 실시예에 따른 예시적인 통신 인터페이스들을 예시하는 블록도를 도시한다. UE(100)와 같은 모바일 디바이스는 공개 인터넷 상에서 직접 어드레싱됨 없이 인터넷에 연결될 수 있다. 예시적인 시나리오에서, UE(100) 및 UE(100) 상에서 실행되는 서비스들 및/또는 애플리케이션들은 예를 들어, 웹 서비스 제공자(102)와 같은 외부 엔티티들에 의해 도달될 수 없을 수 있다. 예를 들어, 로컬 OP(104)와 같은 UE(100) 상의 로컬 서비스들은 UE(100) 상의 브라우저(106)를 통해 및/또는 모바일 네트워크 운용자(mobile network operator; MNO)(108)의 관리 백-엔드 시스템에 의해 도달될 수 있다. 로컬 서비스들은, 예를 들어, 로컬 OP(104)가 MNO(108)에 의해 발행되고 SIM 카드 상에 설치되는 경우, 오버-디-에어(over-the-air; OTA) 관리를 통해 액세스될 수 있다. 예를 들어, 서비스 제공자(102)와 같은 몇몇 웹 서비스들은 UE(100) 상에서 실행되는 서비스들과 직접 통신할 수 있다.
UE(100)가 MNO 네트워크(108)를 통해 인터넷에 연결되는 예시적인 구성에서, 예시적인 통신 경로들/인터페이스들은 도 1의 예시되는 실시예에 따라 식별될 수 있다. 인터페이스(IF)(112)에서, UE(100)의 브라우저(106)는 예를 들어, HTTP(들) 요청들을 이용함으로써 웹-기반 서비스(예를 들어, SP(102))에 접촉할 수 있다. SP(102)는 HTTP 요청들에 대답(answer)하고 및/또는 브라우저(106)에 응답을 전송한다. 예시적인 시나리오에서, SP(102)는 요청을 수신하기 이전에 브라우저(106)와의 통신을 개시할 수 없을 수 있다. IF(114)가 브라우저(106) 및 내부 로컬 OP(104)에 대해 이용 가능할 수 있다. 브라우저(106)는 예를 들어, 자바 애플릿, 자바스크립트 위젯, OS API 등과 같은 미들웨어 소프트웨어 엔티티를 통해 및/또는 HTTP(들)을 통해 UE(100) 내에 상주하는 로컬 OP(104)와 통신할 수 있다. 로컬 OP(104)는 예를 들어, HTTP 응답으로 브라우저, 애플리케이션 및/또는 API로부터의 요청에 응답할 수 있다. 예시적인 구성에서, 로컬 OP(104)는 요청을 수신하기 이전에 브라우저와의 통신을 개시할 수 없을 수 있다.
IF(116)는 백-채널로서 지칭될 수 있다. 백 채널(116)을 이용하여, SP(102)는 (예를 들어, HTTP를 이용하여) IdP 서버(110)에 접촉하고 및/또는 IdP 서버(110)는 (예를 들어, HTTP를 이용하여) 서비스 제공자들(102)에 접촉할 수 있다. IF(116)를 통한 통신은 브라우저(106) 또는 사용자의 디바이스(100)를 수반하지 않고 발생할 수 있다. IF(118)는 IdP(110) 및 MNO 네트워크(108)에 대해 이용가능할 수 있다. 도 1에서 점선 타원에 의해 표시된 바와 같이, IdP(110)는 자립형일 수 있거나 MNO 네트워크(108)의 부분일 수 있다. IdP 서버(110)는 (예를 들어, HTTP 및/또는 사유 인터페이스들을 이용하여) MNO 네트워크(108)의 내부 엔티티들에 의해 도달될 수 있다. IdP 서버(110)는 MNO 네트워크(108)의 내부 엔티티들과 통신할 수 있을 수 있다. 예시적인 구성에서, IdP 서버(110)가 MNO 네트워크(108)의 내부 엔티티들과 통신할 수 있는지 여부는 MNO 방화벽 규칙들 및/또는 정책들에 의존할 수 있다. IF(120)는 오버-디-에어(over-the-air; OTA) 관리 인터페이스(120)로서 지칭될 수 있다. OTA 인터페이스(120)는 MNO 네트워크(108) 및 로컬 OP(104)에 대해 이용 가능할 수 있다. 예를 들어, MNO 네트워크(108)의 엔티티들은 UICC/SIM 카드 상의 애플리케이션과 통신하기 위해 OTA 관리 인터페이스(120)를 이용할 수 있다. 로컬 OP(104)의 애플리케이션으로부터 MNO 네트워크(108) 상의 엔티티들로의 연결들은 MNO 방화벽 규칙들의 대상일 수 있다. IF(122)는 예를 들어, 로컬 OP(104) 및/또는 IdP(110)의 애플리케이션의 소유권에 의존하여 로컬 OP(104) 및/또는 IdP 서버(110)에 대해 이용 가능하지 않을 수 있다. 예를 들어, IF(122)의 양자의 엔티티들(예를 들어, 로컬 OP(104) 및 IdP(110)) 간의 직접 통신 채널(예를 들어, SMS, OTA 등을 이용함)은, 양자의 엔티티들이 MNO로부터 동의되고 및/또는 MNO에 의해 동작되고 및/또는 소유될 때 설정될 수 있다. 예시적인 구성에서, MNO는 IF(122)에서의 통신 채널을 인에이블할 수 있다. 통신 IF(124)는 SP(102)와 로컬 OP(104) 간에 이용 가능하지 않을 수 있다. 서비스 제공자(102)로부터 UE(100) 또는 UE(100) 상에서 실행되는 로컬 OP 서비스(104)로의 직접 통신은 예를 들어, UE(100)가 공개적으로 어드레싱 가능하지 않을 때 이용가능하지 않을 수 있다. IF(126)는 브라우저(106) 및 IdP(110)에 대해 이용 가능할 수 있다. 예를 들어, 브라우저(106)는 HTTP 요청들을 통해 IdP(110)에 도달할 수 있다. IdP 서버(110)는 브라우저(106)의 HTTP 요청들에 응답할 수 있다.
예를 들어, IF(122)를 통해 통신하는 능력과 같은 인터페이스 가용성은 통신 종단점들 및/또는 종단점들 간의 통신 경로의 제어에 의존할 수 있다. 예시적인 구성에서, IF(122)는 OP(110) 및 로컬 OP(104)가 MNO의 제어 하에 있고 OP(110)와 로컬 OP(104) 간의 통신이 SP(102)와 로컬 OP(104) 간의 물리적 통신 경로를 통해 실현될 때 이용 가능할 수 있다.
예시적인 실시예에서, 로컬 OP(104)는 SP(102)에 토큰들을 발행할 수 있다. 토큰들은 SP(102)에 의해, 네트워크 IdP/OP(110)로 제공될 수 있다. 이러한 토큰들은 데이터를 검색하는데 이용될 수 있다. SP(102)가 로컬 OP(104)에 토큰을 제공하기 위한 통신 인터페이스가 이용 가능하지 않은 예시적인 구성에서, 네트워크 IdP/OP(110)는 토큰이 적법한 로컬 OP(104)에 의해 발행되었다고 검증할 수 있다. IdP/OP(110)는 또한 토큰이 유효한지를 결정할 수 있다. 예를 들어, 토큰이 유효한지를 결정하는 것은 토큰이 만료하지 않았음을 검증하는 것을 포함할 수 있다.
도 1을 계속 참조하면, SP(102)로부터 로컬 OP(104)로의 간접 통신은 예를 들어, 리디렉트 메시지들에 의해, UE(100)의 브라우저(106)를 통해 발생할 수 있다. SP(102)는 브라우저(106)에 리디렉트하도록 URL을 포함하는 HTTP 3xx 메시지를 전송할 수 있다. 예를 들어, 오픈ID 프로토콜에 따라, URL은 IdP 인증 종단점(AEP)에 대응하는 URL일 수 있다. IdP 인증 종단점은 예를 들어, 발견 매커니즘을 통해 SP(102)에 알려질 수 있다. UE(100)는 URL을 AEP의 서버의 인터넷 프로토콜(IP) 어드레스로 분해(resolve)할 수 있다. 예를 들어, UE(100) 상에 설치되는 로컬 OP(104)를 갖는 UE(100)는 URL을 로컬 OP 서버(104)의 로컬 IP 어드레스로 분해할 수 있다.
도 2는 예시적인 HTTP 리디렉트 메시지들을 예시하는 흐름도이다. 도 2의 정보 흐름들은 오픈ID 프로토콜을 구현할 때 이용될 수 있는 간접 통신으로 구현될 수 있다. UE의 브라우저(202)는 SP(204)에 의해 제공되는 서비스에 대한 액세스를 요청함으로써 SP(204)와의 통신을 개시할 수 있다. 요청은 서비스에 액세스하기 위한 HTTP 요청을 포함할 수 있다. 206에서, SP(204)는 요청에 응답할 수 있고, 206에서 리디렉트 메시지의 부분으로서 로컬 OP(200)에 데이터를 전송할 수 있다(예를 들어, 데이터는 HTTP 메시지의 파라미터들 내에서 전달될 수 있음). 208에서, 브라우저(202)는 로컬 OP(200)의 로컬 어드레스를 분해할 수 있다. 브라우저(202)는 예를 들어, 210에서 메시지를 전송함으로써 로컬 OP(200)으로 206에서 자신이 수신한 리디렉트 메시지를 따를 수 있다. 예를 들어, 브라우저(202)는 DNS 룩업 및/또는 헬퍼 소프트웨어(예를 들어, 자바 애플릿)에 대한 수정을 통해 리디렉트를 따를 수 있다. 예를 들어, URL/어드레스의 DNS 분해(resolution)는 호스트 파일을 통해 발생할 수 있고 및/또는 자바 애플릿 서플리컨트(Java applet supplicant)에 의해 용이하게 될 수 있다. 212에서, 로컬 OP 동작들이 발생할 수 있다. 예를 들어, 212에서, UE의 사용자는 UE를 통해 인증될 수 있다. 214 및 216에서, 로컬 OP(200)는 예를 들어, 브라우저(202)로부터 SP(204)에 전송(216에서)할 수 있는 다른 리디렉트를 통해 정보를 SP(204)에 전달(214에서)할 수 있다. 정보 및/또는 데이터는 HTTP 메시지의 파라미터들 내에서 전달될 수 있다. 예시적인 구성에서, SP(204)로부터 로컬 OP(200)로의 직접 통신은 이용 가능하지 않을 수 있다.
오픈ID 연결 프로토콜은 예를 들어, 브라우저-기반, 모바일 및/또는 자바스크립트 클라이언트와 같은 다양한 타입들의 클라이언트들이 아이덴티티 및 인증 세션에 관한 정보를 요청 및 수신하는 것을 가능하게 한다. 오픈ID 연결의 다양한 예시적인 구현들에서, 아이덴티티 데이터는 암호화될 수 있고, OP는 발견될 수 있고 진보된 세션 관리(예를 들어, 로그아웃)이 인에이블될 수 있다. 오픈ID 연결의 예시적인 구현에서, 사용자 식별자는 이메일 어드레스들 및/또는 URL들에 기초할 수 있다. 서비스 제공자는 예를 들어, 인가가 (예를 들어, OAuth 기반 호 흐름을 통해) 사용자로부터 획득될 때 사용자 소유 콘텐츠 및/또는 프로파일 데이터에 액세스하도록 허용될 수 있다.
오픈ID 2.0 프로토콜의 예시적인 구현에 따라, 클라이언트 시크릿(예를 들어, 아이덴티티 제공자(IdP/OP)와 SP/클라이언트 간의 공유 시크릿)이 각각의 사용자에 대해(예를 들어, 인증 프로토콜 실행 마다) 설정될 수 있다. 공유 시크릿은 발견 프로세스 동안 OP와 서비스 간에 설정될 수 있다. 예를 들어, 공유 시크릿은 장기 시크릿으로부터 유도될 수 있고 및/또는 이것은 로컬 OP 인스턴스에 의해 계산될 수 있다. 오픈ID 연결 프로토콜의 예시적인 구현에 따라, 클라이언트 시크릿은 토큰들을 포함할 수 있다. 예를 들어, 아이덴티티(ID) 토큰은 OP에 의해 서명될 수 있고, 클라이언트는 (예를 들어, OP 제공 토큰 종단점의 도움으로) 토큰을 검증할 수 있고 및/또는 클라이언트는 스스로 토큰 서명을 검증할 수 있다. 예시적인 실시예에서, OP는 발견 및/또는 등록 프로세스들 동안 키들(keys)을 제공할 수 있다. 등록은 예를 들어, 발견 이후에 클라이언트와 OP 간에 수행될 수 있다. 예시적인 구성에서, 등록 프로토콜 단계들은 사용자에 특유하지 않을 수 있다. 예를 들어, 키들은 토큰들을 서명하는데 이용될 수 있고 키들은 다수의 사용자들에 대한 일반 키들일 수 있다. 예시적인 실시예에서, 토큰들 및 그들의 서명들은 로컬 OP에 의해 생성될 수 있다. 예를 들어, 키들은 로컬 OP에 대해 이용 가능할 수 있고, OP는 서명들을 생성하도록 키를 이용할 수 있다.
도 3은 오픈ID 연결의 예시적인 구현에 따른 예시적인 발견 프로세스를 도시한다. SP로서 지칭될 수 있는 클라이언트(300)는 예를 들어, 오픈ID 아이덴티티 제공자(302)의 종단점 URL들과 같은 정보를 탐색할 수 있다. 다수의 사람들이 원하는 정보(sought-after information)를 획득하는 프로세스는 발견(discovery)으로서 지칭될 수 있다. SP는 (예를 들어, 대역외(out-of-band) 매커니즘을 통해) 제공자 정보를 알 수 있고, 이에 따라 오픈ID 프로토콜의 예시적인 구현에 따라 발견을 스킵(skip)할 수 있다. 다른 예시적인 구현에서, 클라이언트(300)는 단순 웹 발견(simple web discovery; SWD)을 이용하여 정보를 발견할 수 있다. SWD에서, 예를 들어, UE의 사용자는 306에서, 사용자의 식별자를 클라이언트(300)에 공급할 수 있다. 사용자는 프린스펄(principal)로서 지칭될 수 있다. 306에서, 클라이언트(300)는 식별자의 호스트를 식별할 수 있다. 호스트는 SWD 서비스를 호스팅하는 서버를 지칭할 수 있다. 프린스펄 및/또는 호스트 정보는 예를 들어, 식별자에서 종단-사용자에 의해 제공될 수 있다. 식별자는 예를 들어, XRI, 이메일, URL 등일 수 있다. 306에서, 클라이언트(300)는 프린스펄 및/또는 호스트를 결정하기 위해 사용자 공급 식별자 상에서 정규화 및/또는 추출 규칙들을 적용할 수 있다. 도 3을 참조하면, 예를 들어, 프린스펄은 이메일을 지칭할 수 있고, 호스트는 제공된 이메일 어드레스에서 '@'의 우측의 모든 것을 지칭할 수 있다. 클라이언트(300)는 308에서 HTTP GET 요청을 이용하여 제공자(302)로부터 위치(예를 들어, URL)를 요청할 수 있다. 310에서, OP(302)는 예를 들어, 인증 종단점들 및/또는 인가 종단점들의 어드레스들과 같은 위치 정보를 포함하는 정보를 리턴(return)할 수 있다.
발견의 부분으로서, 클라이언트(300)는 구성 정보를 검색할 수 있다(예를 들어, 도 4 참조). 400에서, 클라이언트(300)는 구성 정보를 요청할 수 있다. 이러한 구성 정보는 오픈ID 제공자(302)에서(예를 들어, JSON 문서를 가리킬 수 있는 URL well-known/openid-configuration에서) 이용 가능할 수 있다. 통신은 TLS를 이용하여 안전해질 수 있다. 요청에 대한 응답으로, 402에서, 오픈ID 제공자(302)는 오픈ID 제공자(302)의 구성에 관한 속성들(예를 들어, 정보)을 포함할 수 있는 JSON 문서를 리턴할 수 있다. 정보는 예를 들어, 공개 키 위치 정보 및/또는 종단점들에 관한 정보를 포함할 수 있다. 예를 들어, 종단점 정보는 인증 및/또는 인가 종단점의; 토큰 종단점의; 사용자 정보(User Info) 종단점의; 및/또는 체크 ID 종단점의 URL들을 포함할 수 있다. JSON Web Key 문서는 제공자의 JSON Web Key(JWK) 문서의 URL을 포함할 수 있다. JWK 문서는 공개 키들의 세트를 제공할 수 있는 JSON 구조가 될 수 있다. 이러한 키들은 JSON 웹 토큰들(예를 들어, ID 토큰들)에 서명하는데 이용될 수 있다.
도 5는 오픈ID 연결 프로토콜의 예시적인 구현에 따른 예시적인 등록 프로세스를 도시한다. 클라이언트(300)는 예를 들어, 클라이언트 ID 및/또는 클라이언트 시크릿을 획득하기 위해 오픈ID 제공자(302)에 등록할 수 있다. 500에서, 클라이언트(300)는 제공자(302)의 발견된 등록 종단점에 요청을 발행할 수 있다. 502에서, 응답이 클라이언트(300)에 발행될 수 있다. 응답은 JSON 문서를 포함할 수 있다. JSON 문서는 클라이언트ID 및/또는 클라이언트 시크릿을 포함할 수 있다. TLS는 통신들을 안전하게 하는데 이용될 수 있다.
도 5를 계속 참조하면, 클라이언트 시크릿은 클라이언트/SP(300)와 IdP(302) 간의 등록 동안 설정될 수 있다. 클라이언트 시크릿은 인가 코드 흐름을 수행하기를 원할 수 있는 클라이언트들에 대한 인증 크리덴셜(authentication credential)로서 이용될 수 있다. 인가 코드 흐름에서, 클라이언트는, 예를 들어, 클라이언트가 액세스 토큰을 요청할 때 또는 클라이언트가 액세스 토큰을 리프레시(refresh)하기를 원할 때 제공자의 토큰 종단점에 대해 인증하는데 클라이언트 시크릿을 이용할 수 있다. 예시적인 구현에 따라, HMAC 서명은 ID 토큰을 서명하는데 이용될 수 있다. 이러한 구현에서, 클라이언트 시크릿은 서명 키로서 이용될 수 있다. RP는 예를 들어, HMAC가 서명 매커니즘으로서 이용되는 경우 토큰 서명들을 검증하기 위해 그의 저장된 클라이언트 시크릿을 이용하도록 시도할 수 있다. 예를 들어, HMAC 대칭 서명들은 로컬 OP와 함께 이용될 수 있다. 로컬 OP는 예를 들어, HMAC 서명을 생성하기 위해 SP에 대한 클라이언트 시크릿을 알 수 있다.
등록은 사용자가 클라이언트에 로그 인할 때 수행될 수 있거나 수행되지 않을 수 있다. 오픈ID 연결 프로토콜의 예시적인 구현에서, 클라이언트 시크릿은 서비스 및 IdP 마다 설정될 수 있어서, 서비스는 IdP와 더불어 그 자신의 클라이언트 시크릿을 가질 수 있다. 오픈ID 2.0 프로토콜의 예시적인 구현에서, 연관 시크릿이 서비스와 IdP 간의 각각의 사용자 인증 프로세스에 대해 생성될 수 있다. 연관 시크릿은 예를 들어, 아이덴티티 어서트 메시지(identity assertion message)에 서명하는데 이용될 수 있고, 클라이언트는 서명을 검증할 수 있다. 예시적인 오픈ID 연결 구현에서, 클라이언트 시크릿은 클라이언트 인증 크리덴셜일 수 있다. 따라서, 연관 시크릿의 역할은 ID 토큰 상의 서명에 의해 구현될 수 있다. ID 토큰 상의 서명은 예를 들어, 제공자 JWK 키를 이용하여 생성될 수 있다.
오픈ID 연결 프로토콜의 예시적인 구현에 따라, 발견 및 등록 프로세스들은 네트워크 상에서 SP와 IdP 간에 발생할 수 있어서, 두 엔티티들 간에 교환되는 클라이언트 시크릿들 및/또는 다른 정보의 가용성은 SP와 네트워크 IdP로 제한될 수 있다.
오픈ID 연결 프로토콜의 다양한 예시적인 구현들에서, ID 토큰은 OAuth 액세스 토큰으로서 작동할 수 있다. 예를 들어, ID 토큰은 예를 들어, 사용자 식별자와 같이 인증 데이터를 위해 OP에서 교환될 수 있다. ID 토큰은 인코딩된 데이터를 전달(carry)할 수 있다. 액세스 토큰에 대한 요청들은 서비스 제공자가 사용자 식별자 및/또는 부가적인 프로파일 데이터(예를 들어, 주소, 나이 등과 같은 사용자 속성들)에 액세스하도록 허용할 수 있다. ID 토큰의 데이터 포맷은 예를 들어, JSON 데이터를 포함할 수 있는 JWT일 수 있다.
본 명세서에서 설명되는 실시예들은 예를 들어, ID 토큰들 및/또는 액세스 토큰들과 같은 다양한 토큰 타입들을 이용할 수 있다. 이러한 토큰들은 오픈ID 연결 프로토콜에 따라 구현될 수 있다. 예를 들어, ID 토큰들은 인증 이벤트에 관한 정보를 포함할 수 있고, 사용자가 IdP에서 인증되었음을 서비스 제공자들이 검증하는 것을 가능케 할 수 있다. 검증을 가능하게 하기 위해, 예를 들어, ID 토큰들은 인코딩된 데이터를 포함할 수 있다. 액세스 토큰은 예를 들어, OAuth 베어러 토큰일 수 있다. 액세스 토큰은 수신 서비스가 (예를 들어, 사용자 인포 종단점에서) 토큰을 보완(redeem)하도록 허용할 수 있다. 서비스 제공자는 예를 들어, 사용자 정보(예를 들어, 사용자 속성들/요구들)를 수신하도록 액세스 토큰을 보완할 수 있다. 서비스 제공자는 사용자들을 인증하도록 ID 토큰을 이용할 수 있다. 예시적인 실시예에서, 서비스는 ID 토큰에 포함되지 않은 부가적인 데이터를 검색하도록 액세스 토큰을 요청할 수 있다. 예를 들어, 서비스 제공자는 종단점으로부터 데이터를 획득하도록 액세스 토큰을 요청할 수 있다.
ID 토큰은 오픈ID 연결 프로토콜의 예시적인 구현에 따라 JWT 포맷일 수 있다. JWT는 예를 들어, 사용자의 실제 인증의 JSON 속성들을 포함할 수 있다. 예를 들어, ID 토큰은 JWT로서 인코딩될 수 있는 다음의 데이터를 포함할 수 있다:
iss - 이것은 응답의 발행자의 고유한 식별자를 지칭할 수 있다;
user_i - 이것은 클라이언트에 의해 소비되도록 의도될 수 있는, 사용자에 대한 국부적으로 고유하고 및/또는 결코 재할당되지 않은 식별자(예를 들어, 24400320 또는 AItOawmwtWwcT0k5lBayewNvutrJUqsvl6qs7A4)를 지칭할 수 있다. 이것은 예시적인 구현에 따라 길이가 255 ASCII 문자들을 초과하지 않을 수 있다;
aud - 이것은 ID 토큰의 의도된 청중(audience)을 지칭할 수 있다. 예를 들어, "aud"는 RP의 OAuth client_id일 수 있다;
exp - 이것은 정수를 포함할 수 있고 및/또는 만료 시간을 식별할 수 있으며, 이 만료시간에 또는 그 이후에 ID 토큰은 프로세싱을 위해 수락될 수 있다. 이 파라미터의 프로세싱은 현재 날자/시간이 값으로 나열되는 만료 날자/시간 이전에 있는지에 의존할 수 있다. 예를 들어, 구현자들은 예를 들어, 클록 스큐(clock skew)를 고려하기 위해 재량(leeway)을 제공할 수 있다. 값은 원하는 날자/시간 때까지 UTC에서 측정되는 바와 같이 1970-01-01T0:0:0Z로부터 다수의 초들일 수 있다;
iso29115 - 이것은 엔티티 인증 보증을 제공할 수 있다. 예를 들어, 이 데이터 파라미터는 수행된 인증의 엔티티 인증 보증 레벨을 특정할 수 있다;
nonce - 인가 요청이 nonce 요청 값을 포함하는 경우, 이 값은 요청 값과 동일한 값으로 세팅될 수 있다.
다음은 오픈ID 연결 프로토콜의 예시적인 구현에 따라 ID 토큰의 예시적인 콘텐츠들을 예시한다. 예시적인 ID 토큰은 클라이언트로부터 CheckID 종단점으로 전송될 수 있다. 아래의 이 섹션은 예시적인 토큰을 비롯해서, 서비스로부터 종단점으로의 예시적인 요청을 도시한다:
POST /id_token HTTP/1.1
호스트: server.example.com
콘텐츠-타입: application/x-www-form-encoded
id_token=eyJ0eXAiOiJKV1QiL
다음의 섹션은 종단점에 의해 서비스 제공자에게 리턴될 수 있는 바와 같은 예시적인 토큰의 (JSON) 콘텐츠들의 예를 도시한다:
HTTP/1.1 200 OK
콘텐츠-타입: application/json
{
"iss": "http://server.example.com",
"user_id": "248289761001",
"aud": "http://client.example.com",
"exp": 1311281970
}
예시적인 토큰은 JSON 웹 서명(JSON Web Signature; JWS) 및/또는 JSON 웹 암호화(JSON Web Encryption; JWE)를 이용하여 암호화될 수 있다. 서명 및/또는 암호화를 위해 이용되는 키들은 예를 들어, JSON Web Key들일 수 있다.
JWT의 속성들은 JSON 객체로서 인코딩될 수 있다. JWT는 컴포넌트들의 결합을 갖는 스트링(string)일 수 있다. 예시적인 컴포넌트들은 JWT 헤더 세그먼트, JWT 속성 세그먼트 및 JWT 암호(crypto) 세그먼트를 포함한다. JWT 헤더 세그먼트는 헤더 및 속성 세그먼트에 적용되는 암호 동작들을 설명하는 base64url* 인코딩 JSON을 포함할 수 있다. JWT 속성 세그먼트는 속성들을 인코딩하는 base64url* 인코딩된 JSON 객체를 포함할 수 있다. JWT 암호 세그먼트는 JWT 헤더 및 속성 세그먼트들의 콘텐츠들을 안전하게 하는 base64url* 인코딩된 암호 자료를 포함할 수 있다. 예시적인 base64 인코딩은 트레일링 '=' 문자들을 제거할 수 있다.
오픈ID 연결 프로토콜의 예시적인 구현에서, 토큰들에 관한 서명들은 유효한 JSON 웹 토큰 서명(Web Token Signature; JWS)들일 수 있다. JWS를 이용한 서명된 토큰들은 서명 알고리즘에 관한 정보를 포함하는 헤더를 가질 수 있고 및/또는 서명을 위해 이용되는 키들에 대한 포인터들을 포함할 수 있다. JWS에 대한 서명 알고리즘은 다음의 알고리즘들을 포함할 수 있지만, 실시예들은 다음의 서명 알고리즘들로 제한되지 않는다:
HS256 SHA-256 해시 알고리즘을 이용하는 HMAC;
HS384 SHA-384 해시 알고리즘을 이용하는 HMAC;
HS512 SHA-512 해시 알고리즘을 이용하는 HMAC;
RS256 SHA-256 해시 알고리즘을 이용하는 RSA;
RS384 SHA-384 해시 알고리즘을 이용하는 RSA;
RS512 SHA-512 해시 알고리즘을 이용하는 RSA;
ES256 P-256 곡선 및 SHA-256 해시 알고리즘을 이용하는 ECDSA;
ES384 P-384 곡선 및 SHA-384 해시 알고리즘을 이용하는 ECDSA; 및/또는
ES512 P-521 곡선 및 SHA-512 해시 알고리즘을 이용하는 ECDSA.
위에서 도시된 바와 같이, 상이한 키 타입들은 예를 들어, 선택된 서명 알고리즘에 기초하여 지원될 수 있다. 예시적인 구현에서, RP는 스스로 ID 토큰 상의 서명을 검증하도록 선택할 수 있어서, RP는 검증 키들을 알 필요가 있을 수 있다. 키들에 대한 포인터는 헤더의 부분일 수 있다. 예를 들어, 포인터는 JSON 인코딩 공개 키들의 세트를 가리키는 URL을 포함할 수 있는 jku(예를 들어, JSON Web Key URL) 파라미터일 수 다. 예시적인 구현에서, x5u 파라미터는 x.509 공개키 인증서 또는 인증서 체인(예를 들어, 키들에 대응함)을 가리키는 URL을 포함할 수 있다. 헤더 파라미터들은 토큰 및 토큰 서명을 생성하는 엔티티에 의해 세팅될 수 있다. HMAC 서명이 ID 토큰을 서명하는데 이용되는 경우, 클라이언트 시크릿은 서명 키로서 이용될 수 있다. 예시적인 액세스 토큰은 예를 들어, OAuth 베어러 토큰일 수 있다. 예시적인 액세스 토큰은 예를 들어, 사용자 정보(예를 들어, 아이덴티티 속성들 및/또는 사용자 정보)를 획득하기 위해 사용자 인포 종단점에서 이용될 수 있다.
서비스 제공자들(클라이언트들)은 ID 토큰들의 검증을 독립적으로 수행할 수 있다. 예를 들어, 클라이언트들은 발행 IdP 서버에 접촉함 없이 토큰들을 검증할 수 있다. 검증을 위한 키 재료는 발견 프로세스에서(예를 들어, JSON Web Key URL 파라미터에서) 클라이언트에 의해 수신될 수 있다.
예시적인 실시예에 따라, 서비스 제공자들은 오파크 값(opaque value)들로서 ID 토큰들을 취급할 수 있고 검증을 위해 이들을 체크 ID 종단점에 제출할 수 있다. 이러한 실시예에서, 서비스 제공자들은 체크 ID 종단점으로부터 사용자 인증에 관한 정보를 수신할 수 있다. ID 토큰 상의 서명 및/또는 암호화는 예를 들어, JSON Web Key를 이용할 수 있다. 키는 등록 및/또는 공개 키(예를 들어, x5u 헤더 파라미터에서 참조됨)에서 JSON Web Key 파라미터를 통해 클라이언트에 대해 이용 가능할 수 있다.
도 6은 오픈ID 연결 프로토콜의 예시적인 구현에 따라 예시적인 호 흐름을 도시한다. 도 6의 예시적인 호 흐름은 예를 들어, 공유 시크릿을 OP(예를 들어, 인가 서버(604))에 등록하지 않은 서비스 제공자들(예를 들어, 클라이언트(602))에 의해 이용될 수 있다. 서비스 제공자가 공유 시크릿을 아이덴티티 제공자에 등록하지 않는 예시적인 오픈ID 연결 구현에서, 서비스 제공자는 도 6의 610에서 도시된 바와 같이 아이덴티티 제공자로부터 ID 토큰을 직접 요청할 수 있다.
서비스 제공자가 공유 시크릿을 아이덴티티 제공자에 등록한 다른 오픈ID 연결 구현에서, 서비스 제공자는, 서비스 제공자가 토큰 대신 안전한 인가 코드를 수신할 수 있은 인가(auth) 코드 흐름(도 7 참조)을 따를 수 있다. auth 코드는 예를 들어, 아이덴티티 제공자에서 ID 토큰을 위해 교환될 수 있다. 서비스 제공자는 ID 토큰에 대한 auth 코드를 보완할 때 서비스 제공자를 인증하기 위해 미리-설정된 공유 시크릿(예를 들어, 아이덴티티 제공자와 더불어)을 이용할 수 있다.
도 6을 재차 참조하면, 클라이언트(602)는 사용자/UE(600)가 클라이언트(602)에 의해 제공된 서비스에 대한 액세스를 요청할 때 시크릿을 인가 서버(604)에 등록하지 않았을 수 있다. 606에서, 사용자(600)는 예를 들어, 이메일 어드레스와 같이 오픈ID 식별자를 이용함으로써 서비스에 대한 액세스를 요청할 수 있다. 식별자는 오픈ID IdP(OP)의 사용자이름 및 도메인을 포함할 수 있다. OP는 발견 및 인증을 위한 종단점들을 제공할 수 있다. 608에서, 클라이언트(602)(서비스 제공자)는 인가 요청을 준비할 수 있고, 요청을 사용자(600)에 전송할 수 있다. 이 요청은 원하는 요청 파라미터들을 포함할 수 있다. 610에서, 인가 요청은 예를 들어, HTTP 리디렉트를 이용하여 인가 서버(604)(예를 들어, 사용자를 통해)에 전송될 수 있다. 612에서, 인가 서버(604)는 사용자(600)를 인증할 수 있고, 이에 따라 인가 서버(604)는 인증 종단점(AEP)으로서 지칭될 수 있다. 예시적인 구성에서, 인가 서버(604)는, 사용자(600)가 이미 인증되지 않고 인증이 만료되지 않은 것이 아니면, 사용자(400)를 인증할 수 있다. 예를 들어, 사용자(600)의 현재 인증 상태는 "참(true)"일 수 있어서, 사용자(600)는 612에서 재인증될 필요가 없을 수 있다. 614에서, 인가 서버(604)는 예를 들어, 토큰이 발행되도록 허용하기 위해 사용자(600)로부터 인가 또는 동의(consent)를 획득할 수 있다. 예시적인 구성에서, 사용자(600)는 사용자 동의/인가를 방지할 수 있는 정책을 설정할 수 있다. 예를 들어, 사용자(600)는 이전의 프로토콜 실행 시에 '이 판단을 기억함' 체크박스를 클릭했었을 수 있다. 616에서, 토큰들이 생성되고, 인가 서버(604)는 액세스 토큰 및/또는 ID 토큰과 더불어 사용자(600)를 클라이언트(602)로 역으로 전송할 수 있다. 예시적인 구현에서, 620에서, 클라이언트(602)는 체크 ID 종단점(628)에서 ID 토큰을 입증할 수 있다. 622에서, 클라이언트(602)는 예를 들어, 사용자의 아이덴티티를 갖는 ID 토큰 응답을 수신할 수 있다. 624에서, 클라이언트(602)는 예를 들어, 액세스 토큰을 이용하여 사용자 인포 종단점(630)에 액세스할 수 있다. 클라이언트(602)는 예를 들어, 사용자 인포 종단점(630)에 액세스한 이후 요청된 사용자 속성들과 같은 사용자 인포 응답을 수신할 수 있다.
도 7을 참조하면, 서비스 제공자(예를 들어, 클라이언트(702))는 공유 시크릿을 아이덴티티 제공자(예를 들어, 인가 서버(704))에 등록할 수 있다. 706에서, 사용자/UE(700)는 클라이언트(702)에 의해 제공되는 서비스에 대한 액세스를 요청할 수 있다. 706에서, 액세스는 사용자(700)의 식별자를 클라이언트(702)에 제공함으로써 요청될 수 있다. 이러한 식별자는 예를 들어, 오픈ID 식별자를 포함할 수 있다. 클라이언트(702)는 원하는 요청 파라미터들을 포함할 수 있는 인가 요청을 준비할 수 있고, 클라이언트(702)는 708에서 사용자(700)에 요청을 전송할 수 있다. 클라이언트(702)는 710에서 HTTP 리디렉트를 이용하여 인가 서버(704)(예를 들어, 사용자(700)를 통해)와 같은 인증 종단점(AEP)(713)에 요청을 전송할 수 있다. 704에서, AEP(713)(예를 들어, 인가 서버(704))는 예를 들어, 사용자(700)가 현재 인증되지 않은 경우 사용자(700)를 인증할 수 있다. 714에서, 인가 서버(704)는, 예를 들어, 사용자 동의/인가를 이미 획득했을 수 있는, 정책이 적절하지 않은 경우 사용자(700)의 동의/인가를 획득할 수 있다. 716에서, 인가 서버는 인가(auth) 코드를 생성할 수 있고, 예를 들어, 718에서 사용자(700)가 클라이언트(702)에 인가 코드를 리디렉트하게 할 수 있다. 720에서, 클라이언트(702)는 예를 들어, 토큰 종단점(734)에서 인가 코드를 이용하여 어서트(assertion)를 요청할 수 있다. 724에서, 클라이언트(702)는 토큰 종단점(734)으로부터 어서트를 수신할 수 있다. 어서트는 응답 바디에 액세스 토큰 및/또는 ID 토큰을 포함할 수 있다. 726에서, 클라이언트(702)는 예를 들어, 체크 ID 종단점(736)에서 ID 토큰을 입증(validate)할 수 있다. 728에서, 클라이언트(702)는 체크 ID 종단점(736)으로부터 ID 토큰 응답을 수신할 수 있다. 이러한 ID 토큰 응답은 종단 사용자(700)의 아이덴티티를 포함할 수 있다. 730에서, 클라이언트(702)는 예를 들어, 액세스 토큰을 이용하여 사용자 인포 종단점(738)에 액세스할 수 있다. 732에서, 클라이언트(702)는 사용자 인포 종단점(738)으로부터 사용자 인포 응답을 수신할 수 있다. 예시적인 구현에서, 서비스 제공자(예를 들어, 클라이언트(702))는 단계(718)에서 수신된 바와 같은 ID 토큰을 검증할 수 있고, ID 토큰으로부터 획득된 아이덴티티 정보에 기초하여 액세스를 허가(grant)할 수 있다. 사용자 인포 종단점(738)에서 액세스 토큰을 이용한 아이덴티티 속성들의 검색은 클라이언트(702)에 대한 옵션일 수 있다.
일 예시적인 실시예에서, 오픈ID 연결 프로토콜이 구현되는 것을 가능하게 하는 매커니즘들이 UE 상에서 국부적으로 수행될 수 있다. 예를 들어, 사용자는 국부적으로 인증될 수 있고, 사용자에 대응하는 아이덴티티 속성들은 국부적으로 관리될 수 있고, 사용자에 의한 아이덴티티 속성들의 릴리즈는 국부적으로 인가될 수 있고, 사용자 인포 종단점은 UE 상에 국부적으로 위치될 수 있다. 예시적인 실시예에서, 예를 들어, 로컬 OP와 같은 로컬 신뢰 환경은 안전하게 사용자를 인증하고, 사용자로부터 인가를 획득하고 및/또는 토큰들을 생성할 수 있다. 국부적으로 생성된 토큰들은 예를 들어, 각각의 종단점들로부터 사용자 인증 데이터 및/또는 사용자 아이덴티티 정보(예를 들어, 속성들)를 검색하기 위해 서비스 제공자(SP)에 의해 이용될 수 있다. 본 명세서에서 설명되는 바와 같이, 토큰은, 토큰이 인가된 UE 및/또는 인가된 로컬 OP에 의해 발행되었으며 토큰은 만료되지 않았다는 것을 검증하기 위해 네트워크 아이덴티티 제공자(IdP)에 대한 정보를 포함할 수 있다. 토큰이 만료?榮쩝嗤? 결정하기 위해, 예를 들어, 토큰은 사용자 인증 시에 타임 스탬핑(time stamp)될 수 있다.
도 8은 예시적인 실시예에 따라 토큰이 국부적으로 생성될 수 있는 예시적인 프로토콜 흐름의 흐름도를 도시한다. 806에서, 디바이스(800)와 같은 UE는 예를 들어, 서비스 제공자(802)에 의해 제공된 서비스에 대한 액세스를 요청할 수 있다. 요청은 디바이스(800)의 사용자의 식별자를 포함할 수 있다. 808에서, 서비스 제공자(802)(클라이언트)는 리디렉트 메시지를 통해 디바이스(800)로부터 토큰을 요청할 수 있다. 따라서, UE는 토큰에 대한 요청을 수신할 수 있으며, 여기서 토큰에 대한 요청은 서비스 제공자에 의해 제공된 서비스에 대한 액세스에 대한 요청에 응답한다. 808에서, 요청은 오픈ID 연결 프로토콜에 따라 ID 토큰에 대한 요청을 포함할 수 있다. 808에서의 요청은 오픈ID 연결 프로토콜에 따라 액세스 토큰에 대한 요청을 포함할 수 있다. 예를 들어, 액세스 토큰은 서비스 제공자가 디바이스(800)의 사용자의 속성들을 검색할 수 있도록 서비스 제공자(802)에 의해 요청될 수 있다. 속성들은 사용자의 아이덴티티에 관련될 수 있다. 서비스 제공자(802)는 예를 들어, 부가적인 속성들 또는 사용자 정보가 필요하지 않다고 서비스 제공자(802)가 결정하는 경우 액세스 토큰을 요청하지 않는 것으로 판단할 수 있다.
도 8을 계속 참조하면, 810에서, 사용자는 디바이스(800)가 서비스 제공자(802)에 토큰을 발행하도록 하는 동의(승인)를 제공할 수 있다. 예를 들어, 액세스 토큰은 서비스 제공자(802)가 사용자 정보(인포) 종단점으로부터 특정된 속성(들)에 액세스하도록 허용할 수 있는 동의(예를 들어, 사용자에 의해 제공됨)를 표현할 수 있다. 예를 들어, 국부적으로 생성된 액세스 토큰은 액세스가 허가된 특정한 속성들을 사용자 인포 종단점이 식별하도록 허용할 수 있는 데이터를 포함할 수 있다. 예를 들어, 서비스 제공자(802)는 다수의 속성들에 대한 액세스를 요청하고 사용자가 요청된 속성들 중 일부에 대한 액세스를 인가하도록 동의하는 경우(810에서), 사용자 인포 종단점은 예시적인 실시예에 따라, 인가된 정보를 릴리즈(release)할 수 있고, 사용자에 의해 인가되지 않은 속성들을 릴리즈하지 않을 수 있다.
예를 들어, 디바이스(800)와 같은 UE는 사용자 데이터에 대한 요청을 수신할 수 있고, 사용자 데이터의 동의된 부분을 릴리즈하도록 하는 사용자 동의를 수신할 수 있다. 사용자 동의에 응답하여, 디바이스(800)는 서비스 제공자(802)와 연관될 수 있는 액세스 토큰을 생성할 수 있다. 디바이스(800)는 서비스 제공자(802)에 액세스 토큰을 발행할 수 있고, 여기서, 사용자 데이터의 동의된 부분은 액세스 토큰의 검증 시에 서비스 제공자(802)에 릴리즈된다. 요청된 사용자 데이터는 복수의 사용자 속성들을 포함할 수 있으며, 여기서 복수의 사용자 속성들을 중 적어도 하나는 릴리즈되는 사용자 데이터의 동의된 부분의 일부가 아니다. 본 명세서에서 추가로 설명되는 바와 같이, 사용자 정보 종단점은 예시적인 실시예에 따라 디바이스(800) 내에 상주할 수 있으며, 액세스 토큰은 이러한 사용자 정보 종단점에서 수신될 수 있다. 액세스 토큰의 수신에 응답하여, 디바이스(800)는 사용자 데이터의 동의된 부분을 서비스 제공자(802)에 제공할 수 있다.
812에서, 토큰들은 디바이스(800) 상에서 생성될 수 있다. 예를 들어, 토큰에 대한 요청에 응답하여, 디바이스(800)는 토큰에 대한 요청에 따라 아이덴티티 토큰을 생성할 수 있다. 예시적인 실시예에서, 토큰들은 디바이스(800) 내에 상주할 수 있는, 로컬 OP와 같은 신뢰 환경 상에서 안전하게 생성될 수 있다. 액세스 토큰은 812에서 디바이스(800) 상에 생성될 수 있다. 이러한 액세스 토큰은 예를 들어, 어느 속성(들)이 서비스 제공자(802)에 의해 검색될 수 있는지를 네트워크 엔티티가 결정하도록 허용하는 정보를 포함할 수 있다. 토큰은 814에서 서비스 제공자(802)에 발행될 수 있다. 예를 들어, 아이덴티티(ID) 토큰은 예를 들어, 디바이스(800)와 같은 UE를 통해 발행될 수 있으며, 여기서 ID 토큰은 서비스에 UE 액세스를 제공하도록 검증된다. 서비스 제공자(802)는 예를 들어, 820에서 ID 토큰과 같은 토큰을 검증할 수 있다. 예시적인 실시예에서, 서비스 제공자(802)는 토큰이 유효하다고 검증하기 위해 Id 토큰 상의 서명을 체크할 수 있다. 검증을 위한 키 재료는 예를 들어, JSON Web Key URL 파라미터에서와 같은 발견 프로세스에서 서비스 제공자(802)에 의해 수신되었을 수 있다. 서비스 제공자(802)가 ID 토큰 서명을 입증한 이후, 서비스 제공자(802)는 ID 토큰을 추가로 입증하기 위해 ID 토큰에 인코딩된 필드들을 체크할 수 있다. 예를 들어, 'iss'(issuer) 필드는 SP가 사용자 제공 식별자로부터 발견한 IdP의 고유한 식별자와 같은 토큰 발행자의 고유한 식별자를 포함할 수 있다. 'aud'(audience) 필드는 토큰이 의도된 청중을 식별할 수 있다. 따라서, 청중 필드는 서비스 제공자(802)의 client_d를 포함할 수 있다. 'exp'(expires) 필드는 토큰이 수락되지 않는 만료 시간을 식별할 후 있다. 만료 시간을 갖는 예시적인 구성에서, 현재 시간이 'exp' 날짜 및 시간 이후인 경우, 대응하는 ID 토큰이 만료된다. 서비스 제공자는 ID 토큰이 만료되지 않는 경우 그것을 검증 및 입증할 수 있다.
816에서, 예를 들어, 네트워크 IdP와 같은 사용자 인포 종단점에는 액세스 토큰이 제시될 수 있다. 액세스 토큰은 단계(810)로부터 동의 정보를 포함할 수 있다. 예시적인 실시예에서, 서비스 제공자(SP)(802)는 오파크 값들로서 액세스 토큰을 취급할 수 있다. 이러한 액세스 토큰들은 서명을 포함하지 않는 오파크 배리어 토큰들로서 지칭될 수 있다. 816에서, 액세스 토큰들은 각각의 토큰 종단점들에 대해 사용자 속성들 및/또는 다른 정보를 검색하기 위해 이용될 수 있다. 토큰들은 예를 들어, 디바이스(800)의 로컬 OP의 식별자와 같은 디바이스(800)의 식별자를 포함할 수 있다. 이러한 식별자들은 발행 디바이스(800) 또는 발행 로컬 OP의 고유한 아이덴티티를 네트워크 IdP(804)에 통지할 수 있다. 디바이스(800)의 로컬 OP 및/또는 디바이스(800)의 이러한 식별자는 토큰의 서명에 포함될 수 있다. 식별자는 예를 들어, 822에서 네트워크 IdP(804)가 로컬 OP에 의해 발행된 토큰들을 인지 및 입증하도록 허용할 수 있다. 식별자는 토큰 생성 및 토큰 검증이 도 8에서 예시된 바와 같이 적어도 2개의 상이한 엔티티들에서 발생하도록 허용할 수 있다. 예를 들어, 네트워크 IdP(804)와 같은 네트워크 엔티티는 토큰 검증 종단점(822)을 통해 토큰을 검증하도록 요청될 수 있다. 종단점(822)은 ID 토큰을 검증하기 위해 상술된 예시적인 단계들에 따라 액세스 토큰을 검증할 수 있다. 네트워크 IdP(804)는 검증의 결과를 서비스 제공자(802)에 리턴할 수 있다. 성공적인 검증은 서비스 제공자(802)가 ID 토큰을 수락하고 그의 콘텐츠들을 신뢰하기 이전에 요구될 수 있다. 예를 들어, 서비스 제공자는 토큰들이 검증될 때까지 이메일 주소가 현재 세션의 사용자에 속한다는 것을 신뢰하지 않을 수 있다. 성공적인 검증 시에, 서비스 제공자(802)는 자신이 제공하는 서비스 등에 대한 액세스를 허용하도록 검증된 사용자를 그의 사용자 데이터베이스에 부가하는 것과 같은 행동을 취할 수 있다.
로컬 OP가 토큰들을 발행하는 예시적인 실시예에서, 로컬 OP는 토큰에 서명하기 위해 시크릿을 알 수 있다. 예를 들어, 로컬 OP는 발견 프로세스에서 IdP에 등록한 서비스 제공자에 제공되는 시크릿들을 알 수 있다. 본 명세서에서 설명되는 바와 같이, 서비스 제공자는 토큰(예를 들어, ID 토큰)을 체크 ID 종단점에 전송할 수 있다. 종단점은 JWT 인코딩을 디코딩할 수 있고 및/또는 서명을 검증할 수 있다. 예시적인 구성에서, 서비스 제공자는 체크 ID 종단점 없이 토큰을 검증할 수 있다(도 8의 820 참조). 예를 들어, ID 토큰 JWT는 JWK 키(key)로 서명될 수 있다. 키는 예를 들어, 아이덴티티 제공자와의 발견 프로세스의 결과로서 서비스 제공자에 알려질 수 있다.
본 명세서에서 설명된 디바이스들의 다양한 실시예들은 (예를 들어, 로컬 OP에 의해) 국부적으로 토큰들을 생성할 수 있다. 예를 들어, 로컬 OP는 토큰 서명을 생성하기 위해 시크릿을 알 수 있다. 예시적인 실시예에서, HMAC 서명들이 이용될 수 있다. 예를 들어, 로컬 OP는 서비스들에 대한 클라이언트 시크릿들을 포함하는 리스트에 대한 액세스를 가질 수 있다. 리스트는 예를 들어, (예를 들어, OTA 채널을 이용하여) MNO에 의해 유지되고, 업데이트되고 및/또는 관리될 수 있다.
HMAC 서명들을 이용하는 다른 구현에 따라, 로컬 OP는 청중 필드를 이용할 수 있고 및/또는 예를 들어, 네트워크 IdP로부터 대응하는 시크릿을 획득하기 위해 (예를 들어, 보안 통신 채널을 통해) MNO 서비스 종단점에 질의할 수 있다. 예를 들어, 제공자의 JSON Web Key 문서의 URL을 질의하는 것은 키의 식별자를 획득할 수 있다. 로컬 OP는 키 재료를 획득하기 위해 안전한 및/또는 인증된 요청을 행할 수 있다. 요청은 예를 들어, 사용자 인증으로부터 독립적일 수 있는 (예를 들어, 낮은 이용(low usage) 시간들에 키 재료의 로딩) 프로토콜 실행에 의해 및/또는 통신 단계들을 도입함으로써와 같이 인증 시에 발생할 수 있다.
다른 예시적인 실시예에서, 시크릿은 공유 시크릿들(S) 및/또는 청중 필드 콘텐츠들로부터 유도될 수 있다. 예를 들어, 로컬 OP는 클라이언트 키를 계산할 수 있다. 키 유도 기능은 예를 들어, (예를 들어, 장기 시크릿(S)에 기초하여) 클라이언트 시크릿을 계산하기 위해 네트워크 IdP에 의해 이용될 수 있다. 클라이언트 시크릿은 로컬 OP 인스턴스들과 공유될 수 있다. 발견 프로세스에서, 예를 들어, 네트워크 IdP는 클라이언트 시크릿을 계산하기 위해 KEF를 이용할 수 있다. 로컬 OP는 동일한 클라이언트 시크릿을 계산할 수 있다.
JSON 웹 서명(JWS)은 서명된 JWT에 대한 헤더 필드들의 이용을 허용할 수 있다. 예를 들어, 헤더 필드들은 서명을 위해 이용될 수 있는 정보와 같은 키에 관한 정보를 전달하는데 이용될 수 있다. 'jku' 파라미터는 공개 키들을 호스트할 수 있는 JSON Web Key(JWK) URL을 가리킬 수 있다. 'kid' 키 id 파라미터는 어느 키가 이용될 수 있는지를 표시할 수 있다. 대안적인 실시예에서, 헤더는 (예를 들어, X.509 공개 키 인증서에 대한) URL을 가리킬 수 있는 필드 'x5u'를 포함할 수 있다. 네트워크의 OP는 로컬 OP 인스턴스(들)에 대한 키들 및/또는 인증서들을 생성할 수 있고 및/또는 예를 들어, 공개 키 인증서들을 패치(fetch)하기 위해 서비스들/클라이언트들에 대한 URL을 제공할 수 있다. 로컬 OP는 개인키를 포함할 수 있고, 및/또는 예를 들어, JWS의 헤더에 대응하는 공개 키 인증서에 대한 URL에 대한 포인트(point)와 같이 URL에 대한 포인터를 포함할 수 있다. 예시적인 실시예에서, 로컬 OP는 JWT에 따라 ID 토큰을 인코딩할 수 있고 서명을 적용할 수 있고 ID 토큰을 서비스 제공자에 전송할 수 있다.
로컬 OP는 키 쌍이 장착될 수 있다. 예를 들어, 개인키는 안전하게(예를 들어, 로컬 OP에) 저장될 수 있다. 네트워크 OP는 공개 키 및 선택적으로 공개 키에 대한 대응하는 인증서를 알 수 있다. 네트워크 OP는 인증 기관(Certificate Authority; CA)으로서 작동할 수 있고, 인증서들을 스스로 생성할 수 있거나, 네트워크 OP는 인증된 공개 키들을 (예를 들어, 제 3 자 CA로부터) 획득할 수 있다. 로컬 OP에 키 쌍이 장착되는 예시적인 실시예에서, 사용자는 서비스 제공자(예를 들어, 제 1 시간 동안)를 방문하기를 원할 수 있고, 이메일 주소를 입력할 수 있다. 서비스 제공자는 사용자이름 및/또는 OP 호스트를 추출할 수 있고 및/또는 발견 및/또는 등록 단계들을 수행할 수 있다. 예를 들어, 서비스 제공자(예를 들어, 웹사이트)는 사용자 및/또는 OP에 의해 이전에 보여졌을 수 있다. 서비스 제공자(클라이언트)는 네트워크 OP에 등록할 수 있고, 네트워크 OP는 인증된 공개키들의 리스트를 포함하는 JWK URL을 제공할 수 있다. 서비스 제공자는 예를 들어, 속성(들)에 대한 액세스 토큰 및/또는 ID 토큰에 대한 요청을 사용자 에이전트(예를 들어, 브라우저)가 인가 서버에 리디렉트하게 할 수 있다.
디바이스의 내부 라우팅은 사용자 에이전트가 로컬 OP 인스턴스로 지향될 수 있게 될 수 있다. 로컬 OP는 사용자를 국부적으로 인증할 수 있다. 예시적인 실시예에서, 로컬 OP는 요청된 속성들(예를 들어, 요구들)을 추출할 수 있고 및/또는 사용자 속성들의 가용성을 체크할 수 있다. 요청된 속성들이 네트워크에서 이용 가능할 수 있거나 이용 가능하지 않을 수 있다. 예를 들어, 로컬 OP는 액세스 토큰을 생성하기 위한 사용자 동의(예를 들어, 인가)를 획득할 수 있다. 인가는 요청된 속성들의 적어도 일부에 대한 액세스를 서비스 제공자에 제공할 수 있다. 사용자는 데이터를 릴리즈하기 위한 동의를 (예를 들어, '릴리즈를 항상 OK함' 체크박스를 클릭함으로써) 이전에 제공했었을 수 있다. 이러한 동의는 예를 들어, 미래의 판단들을 위해 저장될 수 있다. 로컬 OP는 ID 토큰을 생성할 수 있고 예를 들어, 개인키를 이용함으로써 와 같이 토큰에 서명할 수 있다. 인증서의 URL은 토큰의 JWS 헤더의 x5u 필드에 넣어질 수 있다. 로컬 OP는 액세스 토큰을 생성할 수 있고 토큰에 서명을 적용할 수 있다. 액세스 토큰은 서비스 제공자에 의해 오파크 값으로 취급될 수 있고, 데이터를 포함하지 않을 수 있다. 액세스 토큰은 (예를 들어, 디바이스의 또는 네트워크의 사용자 인포 종단점에서) 보완될 수 있다. 동의는 토큰에 인코딩될 수 있다. 액세스 토큰 내에 동의 판단의 인코딩의 타입은 구현 의존적일 수 있다. 로컬 OP는 예를 들어, ID 토큰 및 액세스 토큰을 통해 사용자 에이전트를 클라이언트 종단점에 리디렉트하게 할 수 있다. 사용자 에이전트가 리디렉트할 URL은 초기 요청에서 서비스 제공자에 의해 제공될 수 있다(예를 들어, parameter redirect_uri). 서비스 제공자는 ID 토큰 서명을 스스로 검증하기를 원할 수 있다. 예를 들어, 서비스 제공자는 예를 들어, 토큰의 헤더 내의 x5u 파라미터에 제공된 URL과 같은 URL로부터 공개 키 및/또는 인증서를 요청할 수 있다. 예시적인 실시예에서, 서비스 제공자는 (예를 들어, 토큰 검증 요청을 위해) ID 토큰을 통해 OP의 체크 ID 종단점에 접촉할 수 있다. 이 통신은 예를 들어, 서비스 제공자와 OP 간에 공유될 수 있는 클라이언트 시크릿의 이용에 의해 보호될 수 있다. 체크 ID 종단점은 예를 들어, 헤더의 x5u 파라미터에 제공된 바와 같은 공개 키를 이용함으로써 와 같이 토큰 헤더로부터 서명을 체크함으로써 토큰이 인가된 로컬 OP 인스턴스에 의해 발행되었다고 검증할 수 있다. 체크 ID 종단점은 토큰 검증의 결과를 서비스 제공자에 리턴할 수 있다.
ID 토큰 검증의 결과로서, 서비스 제공자는 사용자 식별자 및/또는 식별자의 발행자를 알 수 있다. 예를 들어, 서비스 제공자가 액세스 토큰을 요청하지 않는 경우(예를 들어, 서비스 제공자가 요청된 서비스에 대한 액세스를 제공하기 위해 부가적인 데이터를 필요로 하지 않음), 인증 프로토콜은 종료하고 서비스 제공자는 요청된 데이터/서비스를 사용자에 제공할 수 있다. 액세스 토큰이 서비스 제공자에 의해 요청되고 액세스 토큰이 서비스 제공자에 발행되는 경우, 서비스 제공자는 예를 들어, 사용자 정보(예를 들어, 속성들)를 검색하기 위해 사용자 인포 종단점에 대한 요청에 액세스 토큰을 이용할 수 있다. 액세스 토큰은 예시적인 실시예에 따라 사용자 속성들을 포함할 수 있다. 로컬 OP는 속성들을 검색할 수 있고, 토큰을 생성할 수 있고 및/또는 토큰에 서명할 수 있다. 예시적인 실시예에 따라, 서비스 제공자는 자율적으로 토큰 유효성을 검증할 수 있고 원하는 정보(예를 들어, 사용자 속성들 또는 요구들)를 검색할 수 있다.
사용자 인포 종단점은 유효한 그리고 인가된 로컬 OP에 의해 토큰이 발행되었다는 것을 검증할 수 있다. 종단점은 요청된 데이터의 릴리즈에 사용자가 동의하였다는 것을 검증할 수 있다. 로컬 OP의 유효성의 검증은 액세스 토큰 상의 JWS 서명을 검증함으로써 완료될 수 있다. 사용자 동의의 검증은 예를 들어, 사용자 동의와 연관된 정보를 전달하기 위해 액세스 토큰의 내부 서명을 수정할 수 있다. 검증 시에, 사용자 인포 종단점은 요청된 속성들을 서비스 제공자에 (예를 들어, JSON 포맷으로) 리턴할 수 있다. 서비스 제공자는 (예를 들어, 수신된 속성들을 이용하여) 사용자의 사용자 프로파일의 로컬 카피(local copy)를 생성할 수 있고 및/또는 서비스에 대한 액세스를 제공할 수 있다. 예시적인 실시예에 따라, 사용자가 서비스 제공자를 재차 방문한 경우, 등록 및/또는 발견 단계들은 서비스 제공자에 의해 수행되지 않을 수 있다. 사용자는 인증 및 인가를 수행하도록 지향될 수 있고, 사용자는 토큰 검증 이후에 서비스 제공자에 직접 로그인할 수 있다.
예시적인 실시예에서, 개인 키들은 안전한 환경에서 존재할 수 있다. 로컬 OP는 안전한 신뢰 환경(예를 들어, 보안 모듈, 신뢰 모듈 등)에서 국부적으로 키 쌍을 생성할 수 있고 안전 엘리먼트에 개인 키를 저장할 수 있다. 네트워크 OP는 대응하는 공개 키에 대한 인증서를 생성할 수 있고 및/또는 인증서를 서비스 제공자들에 (예를 들어, 요청 시에) 제공할 수 있다. 본 명세서에서 설명된 바와 같이, K라는 표기는 키 쌍을 나타낼 수 있고, pu(K)는 공개 키를 나타낼 수 있고, pr(K)는 개인 키를 나타낼 수 있고 cert(K,C)는 pu(K)에 대한 인증서를 나타낼 수 있다. 예를 들어, cert(K,C)는 키(C)의 보유자에 의해 발행될 수 있고 및/또는 이것은 키 pr(C)를 이용하여 생성될 수 있고 및/또는 이것은 pu(C)를 이용하여 검증될 수 있다.
예를 들어, 안전 엘리먼트 상에 로컬 OP 애플릿의 설치 시에, 애플릿은 루트 키 쌍 R을 생성할 수 있고, 안전 엘리먼트에 pr(R)을 저장할 수 있고, 안전 엘리먼트 발행자 또는 제조자로부터(예를 들어, 스마트 카드 제조자로부터) 인증서(cert(R,I))를 획득할 수 있다. 인증서는 발행자에 의해 저장될 수 있고, 안전 엘리먼트에 저장될 수 있다.
예시적인 실시예에 따라, 로컬 OP는 OP 서버 기능(OP Server Function; OPSF)의 도메인에 기재될 수 있다. 이 기재(enrollment)는 예를 들어, 모바일 디바이스 상에 로컬 OP 애플리케이션이 설치되거나 처음 시작될 때 트리거될 수 있다. OPSF는 예를 들어, 새로운 키 쌍들을 OPSF에 기재하기 위해 로컬 OP들에 의해 이용될 수 있는 기재 종단점을 제공할 수 있다.
로컬 OP는 오픈ID 애플리케이션 특정 키 쌍 O1을 생성할 수 있고, cert(O1, R)을 생성할 수 있고(예를 들어, pr(R)을 이용하여 pu(O1)에 서명할 수 있음), cert(O1, R) 및 cert(R, I)를 OPSF의 기재 종단점에 제출할 수 있다. 기재 종단점은 예를 들어, 로컬 OP가 신뢰할 수 있는 발행자에 의해 생성되고 발행되었다는 것을 검증하기 위해 cert(R, I)를 체크할 수 있다. 예를 들어, 검증은 발행자 키 I에 대한 인증서를 체크하는 것을 포함할 수 있고, (예를 들어, 인증서들이 유효한지를 결정할 수 있는) OCSP 체크들을 포함할 수 있다. OPSF 기재 종단점은 키 pu(O1)가 그 로컬 OP 인스턴스에 의해 생성되었다는 것을 검증하기 위해 cert(O1, R)을 체크할 수 있다.
로컬 OP는 토큰 서명들을 생성하기 위해 키를 이용할 수 있다. 예를 들어, OPSF는 인증서(예를 들어, 체인)가 (예를 들어, 인증서 종단점에서) RP들에 대해 이용 가능하게 할 수 있다. OPSF는 인증서 및 그의 인증서 체인을 저장할 수 있다. 인증서(들)은 예시적인 실시예에 따라 인증서 종단점에서 이용 가능할 수 있다. 대안적으로, OPSF는 cert(O1, P)일 수 있는, O1에 대한 인증서를 생성할 수 있다. OPSF는 인증서 cert(O1, P)를 인증서 종단점에서 이용 가능하게 할 수 있다. 다양한 실시예들에서, OPSF는 인증서 종단점에서의 인증서의 URL을 로컬 OP(예를 들어, 암호화되고 및/또는 서명될 수 있음)에 리턴할 수 있다. OPSF는 예를 들어, 증명(certification)에 걸쳐 적용될 수 있고, 이에 따라 OFSP 도메인 PKI를 안전 엘리먼트 발행자 도메인과 통합할 수 있다.
로컬 OP는 본 명세서에서 설명된 바와 같이, 토큰 헤더들에서 인증서(예를 들어, 이용된 방법에 의존할 수 있는 cert(O1, R) 및/또는 cert(O1, P))에 대해 (예를 들어, 수신된 바와 같은) URL을 포함할 수 있다. 예를 들어, 로컬 OP는 토큰 서명을 생성하기 위해 pr(O1) 키를 이용할 수 있다.
로컬 OP는 인증서 및/또는 서명 키 O1를 업데이트할 필요가 있을 수 있다. 예를 들어, 인증서의 유효성은 키가 이용될 수 있을 때 체크될 수 있다. 갱신(renewal) 프로세스는 만료 날자가 근접할 때 트리거될 수 있다.
서명 키 O1는 새롭게 생성된 키 쌍 O2으로 대체될 수 있다. 예를 들어, 새로운 공개 검증키가 OPSF 도메인에 기재될 수 있다. 구(old) 검증 키는 (예를 들어, 천이 기간 동안 그의 구 URL 에서) 이용 가능하게 남아있을 수 있다. 예시적인 실시예에서, 클라이언트들은 토큰 서명 검증을 위해 키를 이용할 수 있다. OPSF는 최근에 발행된 ID 토큰의 유효 기간을 알 수 있고, 구 인증서(예를 들어, cert(O1, R) 또는 cert(O1, P))는 유효 기간 동안 이용 가능할 수 있다. 유효 기간이 알려지지 않은 경우, 예를 들어, 엔티티들은 구 인증서들이 이용 가능하게 남아있는 천이 기간에 대해 최소 지속기간으로 협의할 수 있다. OPSF는 인증서들을 생성할 수 있고, 그것은 이전의 cert(O1,P)를 생성할 수 있고, 그것은 cert(O2,P)를 생성할 수 있다. 새로운 키 쌍 O2는 구 키 쌍을 O1를 이용하여 기재될 수 있고(예를 들어, cert(O2, O1)는 기재에 이용될 수 있음) 키들의 체인(예를 들어, 키 이력)이 구축될 수 있다. 구/이전/만료된 서명 키는 삭제될 수 있다.
기재의 다른 예시적인 실시예에서, 로컬 OP는 예를 들어, 프로토콜 흐름에서 동적으로 키 쌍을 생성할 수 있다. 예를 들어, 로컬 OP 및 OPSF는 장기 시크릿(KL)을 공유할 수 있다. 키 쌍이 생성되고 및/또는 랜덤 시드 값 및/또는 OPSF에 알려질 수 있는 장기 공유 시크릿에 기초할 수 있다. 랜덤 시드는 OPSF에 전달될 수 있고, OPSF는 키들을 재-계산할 수 있다. 개인 키는 네트워크에서 드리고 로컬 OP에서 이용 가능할 수 있다.
본 명세서에서 설명되는 바와 같이, 로컬 OP는 토큰 요청 메시지를 수신할 수 있고 토큰 서명들을 생성할 수 있다. 로컬 OP는 예를 들어, 토큰 서명들이 생성될 때 랜덤 시드 값(S)을 생성할 수 있다. 로컬 OP는 예를 들어, S 및 장기 시크릿(KL)에 기초하여 새로운 키 쌍을 계산할 수 있다. 토큰 헤더의 x5t URL 파라미터 및 토큰에 서명하는데 이용될 수 있는 공개 키는 (예를 들어, OPSF의 인증서 종단점에서) 동적 URL로 세팅될 수 있다. 동적 URL은 파라미터(예를 들어, http://opsf.org/cert.php?seed=1234)로서 시드(S)를 포함할 수 있다. 인증서 종단점은 예를 들어, 수신된 파라미터(S) 및/또는 장기 시크릿(KL)에 기초하여 로컬 OP가 계산한 키 쌍을 계산할 수 있다. 인증서 종단점은 공개 키에 대한 인증서를 생성할 수 있다. OPSF는 개인 키를 삭제할 수 있고 및/또는 동적 URL(예를 들어, http://opsf.org/cert.php?seed=1234)에서 공개 키 인증서를 제공할 수 있다. 클라이언트가 토큰을 수신하고 URL(예를 들어, http://opsf.org/cert.php?seed=1234)을 질의하는 경우, OPSF는 올바른 키 쌍을 생성할 수 있고, 인증서를 클라이언트에 제공할 수 있다. 예를 들어, 키 및/또는 인증서가 이미 생성된 경우, OPSF는 인증서를 클라이언트에 직접 제공할 수 있다.
도 9는 인증(auth) 서버(906)와 미리-설정된 공유 시크릿(S)을 공유하는 로컬 OP(900)와의 예시적인 프로토콜 흐름의 흐름도를 도시한다. 예시적인 시나리오에서, 로컬 OP에는 ID 토큰 상에 비대칭 서명들을 생성하는데 이용될 수 있는 개인 키가 장착되지 않을 수 있다. 예를 들어, HMAC 서명들이 토큰 서명을 위해 이용될 수 있다. 대안적인 예시적인 시나리오에서, 인증 서버(906)와 같은 네트워크 OP와 클라이언트(예를 들어, 서비스 제공자(904)) 간에 설정된 키는 예를 들어, 토큰 서명들의 생성을 위해 이용될 수 있어서, 클라이언트들은 서명들을 자율적으로 입증할 수 있다.
도 9를 참조하면, 908에서, 사용자는 UE의 브라우저(902)를 통해 서비스 제공자(904)에 의해 제공되는 서비스에 대한 액세스를 요청할 수 있다. 908에서, 브라우저(902)는 예를 들어, 서비스 제공자(904)에 오픈ID 식별자와 같은 식별자를 제공할 수 있다. 서비스 제공자(904)는 ID 토큰 및 액세스 토큰에 대한 요청을 포함할 수 있는 인가 요청을 준비할 수 있고 서비스 제공자(904)는 910에서, 리디렉트 메시지를 통해 요청을 브라우저(902)에 전송할 수 있다. 910에서의 요청은 오픈ID 연결 프로토콜에 따라 ID 토큰에 대한 요청을 포함할 수 있다. 910에서의 요청은 오픈ID 연결 프로토콜에 따라 액세스 토큰에 대한 요청을 포함할 수 있다. 예를 들어, 액세스 토큰은 서비스 제공자(904)가 UE의 사용자의 속성들을 검색할 수 있도록 서비스 제공자(904)에 의해 요청될 수 있다. 912에서, 요청은 예를 들어, UE 상의 브라우저(902)로부터 로컬 OP(900)와 같이 UE 상의 신뢰 모듈로, 리디렉트 메시지를 통해 포워딩될 수 있다. 914에서, UE의 사용자는 로컬 OP(900)에 의해 인증될 수 있다. 916에서, 사용자는 UE가 서비스 제공자(904)에 토큰을 발행하도록 하는 동의(승인)를 제공할 수 있다. 예를 들어, 인가 요청은 UE의 사용자에 의해 승인될 수 있다. 또한, 인가 요청에 응답하여, UE에서, 인가 요청의 사용자 승인과 연관되는 액세스 토큰이 생성될 수 있다. 예시적인 실시예에서, 인가 요청의 사용자 승인은 UE 상에 저장되는 정책을 통해 자동으로 수신될 수 있다.
도 9를 계속 참조하면, 918에서, 토큰은 로컬 OP(900)에서 생성될 수 있다. 정보는 토큰에 부가될 수 있다. 예를 들어, 토큰에 대한 확장은 정보를 토큰의 JSON 데이터 구조에 부가할 수 있다. 예시적인 실시예에서, 토큰은 다음을 포함한다:
"iss": (예를 들어, http://server.example.com),
"user_id" : (예를 들어, 248289761001),
"aud" : (예를 들어, http://client.example.com"),
"exp" : (예를 들어, 1311281970),
"lop id": (예를 들어, 11223344556677와 같이 로컬 OP에 대한 식별자를 표현할 수 있음),
"timestamp" : (예를 들어, time20111012143815Z와 같이 포맷 YYYYMMDDhhmmss[.s...]Z'를 갖는 time 타임스탬프를 표현할 수 있음), 및/또는
"lop_sig": (예를 들어, 572400e4ec56fdce9549777bf67d70041f53a6aa와 같이 HMAC SHAl({lop_id|timestamp})를 이용한 서명을 표현할 수 있음)
예를 들어, 918에서, HMAC_SHA1 서명은 키로서 공유 시크릿(S)을 이용하여 계산될 수 있다. 서명은 사용자 인증의 타임스탬프 및/또는 로컬 OP ID의 연결(concatenation) 상에서 계산될 수 있다. 다른 예시적인 토큰에서, 데이터는 예를 들어, 아래에서 예시되는 바와 같은 로컬 OP 필드들의 그룹을 생성함으로써 JSON에 따라 구조화될 수 있다:
{
"iss": (예를 들어, http://server.example.com),
"user_id" : (예를 들어, 248289761001),
"aud" : (예를 들어, http://client.example.com),
"exp" : (예를 들어, 1311281970),
"로컬_openid" : {
"lop_id": "(예를 들어, 11223344556677와 같은 로컬 OP에 대한 식별자일 수 있음),
"timestamp" : "(예를 들어, 20111012143815Z), 및/또는
"lop_sig": (예를 들어, 572400e4ec56fdce9549777bf67d70041f53a6aa와 같이 HMAC SHAl({lop_id|timestamp})를 이용한 서명일 수 있음)
}
}
설명된 바와 같이, 콘텐츠는 ID 토큰에 부가될 수 있고 유효 HMAC SHA1 서명이 생성될 수 있다. 예를 들어, 서명을 위해 이용될 수 있는 키는 클라이언트 시크릿일 수 있다. 정보가 JSON 토큰에 부가될 수 있고 및/또는 그의 내부 서명이 수정될 수 있다. 예시적인 실시예에 따라, 서비스 제공자는 토큰의 부가적인 필드들을 무시할 수 있고 및/또는 서비스 제공자는 오파크 값들로서 토큰을 취급할 수 있다.
본 명세서에서 설명된 바와 같이, 토큰 서명들을 생성할 수 있는 키는 클라이언트 시크릿일 수 있다. 예를 들어, 이를 테면, 등록 프로세스에서 클라이언트 시크릿은 클라이언트(서비스 제공자)와 인증 서버(OPSF) 간에 설정될 수 있다. 인증 서버는 예를 들어, 로컬 OP가 올바른 토큰 서명을 생성하는 것을 가능하게 하기 위해, 로컬 OP에 클라이언트 시크릿들의 리스트를 제공할 수 있다. 예를 들어, 인증 서버는 로컬 OP 인스턴스들에서 클라이언트들의 리스트를 설치하기 위해 오버-디-에어 관리 방법들을 이용할 수 있다. 새로운 클라이언트 시크릿이 (예를 들어, 새로운 클라이언트 및/또는 기존의 클라이언트에 대해) 등록되면, 로컬 OP의 리스트가 업데이트될 수 있다. 예를 들어, 클라이언트의 URL일 수 있는, 토큰 요청에서의 청중(aud) 파라미터는 토큰들을 요청하는 클라이언트를 식별할 수 있다. 청중 파라미터는 예를 들어, 로컬 OP 저장소에서 대응하는 클라이언트 시크릿을 발견하기 위해 로컬 OP에 의해 이용될 수 있다.
다른 예시적인 실시예에서, 클라이언트 시크릿들은 인증 서버로부터 질의될 수 있다. 예를 들어, 로컬 OP는 토큰들에 대한 유효한 HMAC 서명들을 생성하기 위해 클라이언트 시크릿들을 알게 될 수 있다. 로컬 OP가 클라이언트 시크릿들을 알기 위해, 인증 서버는 요청 시에 로컬 OP에 클라이언트 시크릿을 제공할 수 있다. 이러한 준비(provision)에서, 로컬 OP는 토큰 요청에서 수신될 수 있는 청중 파라미터로부터 클라이언트 이름을 추출할 수 있다. 로컬 OP는 예를 들어, 특정한 종단점에서, 인증 서버에 대한 인증되고 및/또는 안정한 연결을 설정할 수 있다. 로컬 OP는 클라이언트에 대한 클라이언트 시크릿을 요청할 수 있다. 클라이언트 시크릿은 서명을 생성하는데 이용될 수 있다. 예를 들어, 인증 서버는 클라이언트 시크릿 종단점에 https://op.org/clients.php을 제공할 수 있다. 이러한 클라이언트 시크릿 종단점은 TLS 암호화를 이용할 수 있고 및/또는 인증될 수 있다. 실시예에 따른 예시적인 프로토콜 실행에서, 토큰 서명들을 생성하기 이전에, 로컬 OP는 클라이언트 시크릿 종단점에 연결될 수 있고, 클라이언트 시크릿 종단점에 대해 인증할 수 있고, 예를 들어, https://op.org/clients.php?client_audience=audience와 같은 자원을 요청할 수 있다. 예시적인 자원에서, 청중은 수신된 청중 필드로부터 콘텐츠를 균등하게 할 수 있다. 클라이언트 시크릿 종단점을 로컬 OP에 클라이언트 시크릿을 리턴할 수 있다. 이어서 로컬 OP는 유효한 서명을 생성하기 위해 시크릿을 이용할 수 있다.
또 다른 예시적인 실시예에서, 클라이언트 시크릿들은 인증 서버 및 로컬 OP에서 장기 시크릿들로부터 유도될 수 있다. 예를 들어, 클라이언트 시크릿들은 예를 들어, 클라이언트와 네트워크 OP 간의 등록 프로세스에서 설정될 수 있다. 본 명세서에서 설명되는 실시예들에 따라, 로컬 OP 및 네트워크 IdP/OP(인증 서버)는 장기 시크릿을 공유할 수 있다. 장기 공유 시크릿들을 생성하기 위한 다양한 방법들이 본 명세서에서 설명된다. 예를 들어, 장기 공유 시크릿은 로컬 OP 애플리케이션에 (예를 들어, 설치 시에) 임베딩될 수 있다. 장기 공유 시크릿은 MNO의 OTA 관리 동작들을 통해 생성될 수 있다. 장기 공유 시크릿은 예를 들어, 네트워크 인증 프로토콜 실행으로부터 키 유도(key derivation)에 의해 생성될 수 있다. 공유 시크릿은 네트워크 IdP/OP(인증 서버) 및 디바이스/로컬 OP 간에 신뢰 앵커(trust anchor)로서 작동할 수 있다. 시크릿은 예를 들어, SIM 카드 및/또는 임베딩된 보안 엘리먼트와 같은 안전 엘리먼트의 보안 특징들에 의해 로컬 OP에서 보호될 수 있다.
클라이언트의 예시적인 등록 프로세스에서, 인증 서버는 키 유도 기능(key derivation function; KDF)에서 클라이언트로부터 청중 파라미터를 갖는 장기 시크릿을 이용할 수 있다. 예를 들어, 네트워크 OP는, 클라이언트 시크릿 = KDF(청중, 장기 시크릿)이 되도록 클라이언트 시크릿을 유도할 수 있다. 예시적인 인증 프로토콜 실행에서, 로컬 OP는 토큰 요청 헤더로부터 청중 필드를 판독할 수 있고 클라이언트 시크릿을 계산하기 위해 장기 시크릿 및 청중 필드에 동일한 KDF를 적용할 수 있다. 클라이언트 시크릿은 이어서 토큰 서명을 생성하는데 이용될 수 있다.
도 9를 재차 참조하면, 910에서, 인가 요청은 예를 들어, 액세스 토큰과 같은 토큰 내로 통합될 수 있다. 클라이언트(예를 들어, 서비스 제공자(904))로부터의 오리지날(original) 인가 요청은 예를 들어, 발행된 액세스 토큰이 요청된 자원들을 위해 보완될 수 있다는 것을 보장하기 위해 토큰 내로 통합될 수 있다. 예시적인 시나리오에서, 로컬 OP(900)는 로컬 토큰 생성 프로세스에서 데이터에 대한 액세스를 인가할 수 있고, 데이터는 로컬 OP(900)에 의해 국부적으로 또는 네트워크에 의해 제공될 수 있다. 예시적인 시나리오에서, 요청은 예를 들어, 네트워크에 대해 토큰을 이용할 때 변경될 수 있다. 토큰은 네트워크로의 인가 요청에 관한 정보를 포함할 수 있다. 예를 들어, 인가 요청은 리디렉트 메시지를 통해 서비스 제공자로부터 인가 서버/OP(906)에 전송될 수 있다. 로컬 OP(900)가 본 명세서에서 설명된 바와 같이 이용될 때, 인가 요청은 910 및 912에서 리디렉트를 통해 로컬 OP(900)에 전송될 수 있다. 서비스 제공자(904)는 액세스 토큰들에 대한 인가 요청에서 요청된 액세스 프리빌리지들(access privileges)을 특정하기 위해 오픈ID 연결 스코프들(scopes)를 이용할 수 있다. 예를 들어, 액세스 토큰과 연관되는 스코프들은, 예를 들어, 이들이 OAuth 2 보호 종단점들에 액세스하는데 이용될 때 이용 가능하게 될 수 있는 자원들을 결정할 수 있다.
예시적인 스코프들은 클라이언트가 오픈ID 요청을 행할 수 있다는 것을 인가 서버에 통지할 수 있는 오픈ID 스코프를 포함한다. 예시적인 구성에서, 오픈ID 스코프가 특정되지 않는 경우, 인가 서버는 일반적인 OAuth 2.0 요청으로서 요청을 취급할 수 있고 오픈ID 프로세싱을 수행하지 않을 수 있다. 예를 들어, 프로파일 스코프는 디폴트 프로파일 정보를 요청할 수 있다. 이메일 스코프는 이메일 주소를 요청할 수 있다. 주소 스코프는 주소를 요청할 수 있다.
스코프 파라미터 외에, 인가 요청은 클라이언트(예를 들어, 서비스 제공자(904))가 요청 구조들을 구축하도록 허용할 수 있는 오픈ID 요청 객체를 포함할 수 있다. 예를 들어, 오픈ID 요청 객체는 오픈ID 요청 객체를 가리킬 수 있는 URL로서 및/또는 인코딩된 JWT로서 전달될 수 있다.
아래에는 오픈ID 연결 프로토콜에서 구현될 수 있는, JWT 인코딩 이전의 오픈ID 요청 객체의 예이다:
{
"response_type" : "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri" : "https://client.example.com/cb",
"scope": "openid profile",
"state": "afOifjsldkj",
"userinfo":
{
"claims" :
{
"name" : null,
"nickname": {"optional" : true},
"email": null,
"verified" : null,
"picture": {"optional": true},
},
"format": "signed"
}
"id token":
{
"max age" : 86400,
"iso29115" : "2"
}
}
아래에는 오픈ID 연결 프로토콜에서 구현될 수 있는 인코딩된 JWT의 예이다:
JWT 알고리즘 = HS256
HMAC HASH 키 = 'aaa' (예를 들어, 이것은 JWT에 서명하기 위한 키의 id일 수 있음)
JSON 인코딩된 헤더 = "{"alg":"HS256","typ":"JWT"} "
JSON 인코딩된 페이로드 = "{"response_type":"code id token",
"client_id" :"s6BhdRkqt3",
"redirect_uri":"https://client.example.com/cb",
"scope" :"openid profile",
"state":"af0ifjsldkj",
"userinfo" :{"claims" :{"name" :null, "nickname" :{"optional" :true} ,
"email" :null,"verified" :null,
"picture" :{"optional" :true}} , "format" :"signed"} ,
"id_token" :{"max_age" :86400,"iso291 15":"2"}}"
JWT =
eyJ0eXAiOiJKVlQiLCJhbGciOiJIUzIlNiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiI sImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLC JyZ WRpcmVj dF91 cmkiOiJodHRwczpcL1wvY2x pZW50LmV4YWlwbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaWlzIjp7Im5hbWUiOm51bGwsIm5pY2tuYWllIjp7Im9wdGlvbmFsIjp0cnVlfSwiZWlhaWwiOm51bGwsInZlcmlmaWkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcmlhdCI6InNpZ251ZCJ9LCJpZF90b2tlbiI6eyJtYXhfYW dlIjo4NjQwMCwiaXNvMjkxMTUiOiIyInl9.20iqRgrbrHkAlFZ5p_7bc_RSdTbH-wo_Agk-ZRpD3wY
아래는 오픈ID 연결 프로토콜에 따라 구현될 수 있는 인가 요청의 예이다.
https://server.example.com/authorize?
response_type=code%02id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid
&state=afOifjsldkj
&request=eyJ0eXAiOiJKVlQiLCJhbGciOiJIUzIlNiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcLlwvY2xpZW50LmV4YWlwbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcmluZm8iOnsiY2xhaWlzIjp7Im5hbWUiOm51bGwsIm5pY2tuYWllIjp7Im9wdGlvbmFsIjp0cnVlfSwiZWlhaWwiOm51bGwsInZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcmlhdCI6InNpZ251ZCJ9LCJpZF90b2tlbiI6eyJtYXhfYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyInl9.20iqRgrbrHkAlFZ5p_7bc_RSdTb H-wo_Agk-ZRpD3wY
도 9를 재차 참조하면, 예를 들어, 본 명세서에서 예시된 인가 요청과 같은 인가 요청은 HTTP 리디렉션(예를 들어, 도 9의 910 및 912 참조)을 통해 로컬 OP에 전송될 수 있다. 로컬 OP(900)는 요청이 유효하다는 것을 체크할 수 있고 및/또는 사용자를 인증할 수 있다. 로컬 OP(900)는 920 및 922에서 리디렉트 메시지들을 통해 서비스 제공자(904)에 발행될 수 있는 토큰을 생성할 수 있다. 서비스 제공자(904)는 예를 들어, 사용자 인포 종단점(928) 및/또는 ID 토큰 종단점(926)으로부터 데이터를 획득하도록 토큰들을 이용할 수 있다.
예시적인 실시예에서, 토큰 종단점들(926 및 928)에 대한 요청들(924 및 930)은 각각 오리지날 요청 객체를 포함하지 않을 수 있다. 이러한 요청(예를 들어, 요청들(924 및 930))에서, 토큰은 예를 들어, 토큰 종단점들(926 및 928)에 의해 수신될 수 있고, 서비스 제공자(904)에 의해 액세스되도록 인가되는 정보 및 서비스 제공자(904)에 의해 요청되는 정보의 표시가 없을 수 있다. 이러한 요청에서, 로컬 OP(900)는 서비스 제공자(904)에 발행하기 이전에 토큰에 JWT 인코딩된 요청을 부가함으로써 토큰 종단점들에 요청된 정보를 전달할 수 있다. 예를 들어, 토큰은 요청 정보를 전달할 수 있고, 요청 정보는 토큰 종단점들에 의해 평가될 수 있다. 요청 JWT는 예를 들어, 사용자의 인가 이후에 서비스가 요청을 변경할 수 있는 공격(attack)과 같은 공격을 방지하기 위해, 예를 들어, 로컬 OP(900)에 의해 서명될 수 있다. 토큰 서명들은 932 및 934에서 공유 시크릿(S)을 이용하여 각각의 종단점에서 검증될 수 있다. ID 토큰 서명들이 검증된 이후, 사용자의 인증 정보(예를 들어, 사용자 식별자)는 936에서, 서비스 제공자(904)에 제공될 수 있다. 액세스 토큰 서명이 검증된 이후, 서비스 제공자(904)에 의해 요청된 사용자 요구들 또는 사용자 속성들과 같은 사용자 프로파일 정보는 938에서 서비스 제공자(904)에 제공될 수 있다. 요청 정보를 포함하는 토큰의 예는 다음과 같이 제공된다:
{
"iss": "http://server.example.com", //오픈ID 연결에서 구현될 수 있음
"user_id" : "248289761001 ", //오픈ID 연결에서 구현될 수 있음
"aud": "http://client.example.com", //오픈ID 연결에서 구현될 수 있음
"exp" : 131 1281970, //오픈ID 연결에서 구현될 수 있음
"local_OPenid": {
"lop_id": " 1 1223344556677", //로컬 OP를 위해 이용된 식별자일 수 있음 "timestamp": "20111012143815Z", //'YYYYMMDDhhmmss[.s...]Z'
"request" :
"eyJ0eXAiOiJKVlQiLCJhbGciOiJIUzIlNiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF90b2tlbiIsImNsa
WVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvY2xpZW50 LmV4YW1wbGUuY29t
XC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwidXNlcm luZm8iOns
iY2xhaWlzIjp7Im5hbWUiOm51bGwsIm5pY2tuYWllIjp7Im9wdGlvbmFsIjp0cnVlfSwiZWlhaW wiOm51bGwsIn
ZlcmlmaWVkIjpudWxsLCJwaWN0dXJlIjp7Im9wdGlvbmFsIjp0cnVlfX0sImZvcmlhdCI6InNpZ2 51ZCJ9LCJpZ
F90b2tlbiI6eyJtYXhiYWdlIjo4NjQwMCwiaXNvMjkxMTUiOiIyInl9.2OiqRgrbrHkAlFZ5p_7bc_ RSdTbH-woAgk-ZRpD3wY",
"lop_sig": "a0a52ecf404981d579dab41439b10e0cdfb48f91"
HMAC SHAl({lop_id|timestamp|request})을 이용한 서명일 수 있음
}
}
위의 예시적인 토큰을 참조하면, 서명 lop_sig는 연결된 lop_id, 타임스탬프 및 요청을 통해 계산될 수 있다. 토큰은 예를 들어, 로컬 OP에 의해 서명될 수 있어서, 서명은 서비스 제공자 및/또는 아이덴티티 제공자의 토큰 종단점에 의해 검증될 수 있다. 예시적인 실시예에 따라, auth 코드는 요청 정보를 포함할 수 있다.
본 명세서에서 설명된 바와 같이, 사용자 데이터(예를 들어, 속성들)은 사용자 인포 종단점에 저장될 수 있다. 이러한 사용자 인포 종단점은 네트워크 엔티티, 클라우드(cloud) 등에 상주할 수 있고 사용자 데이터는 네트워크 또는 클라우드로부터 액세스될 수 있다. 도 10은 사용자 인포 종단점이 UE 상에 국부적으로 상주하는 다른 예시적인 실시예에 따른 호 흐름을 예시한다. 기밀 정보와 같은 사용자 데이터는 UE(1000), UE(1000)내의 UICC, UE(1000) 내에 상주하는 신뢰 모듈(1002) 등 상에 국부적으로 저장될 수 있다. 국부적으로 저장된 사용자 데이터의 인가 및 전송을 허용하는 매커니즘들이 제공된다. 사용자 인포 종단점은 예시된 실시예에 따라 신뢰 모듈(1002) 상에 위치될 수 있다.
예시적인 시나리오에서, 사용자는 예를 들어, 사용자의 사회 보장 번호(Social Security Number; SSN)와 같은 특정한 기밀 정보가 UE(1000) 상에 국부적으로 저장되기를 원할 수 있다. 이러한 국부적으로 저장된 정보는 네트워크/클라우드에서 보단 오히려 안전한/신뢰 하드웨어 모듈(1002) 또는 UICC 상에 저장될 수 있다. 예를 들어, UE 내의 사용자 및 OP/OPSF와 같은 다수의 이해당사자들에 의해 제어되고 구성될 수 있는 로컬 정책은 서비스 제공자(RP)/클라이언트(1006)로의 UE(1000)에 저장된 기밀 정보의 릴리즈를 인가할 수 있다.
예를 들어, 사용자들은 네트워크 또는 클라우드 상에 저장된 그들의 기밀 정보의 보안 및/또는 프라이버시(privacy)에 관해 확신하지 않을 수 있다. 이러한 정보는 예를 들어, 사용자들의 사회 보장 번호들을 포함할 수 있다. 사용자들은 UE 상에 그것을 저장함으로써 정보를 개인적으로 유지하도록 선택할 수 있다. 예시적인 구성에서, 사용자들은 네트워크 상에 몇몇 사용자 속성들(예를 들어, 이름, 주소 등)을 저장할 수 있는 반면에, 다른 사용자 속성들(예를 들어, SSN, 생일 등)은 UE의 안전 환경 상에 국부적으로 저장된다. 사용자가 금융 기관의 서비스들을 획득하기를 원하는 예시적인 시나리오에서, 이 기관은 사용자가 금융 기관에 의해 제공되는 서비스에 액세스하기 위해 사용자의 SSN을 요구할 수 있다. 예를 들어, 네트워크 기반 및/또는 로컬일 수 있는 성공적인 인증에 이어, UE에 관한 정책은 그 금융 기관으로의 국부적으로 저장된 SSN의 릴리즈를 인가할 수 있다. SSN이 국부적으로 저장되는 이러한 예시적인 시나리오에서, 다른 사용자 정보, 예를 들어, 비-기밀 사용자 속성들은 네트워크/클라우드로부터 그 기관에 의해 획득될 수 있다.
도 10을 참조하면, 1010에서, 브라우저 에이전트(BA)(1004)는 사용자 식별자를 SP/클라이언트/RP(1006)에 전송할 수 있고, RP(1006)에 의해 제공되는 서비스에 대한 액세스를 요청할 수 있다. 1012에서, RP(1006)는 인가 요청을 구축할 수 있고 (1014에서) BA(1005)가 인가 요청을 신뢰 모듈(1002)에 리디렉트하게 할 수 있다. 1016에서, UE(1000)의 사용자는 UE(1000)에서 인증될 수 있다. 1018에서, UE는 적어도 하나의 토큰을 RP(1006)에 발행하도록 하는 사용자 동의/인가를 갖는다고 결정할 수 있다. 1020에서, 신뢰 모듈(1002)(예를 들어, 로컬 OP)은 오픈ID 연결 프로토콜에 따라 토큰들을 생성할 수 있다. 신뢰 모듈(1002)은 1020에서 토큰들에 서명할 수 있다. 토큰 헤더는 헤더를 포함하는 토큰이 국부적으로 생성되었다고 결정하기 위해 OP(1008)에 대한 표시자를 포함할 수 있다. 1022에서, 신뢰 모듈(1002)은 이어서 1024에서 BA(1004)가 RP(1006)에 리디렉트하게 할 수 있는, 서명된 토큰들을 포함하는 리디렉트 메시지를 BA(1004)에 전달할 수 있다. 서명된 토큰들 중 하나 이상은 오픈ID 연결 프로토콜에 따라 포맷팅될 수 있는 액세스 토큰들을 포함할 수 있다. 예를 들어, 액세스 토큰들은 1020에서, OP(1008)와 같은 네트워크 엔티티의 지식 없이 또는 이런 지식을 이용하여 신뢰 모듈(1002)을 통해 UE(1000) 상에 국부적으로 생성될 수 있고 단계들(1022 및 1024)에서 SP/클라이언트/RP(1006)에 전송될 수 있다. 특정한 사용자 데이터 또는 사용자 데이터의 클래스와 연관되는 액세스 토큰은 액세스 토큰과 연관되는 사용자 인포 종단점의 위치에 대응하는 위치(예를 들어, URL)와 바인딩(bind)될 수 있다. 예시적인 구성에서, 사용자 데이터(예를 들어, 속성들)는 기밀 또는 비-기밀로서 분류될 수 있고, 기밀 데이터는 UE(1000) 상에 국부적으로 상주하는 사용자 인포 종단점으로부터 액세스될 수 있으며, 비-기밀 데이터는 네트워크 상에 상주하는 사용자 인포 종단점에서 액세스될 수 있다.
도 10을 계속 참조하면, 1026에서, RP(1006)는 ID 토큰을 포함할 수 있는 입증 토큰 요청 메시지를 통해 OP(1008)에서 체크 ID 종단점(1028)에 접촉할 수 있다. 1030에서, 체크 ID 종단점(1030)은 본 명세서에서 설명된 바와 같이 토큰 서명(S)을 검증할 수 있다. 1032에서, 체크 ID 종단점(1028)은 사용자의 인증 정보를 RP(1006)에 리턴할 수 있다. 예를 들어, 액세스 토큰이 요청되고 발행된 경우, 클라이언트(1006)는 요청된 액세스 토큰을 이용하여 사용자 데이터를 요청할 수 있다(1034). 예를 들어, 액세스 토큰은 사용자 인포 종단점(1036)을 호스트하는 신뢰 모듈(1002)의 위치와 같은 사용자 인포 종단점(1036)의 위치에 관한 정보를 전달할 수 있다. 대안적으로, 사용자 인포 종단점의 위치 정보는 예를 들어, 액세스 토큰의 부분이 되는 대신, 1024에서 리디렉트 메시지의 부분으로서 전송될 수 있다. 1034에서, RP(1006)는 예를 들어, 본 명세서에서 설명된 바와 같이 액세스 토큰을 이용함으로써 UE(1000) 상에 국부적으로 상주할 수 있는 사용자 인포 종단점(1036)으로부터 사용자 데이터를 요청할 수 있다. 1038에서, 신뢰 모듈(1002) 상에 상주할 수 있는 사용자 인포 종단점(1036)은 요청된 사용자 데이터(예를 들어, 사회 보장 번호, 주소 등)를 리턴할 수 있다. 예시적인 실시예에서, UE(1000)는 사용자 데이터가 RP(1006)에 의해 수신된 이후 클라이언트(1006)에 의해 제공되는 서비스에 대한 완전(full)한 액세스를 수신할 수 있다.
본 명세서에서 설명되는 다른 예시적인 실시예에서, 액세스 토큰들은 네트워크/클라우드에서 생성될 수 있다. 예를 들어, 네트워크 엔티티는 UE 대신 액세스 토큰을 생성할 수 있고, 토큰들은 SP/클라이언트/RP에 전송될 수 있다. 액세스 토큰들은 사용자 인포 종단점의 위치(예를 들어, URL)에 관한 정보를 전달할 수 있고, 위치는 UE 내의 신뢰 모듈 내에 또는 UE 상의 사용자 인포 종단점 또는 네트워크 클라우드의 엔티티에 대응할 수 있다. 사용자 인포 종단점 위치 정보는 액세스 토큰의 메시지 바디 내에서 전달될 수 있다.
토큰(들)으로 액세스 가능한 정보는 예시적인 실시예에 따라, 가능하게는, 아이덴티티 제공자 또는 네트워크/클라우드 엔티티의 지식 없이, UE 상에 상주할 수 있다. 대안적으로, 각각의 토큰들로 액세스 가능한 정보는 네트워크 클라우드에 상주할 수 있다. 토큰들의 정보는 토큰 데이터를 도청(eavesdropping)으로부터 보호하기 위해 서명되고 및/또는 암호화될 수 있다. 이러한 정보는 토큰 정보를 획득하기 위해 복호화될 수 있다. 이러한 조치들은 올바른 키를 갖는 정당한 SP/클라이언트/RP만이 토큰을 획득할 수 있다는 것을 보장할 수 있다. 토큰이 SP/클라이언트/RP에 의해 복호화되면, SP/클라이언트/RP는 사용자 인포 종단점에 토큰을 제시할 수 있다. UE 또는 UE 및/또는 네트워크/클라우드 엔티티 상의 신뢰 모듈은 토큰들을 생성 및/또는 검증하고, 요청된 데이터를 SP/클라이언트/RP에 제공할 수 있다. 정보 엘리먼트들은 네트워크와 UE 간에 분배되거나, 또는 네트워크와 UE 간에 공통적이거나 동기화될 수 있다.
예를 들어, 사용자 데이터는 UE 상에(예를 들어, UICC, 신뢰 모듈 등 상에) 국부적으로 저장될 수 있고, 사용자 데이터는 네트워크 엔티티(예를 들어, OP 등 상에) 상에 저장될 수 있고 사용자 데이터는 이들의 임의의 적절한 결합에 저장될 수 있다. 도 11은 예시적인 실시예에 따라 몇몇 사용자 데이터는 국부적으로 저장되고 몇몇 사용자 데이터는 네트워크 엔티티 상에 저장되는 호 흐름을 도시한다. 도 11을 참조하면, 도 10에 또한 있는 단계 번호들은 도 10에 관하여 위에서 설명되었다. 예시적인 구성에서, 기밀 데이터로서 자격을 갖춘 사용자 데이터는 국부적으로 저장될 수 있고, 비-기밀 데이터로서 자격을 갖춘 사용자 데이터는 네트워크/클라우드 엔티티 상에 저장될 수 있다. 대안적인 구성에서, 데이터는 분류되는 것이 아니라, 국부적으로 저장될 수 있고 데이터는 네트워크 엔티티 상에 저장될 수 있거나, 또는 데이터는 이들의 결합 상에 저장될 수 있다.
성공적인 사용자 인증 및 아이덴티티 토큰의 검증 시에, RP(1006)는 1100 및 1106에서 사용자 데이터(예를 들어, 사용자 속성들)를 요청할 수 있다. 예를 들어, 1100에서, RP는 신뢰 모듈(1002)에서 UE(1000) 내에 상주하는 사용자 인포 종단점(1102)으로부터 사용자 데이터를 검색하기 위해 제 1 액세스 토큰을 이용할 수 있다. 이러한 사용자 데이터는 기밀 데이터로서 분류될 수 있다. 제 1 액세스 토큰은 사용자 인포 종단점(1102)의 위치 정보를 포함할 수 있다. 1104에서, 예를 들어, 기밀 사용자 데이터는 RP(006)에 제공될 수 있다. 1106에서, RP(1006)는 예를 들어, OP(1008)와 같은 네트워크 엔티티 상에서 사용자 인포 종단점(1108)으로부터 사용자 데이터를 검색하기 위해 제 2 액세스 토큰을 이용할 수 있다. 이러한 사용자 데이터는 비-기밀 데이터로서 분류될 수 있다. 제 2 액세스 토큰은 RP(1106)가 사용자 인포 종단점(1108)으로부터의 사용자 데이터를 보완하기 위해 사용자 인포 종단점(1108)의 위치 정보(예를 들어, URL)를 포함할 수 있다. 기밀 데이터와 연관되고 UE(1000) 내의 저장소로부터 데이터를 획득하는데 이용되는 제 1 액세스 토큰은 로컬 OP(예를 들어, UE(1000)의 신뢰 모듈(1002))에 의해 제공될 수 있다. 사용자 인포 종단점(1102)의 위치(예를 들어, URL)는 또한 UE(1000)의 로컬 OP에 의해 제공될 수 있다. 예시적인 실시예에서, 예를 들어, 기밀 및 비-기밀 데이터로서 데이터가 RP(1006)에 의해 획득된 이후, 그것은 RP(1006)에서 결합되고 RP(1006)에 의해 제공되는 서비스들에 대한 액세스를 UE(1000)에 제공하기 위해 이용될 수 있다. 데이터는 RP(1006)에서 결합되고 소비될 수 있다.
따라서, 본 명세서에서 설명되는 바와 같이, 사용자 데이터의 각각의 액세스 토큰 또는 각각의 클래스(예를 들어, 기밀, 비-기밀, 민감, 일반 등)는 사용자 데이터의 위치와 연관될 수 있다. 사용자 데이터의 위치는 UICC와 같은 UE 또는 신뢰 모듈들의 위치(예를 들어, UE/UIEE로의 URL), 네트워크/클라우드의 위치(예를 들어, 네트워크/클라우드 내의 엔티티로의 URL), 또는 이들의 결합에 대응할 수 있다. 따라서 다양한 위치들에 저장되는 사용자 속성들은 SP/클라이언트/RP에 의해 요청되고, 프로세싱되고, 결합되고 소비될 수 있다.
예로서, UE(1000)는 RP(1006)와 같은 서비스 제공자에 대한 액세스 토큰을 생성하기 위한 인가 요청을 수신할 수 있다. 인가 요청에 기초하여, UE에서, 제 1 액세스 토큰이 생성될 수 있고, 제 2 액세스 토큰이 생성될 수 있다. 액세스 토큰들은 UE(1000)의 사용자 및 RP(1006)에 의해 제공되는 서비스와 연관될 수 있다. 제 1 액세스 토큰은 제 1 액세스 토큰의 검증 시에 RP(1006)에 제 1 요청된 사용자 속성을 제공하는 제 1 사용자 정보 종단점의 위치를 나타내는 정보를 포함할 수 있다. 제 2 액세스 토큰은 제 2 액세스 토큰의 검증 시에 RP(1006)에 제 2 요청된 사용자 속성을 제공하는 제 2 사용자 정보 종단점의 위치를 나타내는 정보를 포함할 수 있다. 제 1 사용자 정보 종단점은 UE(100) 상에 위치될 수 있고, 제 2 사용자 정보 종단점은 예를 들어, 네트워크를 통해 RP(1006)와 통신하는 OP(1008)와 같은 네트워크 엔티티 상에 위치될 수 있다.
도 12a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 통신 시스템(1400)의 도면이다. 통신 시스템(1400)은 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐츠를 다수의 무선 사용자들에 제공하는 다중 액세스 시스템일 수 있다. 통신 시스템(1400)은 무선 대역폭을 포함하는 시스템 자원들의 공유를 통해 다수의 무선 사용자들이 이러한 콘텐츠에 액세스하는 것을 가능하게 할 수 있다. 예를 들어, 통신 시스템들(1400)은 코드 분할 다중 액세스(code division multiple access; CDMA), 시분할 다중 액세스(time division multiple access ; TDMA), 주파수 분할 다중 액세스(frequency division multiple access; FDMA), 직교 FDMA(orthogonal FDMA; OFDMA), 단일-캐리어 FDMA(single-carrier FDMA; SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법들을 이용할 수 있다.
개시된 실시예들이 임의의 수의 WTRU들, 기지국들(BS들), 네트워크들 및/또는 네트워크 엘리먼트들을 기도(contemplate)한다고 인지될 것이지만, 도 12a에서 도시되는 바와 같이, 통신 시스템(1400)은 WTRU들(1402a, 1402b, 1402c, 1402d), 라디오 액세스 네트워크(radio access network; RAN)(1404), 코어 네트워크(1406), 공개 교환 전화 네트워크(public switched telephone network; PSTN)(1408), 인터넷(1410), 및 다른 네트워크들(1412)을 포함할 수 있다. WTRU들(1402a, 1402b, 1402c, 1402d) 각각은 무선 환경에서 동작 및/또는 통신하도록 구성되는 임의의 타입의 디바이스일 수 있다. 예로서, WTRU들(1402a, 1402b, 1402c, 1402d)은 무선 신호들을 전송 및/또는 수신하도록 구성될 수 있고, 사용자 장비(user equipment; UE), 모바일국, 고정 또는 이동 가입자 유닛, 페이저, 셀룰러 전화, 개인 휴대 정보 단말(personal digital assistant; PDA), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 소비자 전자기기 등을 포함할 수 있다.
통신 시스템들(1400)은 또한 기지국(1414a) 및 기지국(1414b)을 포함할 수 있다. 기지국들(1414a, 1414b) 각각은 코어 네트워크(1406), 인터넷(1410), 및/또는 다른 네트워크들(1412)와 같은 하나 이상의 통신 네트워크들에 대한 액세스를 용이하게 하기 위해 WTRU들(1402a, 1402b, 1402c, 1402d) 중 적어도 하나와 무선으로 인터페이스하도록 구성되는 임의의 타입의 디바이스일 수 있다. 예로서, 기지국들(1414a, 1414b)은 베이스 트랜시버 스테이션(base transceiver station; BTS), 노드 B, e노드B, 홈 노드 B, 홈 e노드B, 사이트 제어기, 액세스 포인트(AP), 무선 라우터 등일 수 있다. 기지국들(1414a, 1414b)이 단일의 엘리먼트로서 각각 도시되었지만, 기지국들(1414a, 1414b)은 임의의 수의 상호연결된 기지국들 및/또는 네트워크 엘리먼트들을 포함할 수 있다는 것이 인지될 것이다.
기지국(1414a)은 기지국 제어기(base station controller; BSC), 라디오 네트워크 제어기(radio network controller; RNC), 중계 노드들 등과 같은 다른 기지국들 및/또는 네트워크 엘리먼트들(도시되지 않음)을 또한 포함할 수 있는 RAN(1404)의 일부일 수 있다. 기지국(1414a) 및/또는 기지국(1414b)은 셀(도시되지 않음)로서 지칭될 수 있는 특정한 지리적인 영역 내에서 무선 신호들을 전송 및/또는 수신하도록 구성될 수 있다. 셀은 또한 셀 섹터들로 분할될 수 있다. 예를 들어, 기지국(1414a)과 연관된 셀은 3개의 섹터들로 분할될 수 있다. 따라서 실시예에서, 기지국(1414a)은 3개의 트랜시버들, 즉 셀의 각 섹터마다 하나의 트랜시버를 포함할 수 있다. 실시예에서, 기지국(1414a)은 다중-입력 다중 출력(multiple-input multiple output; MIMO) 기술을 이용할 수 있고, 그러므로 셀의 각 섹터에 대해 다수의 트랜시버들을 활용할 수 있다.
기지국들(1414a, 1414b)은 임의의 적합한 무선 통신 링크(예를 들어, 라디오 주파수(radio frequency; RF), 마이크로파, 적외선(infrared; IR), 자외선(ultraviolet; UV), 가시광 등)일 수 있는 공중 인터페이스(1416)를 통해 WTRU들(1402a, 1402b, 1402c, 1402d) 중 하나 이상의 WTRU와 통신할 수 있다. 공중 인터페이스(1416)는 임의의 적합한 라디오 액세스 기술(RAT)을 이용하여 설정될 수 있다.
보다 구체적으로, 상술한 바와 같이, 통신 시스템(1400)은 다중 액세스 시스템일 수 있으며 CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 액세스 방식들을 이용할 수 있다. 예를 들어, RAN(1404)의 기지국(1414a) 및 WTRU(1402a, 1402b, 1402c)는 광대역 CDMA(WCDMA)를 이용하여 공중 인터페이스(1416)를 설정할 수 있는 유니버셜 모바일 원격통신 시스템(Universal Mobile Telecommunications System; UMTS) 지상 라디오 액세스(Terrestrial Radio Access; UTRA)와 같은 라디오 기술을 구현할 수 있다. WCDMA는 고속 패킷 액세스(High-Speed Packet Access; HSPA) 및/또는 이볼브드 HSPA(HSPA+)와 같은 통신 프로토콜들을 포함할 수 있다. HSPA는 고속 다운링크 패킷 액세스(High-Speed Downlink Packet Access; HSDPA) 및/또는 고속 업링크 패킷 액세스(High-Speed Uplink Packet Access; HSUPA)를 포함할 수 있다.
실시예에서, 기지국(1414a) 및 WTRU들(1402a, 1402b, 1402c)은 롱텀 에볼루션(Long Term Evolution; LTE) 및/또는 LTE-어드밴스드(LTE- Advanced; LTE-A)를 이용하여 공중 인터페이스(1416)를 설정할 수 있는 이볼브드 UMTS 지상 라디오 액세스(E-UTRA)와 같은 라디오 기술을 구현할 수 있다.
다른 실시예들에서, 기지국(1414a) 및 WTRU들(1402a, 1402b, 1402c)은 IEEE 802.16(즉, WiMAX(Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA 2000 EV-DO, 잠정적인 표준 2000(IS-2000), 잠정적인 표준 95(IS-95), 잠정적인 표준 856(IS-856), 모바일 통신을 위한 글로벌 시스템(Global System for Mobile communications; GSM), GSM 에볼루션을 위한 강화된 데이터 레이트(Enhanced Data rates for GSM Evolution; EDGE), GSM/EDGE RAN(GERAN) 등과 같은 라디오 기술들을 구현할 수 있다.
도 12a의 기지국(1414b)은 예를 들어, 무선 라우터, 홈 노드 B, 홈 e노드 B, 펨토 셀 기지국, 또는 액세스 포인트일 수 있으며 비즈니스, 가정, 차량, 캠퍼스 등의 장소와 같이 로컬화된 영역에서 무선 연결을 용이하게 하는 임의의 적합한 RAT를 활용할 수 있다. 실시예에서, 기지국(1414b) 및 WTRU들(1402c, 1402d)은 무선 로컬 영역 네트워크(wireless local area network; WLAN)를 설정하기 위해 IEEE 802.11과 같은 라디오 기술을 구현할 수 있다. 실시예에서, 기지국(1414b) 및 WTRU들(1402c, 1402d)은 무선 개인 영역 네트워크(wireless personal area network; WPAN)을 설정하기 위해 IEEE 802.15와 같은 라디오 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(1414b) 및 WTRU들(1402c, 1402d)은 피코셀 또는 펨토셀을 설정하기 위해 셀룰러-기반 RAT(예를 들어, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 활용할 수 있다. 도 12a에서 도시되는 바와 같이, 기지국(1414b)은 인터넷(1410)에 직접 연결할 수 있다. 따라서 기지국(1414b)은 코어 네트워크(1406)를 통해 인터넷(1410)에 액세스하도록 요구되지 않을 수 있다.
RAN(1404)은 WTRU들(1402a, 1402b, 1402c, 1402d) 중 하나 이상의 WTRU에 음성, 데이터, 애플리케이션들, 및/또는 보이스 오버 인터넷 프로토콜(voice over internet protocol; VoIP) 서비스들을 제공하도록 구성되는 임의의 타입의 네트워크일 수 있는 코어 네트워크(1406)와 통신할 수 있다. 예를 들어, 코어 네트워크(1406)는 호 제어, 계산서발송 서비스들(billing services), 모바일 위치-기반 서비스들, 선불 호출(pre paid calling), 인터넷 연결, 비디오 분배 등을 제공할 수 있고 및/또는 사용자 인증과 같은 고-레벨 보안 기능들을 수행할 수 있다. 도 12a에 도시되지 않았지만, RAN(1404) 및/또는 코어 네트워크(1406)는 RAN(1404)과 같은 동일한 RAT 또는 상이한 RAT를 이용하는 다른 RAN들과 직접적으로 또는 간접적으로 통신할 수 있다는 것이 인지될 것이다. 예를 들어, E-UTRA 라디오 기술을 활용할 수 있는 RAN(1404)에 연결되는 것 외에, 코어 네트워크(1406)는 또한 GSM 라디오 기술을 이용하는 다른 RAN(도시되지 않음)과 통신할 수 있다.
코어 네트워크(1406)는 또한 WTRU들(1402a, 1402b, 1402c, 1402d)이 PSTN(1408), 인터넷(1410) 및/또는 다른 네트워크(1412)에 액세스하기 위한 게이트웨이로서 역할할 수 있다. PSTN(1408)은 기존 전화 서비스(plain old telephone service; POTS)를 제공하는 회선-교환 전화 네트워크들을 포함할 수 있다. 인터넷(1410)은 전송 제어 프로토콜(transmission control protocol; TCP), 사용자 데이터그램 프로토콜(user datagram protocol; UDP) 및 TCP/IP 인터넷 프로토콜 스위트(suite)의 인터넷 프로토콜(internet protocol; IP)과 같이 공통 통신 프로토콜들을 이용하는 상호연결된 컴퓨터 네트워크들 및 디바이스들의 글로벌 시스템을 포함할 수 있다. 네트워크들(1412)는 다른 서비스 제공자들에 의해 소유되고 및/또는 운용되는 유선 또는 무선 통신 네트워크들을 포함할 수 있다. 예를 들어, 네트워크들(1412)은 RAN(1404)과 동일한 RAT 또는 상이한 RAT를 이용할 수 있는 하나 이상의 RAN들에 연결된 다른 코어 네트워크를 포함할 수 있다.
통신 시스템(100)의 WTRU들(1402a, 1402b, 1402c, 1402d) 중 일부 또는 모두 다는 다중-모드 성능들을 포함할 수 있는데, 즉, WTRU들(1402a, 1402b, 1402c, 1402d)은 상이한 무선 링크들을 통해 상이한 무선 네트워크들과 통신하기 위해 다수의 트랜시버들을 포함할 수 있다. 예를 들어, 도 12a에 도시된 WTRU(1402c)는 셀룰러-기반 라디오 기술을 이용할 수 있는 기지국(1414a)과, 그리고 IEEE 802 라디오 기술을 이용할 수 있는 기지국(1414b)과 통신하도록 구성될 수 있다.
도 12b는 예시적인 WTRU(1402)의 시스템도이다. 도 12b에서 도시되는 바와 같이, WTRU(1402)는 프로세서(1418), 트랜시버(1420), 전송/수신 엘리먼트(1422), 스피커/마이크로폰(1424), 키패드(1426), 디스플레이/터치패드(1428), 비분리형 메모리(1430), 분리형 메모리(1432), 전원(1434), 글로벌 포지셔닝 시스템(GPS) 칩셋(1436), 및 다른 주변기기들(1438)을 포함할 수 있다. WTRU(1402)는 일 실시예와 일관됨을 유지하면서 상술한 엘리먼트들의 임의의 서브-조합을 포함할 수 있다는 것이 인지될 것이다.
프로세서(1418)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(digital signal processor; DSP), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, 주문형 집적 회로(application specific integrated circuit; ASIC)들, 필드 프로그래밍 가능한 게이트 어레이(field programmable gate array; FPGA) 회로들, 임의의 다른 타입의 집적 회로(integrated circuit; IC), 상태 머신 등일 수 있다. 프로세서(1418)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입력/출력 프로세싱, 및/또는 WTRU(1402)가 무선 환경에서 동작하는 것을 가능하게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(1418)는 전송/수신 엘리먼트(1422)에 결합될 수 있는 트랜시버(1420)에 결합될 수 있다. 도 12b가 프로세서(1418) 및 트랜시버(1420)를 별개의 컴포넌트들로서 도시하지만, 프로세서(1418) 및 트랜시버(1420)는 전자 패키지 또는 칩에 함께 통합될 수 있다는 것이 인지될 것이다. 프로세서(1418)는 애플리케이션-층 프로그램(예를 들어, 브라우저들) 및/또는 라디오 액세스-층(RAN) 프로그램들 및/또는 통신들을 수행할 수 있다. 프로세서(1418)는 예를 들어, 액세스-층 및/또는 애플리케이션 층에서와 같이, 인증, 보안 키 동의 및/또는 암호 동작들과 같은 보안 동작들을 수행할 수 있다.
예시적인 실시예에서, WTRU(1402)는 프로세서(1418) 및 프로세서에 결합된 메모리를 포함한다. 메모리는, 프로세서에 의해 실행될 때, 프로세서로 하여금 오픈ID 프로토콜의 기능을 국부적으로 수행하는 것과 연관된 동작들을 유발하게 하는 실행 가능한 명령어들을 포함할 수 있다.
전송/수신 엘리먼트(1422)는 공중 인터페이스(1416)를 통해 기지국(예를 들어, 기지국(1414a))에 신호들을 전송하거나 기지국으로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 전송/수신 엘리먼트(1422)는 RF 신호들을 전송 및/또는 수신하도록 구성되는 안테나일 수 있다. 실시예에서, 전송/수신 엘리먼트(1422)는 예를 들어, IR, UV, 또는 가시광 신호들을 전송 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 다른 실시예에서, 전송/수신 엘리먼트(1422)는 RF 및 광 신호들 둘 다를 전송 및 수신하도록 구성될 수 있다. 전송/수신 엘리먼트(1422)는 무선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것이 인지될 것이다.
또한, 전송/수신 엘리먼트(1422)가 단일의 엘리먼트로서 도 12b에서 도시되었지만, WTRU(1402)는 임의의 수의 전송/수신 엘리먼트들(1422)을 포함할 수 있다. 보다 구체적으로, WTRU(1402)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, WTRU(1402)는 공중 인터페이스(1416)를 통해 무선 신호들을 전송하고 수신하기 위해 2개 이상의 전송/수신 엘리먼트들(1422)(예를 들어, 다수의 안테나들)을 포함할 수 있다.
트랜시버(1420)는 전송/수신 엘리먼트(1422)에 의해 전송될 신호들을 변조하고 전송/수신 엘리먼트(1422)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 상술한 바와 같이, WTRU(1402)는 다중-모드 성능들을 가질 수 있다. 따라서 트랜시버(1420)는 WTRU(1402)가 예를 들어, UTRA 및 IEEE 802.11과 같이 다중 RAT들을 통해 통신하는 것을 가능하게 하기 위해 다수의 트랜시버들을 포함할 수 있다.
WTRU(1402)의 프로세서(1418)는 스피커/마이크로폰(1424), 키패드(1426), 및/또는 디스플레이/터치패드(1428)(예를 들어, 액정 디스플레이(LCD) 디스플레이 유닛 또는 유기 발광 다이오드(OLED) 디스플레이 유닛)에 결합될 수 있고, 스피커/마이크로폰(1424), 키패드(1426), 및/또는 디스플레이/터치패드(1428)로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(1418)는 또한 스피커/마이크로폰(1424), 키패드(1426), 및/또는 디스플레이/터치패드(1428)에 사용자 데이터를 출력할 수 있다. 또한, 프로세서(1418)는 비분리형 메모리(1430) 및/또는 분리형 메모리(1432)와 같은 임의의 타입의 적합한 메모리에 데이터를 저장하고, 이로부터 정보를 액세스할 수 있다. 비분리형 메모리(1430)는 랜덤-액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드디스크 또는 임의의 다른 타입의 메모리 저장 디바이스를 포함할 수 있다. 분리형 메모리(1432)는 가입자 아이덴티티 모듈(SIM) 카드, 메모리 스틱, 안전한 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(1418)는 서버 또는 홈 컴퓨터(도시되지 않음) 상에서와 같이 WTRU(1402) 상에 물리적으로 위치되지 않는 메모리에 데이터를 저장하고, 이로부터 정보를 액세스할 수 있다.
프로세서(1418)는 전원(1434)으로부터 전력을 수신할 수 있고, WTRU(1402)의 다른 컴포넌트들에 전력을 분배 및/또는 제어하도록 구성될 수 있다. 전원(1434)은 WTRU(1402)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전원(1434)은 하나 이상의 건전지들(예를 들어, NiCd(nickel-cadmium), NiZn(nickel-zinc), NiMH(nickel metal hydride), Li-ion(lithium-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수 있다.
프로세서(1418)는 또한 WTRU(1402)의 현재 위치에 관한 위치 정보(예를 들어, 위도 및 경도)를 제공하도록 구성될 수 있는 GPS 칩셋(1436)에 결합될 수 있다. GPS 칩셋(1436)으로부터의 정보 외에 또는 그 대신에, WTRU(1402)는 기지국(예를 들어, 기지국들(1414a, 1414b))으로부터 공중 인터페이스(1416)를 통해 위치 정보를 수신할 수 있고 및/또는 둘 이상의 근처의 기지국들로부터 수신되는 신호들의 타이밍에 기초하여 그 위치를 결정할 수 있다. WTRU(1402)가 일 실시예와 일관됨을 유지하면서 임의의 적합한 위치-결정 방법에 의해 위치 정보를 획득할 수 있다는 것이 인지될 것이다.
프로세서(1418)는 부가적인 특징들, 기능 및/또는 유선 또는 무선 연결을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈들을 포함할 수 있는 다른 주변기기들(1438)에 추가로 결합될 수 있다. 예를 들어, 주변기기들(1438)은 가속도계, e-나침반, 위성 트랜시버, 디지털 카메라(사진 또는 비디오 용), 범용 직렬 버스(USB) 포트, 진동 디바이스, 텔레비전 트랜시버, 핸즈 프리 헤드셋, 블루투쓰® 모듈, 주파수 변조(FM) 라디오 유닛, 디지털 음악 재생기, 미디어 재생기, 비디오 게임 재생기 모듈, 인터넷 브라우저 등을 포함할 수 있다.
도 12c는 일 실시예에 따라 RAN(1404)와 코어 네트워크(1430)의 시스템도이다. 위에서 언급한 바와 같이, RAN(1404)는 공중 인터페이스(1416)를 통해 WTRU들(1402a, 1402b, 1402c)과 통신하기 위해 UTRA 라디오 기술을 이용한다. RAN(1404)는 또한 코어 네트워크(1430)와 통신하게 될 수 있다. 도 12c에서 도시되는 바와 같이, RAN(1404)은 공중 인터페이스(1416)를 통해 WTRU들(1402a, 1402b, 1402c)과 통신하기 위해 하나 이상의 트랜시버들을 각각 포함할 수 있는 노드-B들(1440a, 1440b, 1440c)을 포함할 수 있다. 노드-B들(1440a, 1440b, 1440c)은 RAN(1404)내의 특정한 셀(도시되지 않음)과 각각 연관될 수 있다. RAN(1404)는 또한 RNC들(142a, 142b)을 포함할 수 있다. RAN(1404)는 실시예들과 일관됨을 유지하면서 임의의 수의 노드-B들 및 RNC들을 포함할 수 있다는 것이 인지될 것이다.
도 12c에서 도시되는 바와 같이, 노드-B들(1440a, 1440b)은 RNC(1442a)와 통신할 수 있다. 또한, 노드-B(1440c)는 RNC(1404b)와 통신할 수 있다. 노드-B들(1440a, 1440b, 1440c)은 Iub 인터페이스를 통해 각각의 RNC들(1442a, 1442b)과 통신할 수 있다. RNC들(1442a, 1442b)은 Iur 인터페이스를 통해 서로 통신할 수 있다. RNC들(1442a, 1442b) 각각은 자신이 연결된 각각의 노드-B들(1440a, 1440b, 1440c)을 제어하도록 구성될 수 있다. 또한, RNC들(1442a, 1442b) 각각은 외부 루프 전력 제어, 로드 제어, 승인 제어, 패킷 스케줄링, 핸드오버 제어, 매크로다이버시트(macrodiversity), 보안 기능들, 데이터 암호화 등과 같은 기타 기능을 수행하거나 및/또는 지원하도록 구성될 수 있다.
도 12c에서 도시된 코어 네트워크(1430)는 미디어 게이트웨이(MGW)(1444), 모바일 스위칭 센터(MSC)(1446), 서빙 GPRS 지원 노드(SGSN)(1448), 및/또는 게이트웨이 GPRS 지원 노드(GGSN)(1450)를 포함할 수 있다. 상술한 엘리먼트들 각각이 코어 네트워크(1406)의 부분으로서 도시되지만, 이들 엘리먼트들 중 임의의 엘리먼트는 코어 네트워크 운용자 이외의 엔티티에 의해 소유되고 및/또는 운용될 수 있다는 것이 인지될 것이다.
RAN(1404)의 RNC(1442a)는 IuCS 인터페이스를 통해 코어 네트워크(1430)의 MSC(1446)에 연결될 수 있다. MSC(1446)은 MGW(144)에 연결될 수 있다. MSC(1446) 및 MGW(1444)는 PSTN(108)과 같은 회선 교환 네트워크들에 대한 액세스를 WTRU들(1402a, 1402b, 1402c)에 제공하여 WTRU들(1402a, 1402b, 1402c)과 기존의 지상-라인 통신 디바이스들 간의 통신을 용이하게 할 수 있다.
RAN(1404)의 RNC(1442a)는 또한 IuPS 인터페이스를 통해 코어 네트워크(1430)의 SGSN(1448)에 연결될 수 있다. SGSN(1448)은 GGSN(1450)에 연결될 수 있다. SGSN(1448) 및 GGSN(1450)은 인터넷(110)과 같은 패킷-교환 네트워크들에 대한 액세스를 WTRU들(1402a, 1402b, 1402c)에 제공하여 WTRU들(1402a, 1402b, 1402c)과 IP-인에이블 디바이스들(IP-enabled devices) 간의 통신을 용이하게 할 수 있다.
위에서 언급한 바와 같이, 코어 네트워크(1406)는 또한 다른 유선 또는 무선 네트워크들을 포함할 수 있는 네트워크들(1412)에 연결될 수 있으며, 다른 유선 또는 무선 네트워크들은 다른 서비스 제공자들에 의해 소유되고 및/또는 운용된다.
특징들 및 엘리먼트들이 특정한 결합으로 위에서 설명되었지만, 당업자는 각각의 특징 또는 엘리먼트가 다른 특징들 및 엘리먼트들과의 임의의 결합으로 또는 단독으로 이용될 수 있다는 것이 인지될 것이다. 부가적으로, 당업자는 본 명세서에서 설명된 실시예들이 예시 목적만을 위해 제공되었다는 것을 인지할 것이다. 예를 들어, 실시예들이 로컬 오픈ID 아이덴티티 제공자(OP)를 이용하여 본 명세서에서 설명될 수 있지만, 비-로컬 OP 또는 외부 OP가 유사한 기능들을 수행하기 위해 이용될 수 있으며, 그 반대도 가능하다. 또한, 본 명세서에서 설명되는 실시예들은 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터-판독 가능한 매체에 통합되는 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터-판독 가능한 매체들의 예들은 전자 신호들(유선 또는 무선 연결들을 통해 송신됨) 및 컴퓨터-판독 가능한 저장 매체들을 포함한다. 컴퓨터 판독 가능한 저장 매체들의 예들은, 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스, 내부 하드 디스크들 및 분리형 디스크들과 같은 자기 매체들, 자기-광학 매체들 및 CD-ROM 디스크들 및 디지털 다용도 디스크들(DVD들)과 같은 광학 매체들을 포함(그러나 이들로 제한되지 않음)한다. 소프트웨어와 연관되는 프로세서는 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 이용하기 위해 라디오 주파수 트랜시버를 구현하는데 이용될 수 있다.
102: 서비스 제공자
104: 로컬 OP
106: 브라우저
108: MNO 네트워크
200: 로컬 OP
202: 브라우저
204: 서비스
300: 클라이언트
302: 제공자
304: 사용자 공급 식별자
306: 정규화
308: 호스트로의 HTTP GET 요청
310: HTTP 응답

Claims (20)

  1. 네트워크를 통해 통신하는 사용자 장비(user equipment; UE), 아이덴티티 제공자(identity provider; IdP) 및 서비스 제공자(service provider; SP)를 포함하는 시스템 내에서 아이덴티티 관리를 수행하는 방법에 있어서,
    적어도 하나의 토큰(token)에 대한 요청을 수신하는 단계로서, 상기 토큰에 대한 요청은 상기 서비스 제공자에 의해 제공되는 서비스에 대한 액세스를 위한 요청에 응답하는 것인, 상기 수신하는 단계;
    상기 SP에 대한 액세스 토큰을 생성하기 위한 인가 요청(authorization request) - 상기 인가 요청은 상기 UE의 사용자에 의해 승인됨 - 을 상기 UE에 의해 수신하는 단계;
    상기 인가 요청에 응답하여, 상기 UE에서, 상기 인가 요청의 사용자 승인과 연관되는 상기 액세스 토큰을 생성하는 단계;
    상기 서비스에 대한 UE 액세스를 제공하기 위해 아이덴티티(ID) 토큰이 검증되도록, 상기 적어도 하나의 토큰에 대한 요청에 따라 상기 ID 토큰을 상기 UE에 의해 발행(issue)하는 단계;
    상기 UE에 의해, 상기 액세스 토큰을 발행하는 단계; 및
    상기 액세스 토큰이 검증(verify)되면, 상기 UE 상에 상주하는 사용자 정보 종단점에 의해, 사용자 속성(user attribute)을 릴리즈(release)하는 단계
    를 포함하는, 아이덴티티 관리 수행 방법.
  2. 제 1 항에 있어서, 상기 ID 토큰은 상기 UE 내에 상주하는 신뢰 환경(trusted environment)에서 안전하게(securely) 생성되는 것인, 아이덴티티 관리 수행 방법.
  3. 삭제
  4. 제 1 항에 있어서, 상기 인가 요청의 사용자 승인은 상기 UE의 정책을 통해 자동으로 수신되는 것인, 아이덴티티 관리 수행 방법.
  5. 제 1 항에 있어서, 상기 액세스 토큰은 상기 사용자 정보 종단점의 위치를 나타내는 정보를 포함하고, 상기 사용자 정보 종단점은 상기 액세스 토큰의 검증 시에 상기 SP에 요청된 사용자 속성을 제공하는 것인, 아이덴티티 관리 수행 방법.
  6. 제 5 항에 있어서, 상기 액세스 토큰의 검증은 상기 SP에의 요청된 사용자 속성의 릴리즈(release)에 상기 사용자가 동의(consent)했다는 검증을 포함하는 것인, 아이덴티티 관리 수행 방법.
  7. 제 5 항에 있어서, 상기 액세스 토큰은 상기 UE 내에 상주하는 신뢰 환경에서 안전하게 생성되고, 상기 액세스 토큰의 검증은 상기 신뢰 환경이 유효하다는 검증을 포함하는 것인, 아이덴티티 관리 수행 방법.
  8. 제 1 항에 있어서, 상기 ID 토큰 및 상기 액세스 토큰은 오픈ID 연결 프로토콜(OpenID Connect protocol)에 따라 생성되는 것인, 아이덴티티 관리 수행 방법.
  9. 제 1 항에 있어서,
    상기 ID 토큰 및 상기 액세스 토큰은 상기 UE 내에 상주하는 신뢰 환경에서 안전하게 생성되고, 상기 아이덴티티 관리 수행 방법은,
    신뢰 모듈을 통해 상기 사용자의 인증 상태(authentication status)를 결정하는 단계; 및
    상기 사용자가 인증되지 않았다고 상기 인증 상태가 표시하면, 상기 신뢰 환경에서 상기 사용자를 인증하는 단계
    를 더 포함하는 것인, 아이덴티티 관리 수행 방법.
  10. 제 1 항에 있어서,
    상기 액세스 토큰은 제 1 액세스 토큰이고, 상기 아이덴티티 관리 수행 방법은,
    상기 인가 요청에 기초하여, 상기 UE에서, 상기 제 1 액세스 토큰 및 제 2 액세스 토큰 - 상기 액세스 토큰들은 상기 서비스 및 상기 사용자와 연관됨 - 을 생성하는 단계
    를 더 포함하는 것인, 아이덴티티 관리 수행 방법.
  11. 제 10 항에 있어서,
    상기 사용자 정보 종단점은 제 1 사용자 정보 종단점이고,
    상기 제 1 액세스 토큰은, 상기 제 1 액세스 토큰의 검증 시에 상기 SP에 제 1 요청된 사용자 속성을 제공하는 제 1 사용자 정보 종단점의 위치를 나타내는 정보를 포함하고,
    상기 제 2 액세스 토큰은, 상기 제 2 액세스 토큰의 검증 시에 상기 SP에 제 2 요청된 사용자 속성을 제공하는 제 2 사용자 정보 종단점의 위치를 나타내는 정보를 포함하고,
    상기 제 1 사용자 정보 종단점은 상기 UE 상에 위치되며,
    상기 제 2 사용자 정보 종단점은 상기 네트워크를 통해 상기 SP와 통신하는 네트워크 엔티티 상에 위치되는 것인, 아이덴티티 관리 수행 방법.
  12. 제 11 항에 있어서,
    상기 제 1 사용자 정보 종단점에 의해 제공된 상기 제 1 요청된 사용자 속성은 상기 사용자에 의해 기밀 데이터로서 분류되고,
    상기 제 2 사용자 정보 종단점에 의해 제공된 상기 제 2 요청된 사용자 속성은 상기 사용자에 의해 비-기밀(nonconfidential) 데이터로서 분류되는 것인, 아이덴티티 관리 수행 방법.
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 무선 송수신 유닛(wireless/transmit receive unit; WTRU)에 있어서,
    실행 가능한 명령어들을 포함하는 메모리; 및
    상기 메모리와 통신하는 프로세서
    를 포함하고,
    상기 명령어들은 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금,
    적어도 하나의 토큰에 대한 요청을 수신하는 동작으로서, 상기 토큰에 대한 요청은 서비스 제공자(service provider; SP)에 의해 제공된 서비스에 대한 액세스를 위한 요청에 응답하는 것인, 상기 수신하는 동작;
    상기 SP에 대한 액세스 토큰을 생성하기 위한 인가 요청 - 상기 인가 요청은 상기 WTRU의 사용자에 의해 승인됨 - 을 수신하는 동작;
    상기 인가 요청에 응답하여, 상기 인가 요청의 사용자 승인과 연관되는 상기 액세스 토큰을 생성하는 동작;
    상기 적어도 하나의 토큰에 대한 요청에 따라 아이덴티티(ID) 토큰 - 상기 서비스에 대한 WTRU 액세스를 제공하기 위해 상기 ID 토큰이 검증됨 - 을 발행(issue)하는 동작;
    상기 액세스 토큰을 발행하는 동작; 및
    상기 액세스 토큰이 검증(verify)되면, 상기 WTRU 상에 상주하는 사용자 정보 종단점에 의해, 사용자 속성(user attribute)을 릴리즈(release)하는 동작
    을 포함하는 동작들을 실시하게 하는 것인, 무선 송수신 유닛(WTRU).
  18. 삭제
  19. 제 17 항에 있어서,
    상기 액세스 토큰은 사용자 정보 종단점의 위치를 나타내는 정보를 포함하고, 상기 사용자 정보 종단점은 상기 액세스 토큰의 검증 시에 상기 SP에 요청된 사용자 속성을 제공하는 것인, 무선 송수신 유닛(WTRU).
  20. 제 19 항에 있어서,
    상기 액세스 토큰의 검증은 상기 SP에의 상기 요청된 사용자 속성의 릴리즈에 상기 사용자가 동의했다는 검증을 포함하는 것인, 무선 송수신 유닛(WTRU).
KR1020167017358A 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리 KR101730459B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261589125P 2012-01-20 2012-01-20
US61/589,125 2012-01-20
PCT/US2013/022105 WO2013109857A1 (en) 2012-01-20 2013-01-18 Identity management with local functionality

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020147023299A Division KR101636028B1 (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020177010722A Division KR20170046191A (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리

Publications (2)

Publication Number Publication Date
KR20160079153A KR20160079153A (ko) 2016-07-05
KR101730459B1 true KR101730459B1 (ko) 2017-04-26

Family

ID=47913537

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020167017358A KR101730459B1 (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리
KR1020147023299A KR101636028B1 (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리
KR1020177010722A KR20170046191A (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리

Family Applications After (2)

Application Number Title Priority Date Filing Date
KR1020147023299A KR101636028B1 (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리
KR1020177010722A KR20170046191A (ko) 2012-01-20 2013-01-18 로컬 기능을 갖는 아이덴티티 관리

Country Status (7)

Country Link
US (1) US9774581B2 (ko)
EP (1) EP2805470B1 (ko)
JP (1) JP2015511348A (ko)
KR (3) KR101730459B1 (ko)
CN (1) CN104115465A (ko)
TW (1) TW201345217A (ko)
WO (1) WO2013109857A1 (ko)

Families Citing this family (152)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10181953B1 (en) 2013-09-16 2019-01-15 Amazon Technologies, Inc. Trusted data verification
WO2000079452A2 (en) * 1999-06-18 2000-12-28 Echarge Corporation Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US9237155B1 (en) 2010-12-06 2016-01-12 Amazon Technologies, Inc. Distributed policy enforcement with optimizing policy transformations
US8769642B1 (en) 2011-05-31 2014-07-01 Amazon Technologies, Inc. Techniques for delegation of access privileges
US9264237B2 (en) 2011-06-15 2016-02-16 Microsoft Technology Licensing, Llc Verifying requests for access to a service provider using an authentication component
US9197409B2 (en) 2011-09-29 2015-11-24 Amazon Technologies, Inc. Key derivation techniques
US9203613B2 (en) 2011-09-29 2015-12-01 Amazon Technologies, Inc. Techniques for client constructed sessions
US9178701B2 (en) 2011-09-29 2015-11-03 Amazon Technologies, Inc. Parameter based key derivation
US9081951B2 (en) 2011-09-29 2015-07-14 Oracle International Corporation Mobile application, identity interface
US10212588B2 (en) * 2011-10-25 2019-02-19 Salesforce.Com, Inc. Preemptive authorization automation
US10225264B2 (en) 2011-10-25 2019-03-05 Salesforce.Com, Inc. Automated authorization response techniques
US10225242B2 (en) * 2011-10-25 2019-03-05 Salesforce.Com, Inc. Automated authorization response techniques
US10733151B2 (en) 2011-10-27 2020-08-04 Microsoft Technology Licensing, Llc Techniques to share media files
US9003507B2 (en) * 2012-03-23 2015-04-07 Cloudpath Networks, Inc. System and method for providing a certificate to a third party request
US8892865B1 (en) 2012-03-27 2014-11-18 Amazon Technologies, Inc. Multiple authority key derivation
US8739308B1 (en) 2012-03-27 2014-05-27 Amazon Technologies, Inc. Source identification for unauthorized copies of content
US9215076B1 (en) 2012-03-27 2015-12-15 Amazon Technologies, Inc. Key generation for hierarchical data access
US9571282B1 (en) 2012-04-03 2017-02-14 Google Inc. Authentication on a computing device
US10423952B2 (en) * 2013-05-06 2019-09-24 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US11334884B2 (en) * 2012-05-04 2022-05-17 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
WO2013166518A1 (en) * 2012-05-04 2013-11-07 Institutional Cash Distributors Technology, Llc Secure transaction object creation, propagation and invocation
KR102093757B1 (ko) * 2012-05-24 2020-03-26 삼성전자 주식회사 ｅＵＩＣＣ 환경에서 ＳＩＭ 프로파일을 제공하는 방법 및 장치
US9660972B1 (en) 2012-06-25 2017-05-23 Amazon Technologies, Inc. Protection from data security threats
US9258118B1 (en) 2012-06-25 2016-02-09 Amazon Technologies, Inc. Decentralized verification in a distributed system
US9152781B2 (en) * 2012-08-09 2015-10-06 Cisco Technology, Inc. Secure mobile client with assertions for access to service provider applications
GB2508207A (en) * 2012-11-23 2014-05-28 Intercede Ltd Controlling access to secured data stored on a mobile device
US9038142B2 (en) 2013-02-05 2015-05-19 Google Inc. Authorization flow initiation using short-term wireless communication
US9124911B2 (en) 2013-02-15 2015-09-01 Cox Communications, Inc. Storage optimization in a cloud-enabled network-based digital video recorder
US10601798B2 (en) 2013-03-15 2020-03-24 Cox Communications, Inc. Federated services managed access to services and content
US9294454B2 (en) * 2013-03-15 2016-03-22 Microsoft Technology Licensing, Llc Actively federated mobile authentication
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US9305298B2 (en) 2013-03-22 2016-04-05 Nok Nok Labs, Inc. System and method for location-based authentication
US9246892B2 (en) 2013-04-03 2016-01-26 Salesforce.Com, Inc. System, method and computer program product for managing access to systems, products, and data based on information associated with a physical location of a user
US9426155B2 (en) * 2013-04-18 2016-08-23 International Business Machines Corporation Extending infrastructure security to services in a cloud computing environment
US9407440B2 (en) 2013-06-20 2016-08-02 Amazon Technologies, Inc. Multiple authority data security and access
US9521000B1 (en) 2013-07-17 2016-12-13 Amazon Technologies, Inc. Complete forward access sessions
US9160731B2 (en) * 2013-09-06 2015-10-13 International Business Machines Corporation Establishing a trust relationship between two product systems
US9237019B2 (en) 2013-09-25 2016-01-12 Amazon Technologies, Inc. Resource locators with keys
US9311500B2 (en) 2013-09-25 2016-04-12 Amazon Technologies, Inc. Data security using request-supplied keys
US10243945B1 (en) * 2013-10-28 2019-03-26 Amazon Technologies, Inc. Managed identity federation
US9397990B1 (en) * 2013-11-08 2016-07-19 Google Inc. Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud
US9106620B2 (en) * 2013-11-14 2015-08-11 Comcast Cable Communications, Llc Trusted communication session and content delivery
US20150150109A1 (en) * 2013-11-27 2015-05-28 Adobe Systems Incorporated Authenticated access to a protected resource using an encoded and signed token
US9420007B1 (en) 2013-12-04 2016-08-16 Amazon Technologies, Inc. Access control using impersonization
US9374368B1 (en) 2014-01-07 2016-06-21 Amazon Technologies, Inc. Distributed passcode verification system
US9369461B1 (en) 2014-01-07 2016-06-14 Amazon Technologies, Inc. Passcode verification using hardware secrets
US9292711B1 (en) 2014-01-07 2016-03-22 Amazon Technologies, Inc. Hardware secret usage limits
US9270662B1 (en) 2014-01-13 2016-02-23 Amazon Technologies, Inc. Adaptive client-aware session security
CA2936985A1 (en) * 2014-02-04 2015-08-13 Visa International Service Association Token verification using limited use certificates
JP6327881B2 (ja) * 2014-02-24 2018-05-23 キヤノン株式会社 情報処理装置、その制御方法、及びプログラム
US10771255B1 (en) 2014-03-25 2020-09-08 Amazon Technologies, Inc. Authenticated storage operations
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US9258117B1 (en) 2014-06-26 2016-02-09 Amazon Technologies, Inc. Mutual authentication with symmetric secrets and signatures
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
JP6354407B2 (ja) * 2014-07-11 2018-07-11 株式会社リコー 認証システム、認証方法、プログラム及び通信システム
US9450760B2 (en) * 2014-07-31 2016-09-20 Nok Nok Labs, Inc. System and method for authenticating a client to a device
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
JP6561441B2 (ja) * 2014-09-05 2019-08-21 株式会社リコー 情報処理装置、アクセス制御方法、通信システム、及びプログラム
US9444848B2 (en) * 2014-09-19 2016-09-13 Microsoft Technology Licensing, Llc Conditional access to services based on device claims
US10198558B2 (en) * 2014-10-06 2019-02-05 Red Hat, Inc. Data source security cluster
CN105490997B (zh) * 2014-10-10 2019-05-14 阿里巴巴集团控股有限公司 安全校验方法、装置、终端及服务器
US10477260B2 (en) 2014-10-17 2019-11-12 Cox Communications, Inc. Network based digital video recorder playback adapter
US20160142409A1 (en) * 2014-11-18 2016-05-19 Microsoft Technology Licensing, Llc Optimized token-based proxy authentication
US10853592B2 (en) * 2015-02-13 2020-12-01 Yoti Holding Limited Digital identity system
CN107210918B (zh) * 2015-02-17 2021-07-27 维萨国际服务协会 用于使用基于交易特定信息的令牌和密码的交易处理的装置和方法
US9819596B2 (en) * 2015-02-24 2017-11-14 Qualcomm Incorporated Efficient policy enforcement using network tokens for services C-plane approach
US9350556B1 (en) 2015-04-20 2016-05-24 Google Inc. Security model for identification and authentication in encrypted communications using delegate certificate chain bound to third party key
CN104917615B (zh) * 2015-04-24 2018-06-01 广东电网有限责任公司信息中心 一种基于环签名的可信计算平台属性验证方法
US10574750B2 (en) 2015-04-27 2020-02-25 Microsoft Technology Licensing, Llc Aggregation and federation of distributed service entities and associations
US10044718B2 (en) 2015-05-27 2018-08-07 Google Llc Authorization in a distributed system using access control lists and groups
US9736165B2 (en) 2015-05-29 2017-08-15 At&T Intellectual Property I, L.P. Centralized authentication for granting access to online services
US11503031B1 (en) * 2015-05-29 2022-11-15 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US9444822B1 (en) * 2015-05-29 2016-09-13 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US10171447B2 (en) 2015-06-15 2019-01-01 Airwatch Llc Single sign-on for unmanaged mobile devices
US10171448B2 (en) * 2015-06-15 2019-01-01 Airwatch Llc Single sign-on for unmanaged mobile devices
US11057364B2 (en) 2015-06-15 2021-07-06 Airwatch Llc Single sign-on for managed mobile devices
US10944738B2 (en) 2015-06-15 2021-03-09 Airwatch, Llc. Single sign-on for managed mobile devices using kerberos
US10812464B2 (en) 2015-06-15 2020-10-20 Airwatch Llc Single sign-on for managed mobile devices
US10122689B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Load balancing with handshake offload
US10122692B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Handshake offload
WO2017020035A1 (en) * 2015-07-30 2017-02-02 Interdigital Patent Holdings, Inc. Enabling coordinated identity management between an operator-managed mobile-edge platform and an external network
US10270753B2 (en) * 2015-08-14 2019-04-23 Salesforce.Com, Inc. Background authentication refresh
US10542117B2 (en) 2015-09-03 2020-01-21 Verisign, Inc. Systems and methods for providing secure access to shared registration systems
US9800580B2 (en) * 2015-11-16 2017-10-24 Mastercard International Incorporated Systems and methods for authenticating an online user using a secure authorization server
US9971637B1 (en) * 2015-11-19 2018-05-15 Sprint Communications Company L.P. Big data propagation agent framework
US11329821B2 (en) * 2015-12-28 2022-05-10 Verisign, Inc. Shared registration system
US10382424B2 (en) 2016-01-26 2019-08-13 Redhat, Inc. Secret store for OAuth offline tokens
EP3345370B1 (en) 2016-01-29 2019-03-13 Google LLC Device access revocation
US10341862B2 (en) 2016-02-05 2019-07-02 Verizon Patent And Licensing Inc. Authenticating mobile devices
WO2017166166A1 (en) 2016-03-31 2017-10-05 Oracle International Corporation System and method for providing runtime tracing for web-based client accessing transactional middleware platform using extension interface
CN108476216B (zh) * 2016-03-31 2021-01-22 甲骨文国际公司 用于集成事务中间件平台与集中式访问管理器用于在企业级计算环境中的单点登录的系统和方法
CN106023458B (zh) * 2016-05-13 2019-08-13 智车优行科技（北京）有限公司 车辆控制方法、装置、终端、车辆、服务器及系统
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
US10116440B1 (en) 2016-08-09 2018-10-30 Amazon Technologies, Inc. Cryptographic key management for imported cryptographic keys
US20180063152A1 (en) * 2016-08-29 2018-03-01 Matt Erich Device-agnostic user authentication and token provisioning
US10635828B2 (en) * 2016-09-23 2020-04-28 Microsoft Technology Licensing, Llc Tokenized links with granular permissions
US10374809B1 (en) 2016-12-13 2019-08-06 Amazon Technologies, Inc. Digital signature verification for asynchronous responses
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
CN110169031B (zh) 2017-01-09 2023-09-19 开利公司 具有本地移动密钥分配的门禁控制系统
MX2019008606A (es) 2017-01-23 2019-09-27 Carrier Corp Sistema de control de acceso con acceso seguro.
CN111669408A (zh) * 2017-03-30 2020-09-15 阿里巴巴集团控股有限公司 一种身份注册及认证的方法及装置
US10742638B1 (en) * 2017-04-27 2020-08-11 EMC IP Holding Company LLC Stateless principal authentication and authorization in a distributed network
US10630668B2 (en) * 2017-04-28 2020-04-21 Amazon Technologies, Inc. Single sign-on registration
CN110583049B (zh) 2017-05-03 2021-12-21 瑞典爱立信有限公司 Ran中的ue处理
US10972273B2 (en) * 2017-06-14 2021-04-06 Ebay Inc. Securing authorization tokens using client instance specific secrets
WO2019005857A1 (en) * 2017-06-28 2019-01-03 Apple Inc. LAW ENFORCEMENT SYSTEM
DE102017211267A1 (de) * 2017-07-03 2019-01-03 Siemens Aktiengesellschaft Verfahren zum Schützen einer Zertifikatsanforderung eines Clienten-Rechners und entsprechendes Kommunikationssystem
US10721222B2 (en) * 2017-08-17 2020-07-21 Citrix Systems, Inc. Extending single-sign-on to relying parties of federated logon providers
US10505916B2 (en) * 2017-10-19 2019-12-10 T-Mobile Usa, Inc. Authentication token with client key
GB201719080D0 (en) 2017-11-17 2018-01-03 Light Blue Optics Ltd Device authorization systems
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US10587409B2 (en) 2017-11-30 2020-03-10 T-Mobile Usa, Inc. Authorization token including fine grain entitlements
TWI640189B (zh) * 2017-12-25 2018-11-01 中華電信股份有限公司 電信認證之身分核實系統及其方法
CN108174363A (zh) * 2017-12-29 2018-06-15 威马智慧出行科技（上海）有限公司 寻车方法及装置
US11831409B2 (en) * 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US11546310B2 (en) * 2018-01-26 2023-01-03 Sensus Spectrum, Llc Apparatus, methods and articles of manufacture for messaging using message level security
US11438168B2 (en) 2018-04-05 2022-09-06 T-Mobile Usa, Inc. Authentication token request with referred application instance public key
US10812476B2 (en) 2018-05-22 2020-10-20 Salesforce.Com, Inc. Authorization of another device for participation in multi-factor authentication
GB201809225D0 (en) * 2018-06-05 2018-07-25 Data Signals Ltd Method and apparatus for access control
WO2020005948A1 (en) * 2018-06-25 2020-01-02 Jpmorgan Chase Bank, N.A. Systems and methods for using an oauth client secret to encrypt data sent to browser
US11108764B2 (en) 2018-07-02 2021-08-31 Salesforce.Com, Inc. Automating responses to authentication requests using unsupervised computer learning techniques
US10764276B2 (en) 2018-08-31 2020-09-01 Sap Se Certificate-initiated access to services
US11310217B2 (en) * 2018-09-07 2022-04-19 Paypal, Inc. Using ephemeral URL passwords to deter high-volume attacks
US10826909B2 (en) * 2018-10-04 2020-11-03 Servicenow, Inc. Platform-based authentication for external services
CN109088890A (zh) * 2018-10-18 2018-12-25 国网电子商务有限公司 一种身份认证方法、相关装置及系统
WO2020107104A1 (en) * 2018-11-30 2020-06-04 BicDroid Inc. Personalized and cryptographically secure access control in operating systems
CN109672675B (zh) * 2018-12-20 2021-06-25 成都三零瑞通移动通信有限公司 一种基于OAuth2.0的密码服务中间件的WEB认证方法
DE102019100335A1 (de) * 2019-01-08 2020-07-09 Bundesdruckerei Gmbh Verfahren zum sicheren Bereitstellen einer personalisierten elektronischen Identität auf einem Endgerät
US11323275B2 (en) 2019-03-25 2022-05-03 Micron Technology, Inc. Verification of identity using a secret key
US11361660B2 (en) 2019-03-25 2022-06-14 Micron Technology, Inc. Verifying identity of an emergency vehicle during operation
US11233650B2 (en) 2019-03-25 2022-01-25 Micron Technology, Inc. Verifying identity of a vehicle entering a trust zone
US11218330B2 (en) 2019-03-25 2022-01-04 Micron Technology, Inc. Generating an identity for a computing device using a physical unclonable function
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110572258B (zh) * 2019-07-24 2021-12-14 中国科学院数据与通信保护研究教育中心 一种云密码计算平台及计算服务方法
US11882120B2 (en) * 2019-07-30 2024-01-23 Hewlett Packard Enterprise Development Lp Identity intermediary service authorization
US11050560B2 (en) 2019-09-27 2021-06-29 International Business Machines Corporation Secure reusable access tokens
US11652813B2 (en) * 2019-10-04 2023-05-16 Mastercard International Incorporated Systems and methods for real-time identity verification using a token code
US11449636B2 (en) 2019-10-04 2022-09-20 Mastercard International Incorporated Systems and methods for secure provisioning of data using secure tokens
US11121863B1 (en) 2020-03-12 2021-09-14 Oracle International Corporation Browser login sessions via non-extractable asymmetric keys
TWI802794B (zh) * 2020-04-29 2023-05-21 臺灣銀行股份有限公司 金融業務審核之整合系統及其方法
CN111797431B (zh) * 2020-07-07 2023-04-28 电子科技大学 一种基于对称密钥体制的加密数据异常检测方法与系统
CN111770200B (zh) * 2020-08-31 2020-12-08 支付宝(杭州)信息技术有限公司 一种信息共享方法和系统
FI129916B (en) * 2020-12-16 2022-10-31 Nokia Technologies Oy AUTHORIZATION OF ONLINE REQUEST
US11895106B2 (en) 2021-01-28 2024-02-06 Oracle International Corporation Automatic sign-in upon account signup
US11620363B1 (en) 2021-03-15 2023-04-04 SHAYRE, Inc. Systems and methods for authentication and authorization for software license management
US11632362B1 (en) 2021-04-14 2023-04-18 SHAYRE, Inc. Systems and methods for using JWTs for information security
JP7453179B2 (ja) * 2021-04-20 2024-03-19 トヨタ自動車株式会社 認証システム
US11831754B2 (en) * 2021-04-21 2023-11-28 Aetna Inc. Systems and methods for device binding across multiple domains using an authentication domain
US11621830B1 (en) 2021-06-28 2023-04-04 SHAYRE, Inc. Systems and methods for facilitating asynchronous secured point-to-point communications

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300746A1 (en) 2008-05-27 2009-12-03 Open Invention Network Llc System integrating an identity selector and user-portable device and method of use in a user-centric identity management system
US20100251353A1 (en) 2009-03-25 2010-09-30 Novell, Inc. User-authorized information card delegation
WO2011100331A1 (en) * 2010-02-09 2011-08-18 Interdigital Patent Holdings, Inc Method and apparatus for trusted federated identity

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004260716A (ja) * 2003-02-27 2004-09-16 Nippon Telegr & Teleph Corp <Ntt> ネットワークシステム、個人情報送信方法およびプログラム
DE102008000067C5 (de) 2008-01-16 2012-10-25 Bundesdruckerei Gmbh Verfahren zum Lesen von Attributen aus einem ID-Token
US9838877B2 (en) * 2008-04-02 2017-12-05 Yougetitback Limited Systems and methods for dynamically assessing and mitigating risk of an insured entity
US20090271847A1 (en) 2008-04-25 2009-10-29 Nokia Corporation Methods, Apparatuses, and Computer Program Products for Providing a Single Service Sign-On
JP2010244272A (ja) * 2009-04-06 2010-10-28 Nippon Telegr & Teleph Corp <Ntt> 個人属性情報管理方法、個人属性情報管理システムおよび個人属性情報管理プログラム
DE102009027682A1 (de) * 2009-07-14 2011-01-20 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Soft-Tokens
KR101482564B1 (ko) 2009-09-14 2015-01-14 인터디지탈 패튼 홀딩스, 인크 신뢰성있는 인증 및 로그온을 위한 방법 및 장치
US20110173105A1 (en) * 2010-01-08 2011-07-14 Nokia Corporation Utilizing AAA/HLR infrastructure for Web-SSO service charging
EP2540057A2 (en) * 2010-02-26 2013-01-02 General instrument Corporation Dynamic cryptographic subscriber-device identity binding for subscriber mobility
GB2478971A (en) * 2010-03-25 2011-09-28 Nec Corp Generating a user interface on a mobile phone for an application on a UICC using metadata
DE102010028133A1 (de) * 2010-04-22 2011-10-27 Bundesdruckerei Gmbh Verfahren zum Lesen eines Attributs aus einem ID-Token
JP5790653B2 (ja) * 2010-07-09 2015-10-07 日本電気株式会社 サービス提供システム
US8832271B2 (en) * 2010-12-03 2014-09-09 International Business Machines Corporation Identity provider instance discovery
US9497184B2 (en) * 2011-03-28 2016-11-15 International Business Machines Corporation User impersonation/delegation in a token-based authentication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300746A1 (en) 2008-05-27 2009-12-03 Open Invention Network Llc System integrating an identity selector and user-portable device and method of use in a user-centric identity management system
US20100251353A1 (en) 2009-03-25 2010-09-30 Novell, Inc. User-authorized information card delegation
WO2011100331A1 (en) * 2010-02-09 2011-08-18 Interdigital Patent Holdings, Inc Method and apparatus for trusted federated identity

Also Published As

Publication number Publication date
US9774581B2 (en) 2017-09-26
KR101636028B1 (ko) 2016-07-04
EP2805470A1 (en) 2014-11-26
KR20170046191A (ko) 2017-04-28
WO2013109857A1 (en) 2013-07-25
KR20160079153A (ko) 2016-07-05
EP2805470B1 (en) 2018-09-12
CN104115465A (zh) 2014-10-22
JP2015511348A (ja) 2015-04-16
US20130191884A1 (en) 2013-07-25
TW201345217A (zh) 2013-11-01
KR20140114058A (ko) 2014-09-25

Similar Documents

Publication Publication Date Title
KR101730459B1 (ko) 로컬 기능을 갖는 아이덴티티 관리
US8533803B2 (en) Method and apparatus for trusted federated identity
US9490984B2 (en) Method and apparatus for trusted authentication and logon
US9237142B2 (en) Client and server group SSO with local openID
US8509431B2 (en) Identity management on a wireless device
US9467429B2 (en) Identity management with generic bootstrapping architecture
JP5688087B2 (ja) 信頼できる認証およびログオンのための方法および装置
JP2017163573A (ja) 無線ユニットのユーザを認証するための方法およびシステム
US9210145B2 (en) Method and system for hypertext transfer protocol digest authentication
TW201225697A (en) Identity management on a wireless device
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
JP2015111440A (ja) 信頼できる認証およびログオンのための方法および装置
Randhawa Security and Trust

Legal Events

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