KR20140035918A

KR20140035918A - 다수의 sso 기술들에 대한 sso 프레임워크

Info

Publication number: KR20140035918A
Application number: KR1020137031258A
Authority: KR
Inventors: 요겐드라 씨 샤; 안드레아스 슈미트; 인혁 차; 루이스 제이 구치오네; 안드레아스 라이셔
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2011-04-28
Filing date: 2012-04-27
Publication date: 2014-03-24
Also published as: EP2702745B1; JP2017112640A; CN103503407B; CN103503407A; WO2012149384A1; CN107070843A; JP2014519634A; JP2018157604A; TW201731274A; TWI589141B; EP2913976B1; EP2913976A1; US20130125226A1; TW201306539A; EP3297246A1; EP2702745A1

Abstract

사용자는, 크리덴셜(credential)의 프로비저닝(provisioning)에서의 사용자 상호작용이 최소로 유지될 수 있거나 심지어 완전히 제거될 수 있도록, 사용가능한 보안 또는 인터넷 서비스들에 액세스하는 매끄러운 수단을 요망하고 있다. 싱글 사인-온(Single Sign-On, SSO) ID 관리(identity management) 개념은 원하는 서비스에 액세스하기 위한 사용자-보조 및 네트워크-보조 인증을 가능하게 해준다. 사용자에게 매끄러운 인증 서비스를 가능하게 해주기 위해, 다수의 인증 방법들을 관리하는 통합된 프레임워크 및 프로토콜 계층 인터페이스가 사용될 수 있다. 사용자 장비(UE)는 서비스에 액세스하기 위해 서비스 제공자와 통신하도록 구성되는 사용자 애플리케이션(202, 204), 및 복수의 네트워크-보조 인증 모듈들(208 내지 216) ― 각각의 네트워크-보조 인증 모듈은 상이한 네트워크-보조 인증 프로토콜에 대응함 ― 을 포함한다. UE는 UE 및/또는 네트워크에서의 사용자-보조 인증 정보에 기초하여 UE의 사용자를 인증하고 하나 이상의 정책들에 기초하여 네트워크-보조 인증 모듈들 중 하나를 선택하도록 구성되는 SSO(single sign-on) 서브시스템(206)을 추가로 포함한다.

Description

다수의 SSO 기술들에 대한 SSO 프레임워크{SSO FRAMEWORK FOR MULTIPLE SSO TECHNOLOGIES}

관련 출원의 상호 참조

이 출원은 2011년 4월 28일자로 출원된 미국 가특허 출원 제61/480,137호 및 2011년 10월 17일자로 출원된 미국 가특허 출원 제61/548,156호를 기초로 우선권을 주장하며, 이들 미국 출원은 참조 문헌으로서 그 전체 내용이 본 명세서에 포함된다.

인터넷 서비스에 대한 스마트 폰 액세스의 사용의 증가로 인해, 모바일 사용자 보안 요구사항이 증가하고 있다. 예를 들어, 뱅킹 서비스, 공연(entertainment event)에 대한 티켓 발급 서비스 등은 무결성, 기밀성 보호, 및 사용자 인증을 필요로 할 수 있다. 이러한 요구사항은 사용자 이름, 핀(pin) 및 비밀 번호의 형태로 사용자에게 직접 인증의 부담을 지울 수 있다. 그렇지만, 각각에 대한 개별적인 사용자-제공 크리덴셜(credential)을 갖는 수많은 계정을 소유하는 것은, 예를 들어, 사용자에 대한 크리덴셜 피로(fatigue)의 관점에서 어쩌면 과도한 인증 부담을 지울 수 있다. 기억하기 쉬운 크리덴셜을 사용하는 것에 의해 또는 2개 이상의 도메인에 걸쳐 동일한 크리덴셜을 재사용함하는 것에 의해, 사용자가 프로세스를 단순화하려고 시도하는 경우, 사용자는 보안 취약성을 야기할 수 있다.

이 요약은 이하에서 상세한 설명에 추가로 기술되어 있는 다양한 개념들을 간략화된 형태로 소개하기 위해 제공된다. 이 요약은 청구된 발명 요지의 주요 특징 또는 필수적인 특징을 확인하기 위한 것도 아니고, 청구된 발명 요지의 범위를 제한하기 위해 사용되기 위한 것도 아니다.

통합된 사용자 인터페이스 및 상이한 인증 프로토콜에 대한 프로토콜 계층 인터페이스를 통해 모바일 사용자에 대한 다수의 인증 방법을 관리하는 통합된 프레임워크가 본 명세서에 개시되어 있다. 통합된 프레임워크 및 프로토콜 계층 둘 다는 최종 사용자에 대한 매끄러운 인증 서비스를 가능하게 해줄 수 있다. 그에 부가하여, 다수의 서비스 제공자를 지원하는 다수의 액세스 도메인을 수반하는 일 실시예가 또한 개시되어 있다.

본 명세서에 기술되어 있는 실시예들은 사용자에게 유연하고 및/또는 매끄러운 경험을 가능하게 해줄 수 있는 전체적인 싱글 사인온(single sign-on, SSO) 아키텍처를 제공할 수 있다. 사용자 인증 인터페이스(user authentication interface)는 사용자/애플리케이션 엔티티(예컨대, 브라우저 또는 넌-브라우저 애플리케이션)와 SSO 서브시스템 사이의 경계로서 역할할 수 있다. 한 예시적인 실시예에서, SSO 서브시스템은 모바일 네트워크 통신 사업자(Mobile Network Operator, MNO)에 의해 제어될 수 있다. SSO 서브시스템은, 예를 들어, 생체 인식, 비밀 번호, PIN, 및/또는 기타 사용자 크리덴셜 입력 등의 각종의 다중-인자 크리덴셜 입력을 지원할 수 있다. 사용자 인증 인터페이스는 또한 다양한 인증 강도 레벨(authentication strength level)을 제공할 수 있다. 네트워크 인증 인터페이스(network authentication interface)는 SSO 서브시스템과 단일의 구조적 프레임워크(structural framework) 내의 몇개의 SSO 메커니즘을 수용하는 것을 가능하게 해줄 수 있는 다수의 네트워크-보조 인증 기술들 또는 프로토콜 모듈들 사이의 경계로서 역할할 수 있다. 기능 구조(functional structure)는, 예를 들어, OpenID 지원 사이트(OpenID relying party) 등의 서비스 제공자에 대해 인증을 받으면서, 네트워크-보조 인증(network-assisted authentication)(예컨대, SSO 네트워크-보조 인증)으로부터 사용자-보조 인증(user-assisted authentication)을 분리하는 것을 제공할 수 있다.

한 예시적인 실시예에서, 사용자 장비(UE)는 서비스에 액세스하기 위해 서비스 제공자와 통신하도록 구성되는 사용자 애플리케이션을 포함할 수 있다. UE는 복수의 네트워크-보조 인증 모듈들을 추가로 포함할 수 있다. 각각의 네트워크-보조 인증 모듈은 상이한 네트워크-보조 인증 프로토콜에 대응할 수 있다. 예를 들어, 네트워크-보조 인증 모듈들은 서비스에 액세스하기 위해 서비스 제공자에 대해 네트워크-보조 인증을 수행하도록 구성되어 있을 수 있다. UE는 UE 및/또는 네트워크에서의 사용자-보조 인증 정보에 기초하여 UE의 사용자를 인증하도록 구성되는 SSO(single sign-on) 서브시스템을 추가로 포함할 수 있다. SSO 서브시스템은 또한 서비스 제공자에 대해 네트워크-보조 인증을 수행하기 위한 복수의 네트워크-보조 인증 모듈들 중의 한 네트워크-보조 인증 모듈을 선택하는 동작을 할 수 있다. SSO 서브시스템은 또한, 하나 이상의 정책들에 기초하여, 사용자-보조 인증을 수행하고 네트워크-보조 인증 모듈을 선택하도록 구성되어 있을 수 있다. 다른 예시적인 실시예에서, UE는 서비스 제공자의 하나 이상의 데이터 필드들을 검출할 수 있다. 데이터 필드들을 검출한 것에 응답하여, UE의 인증 요청자(supplicant)는 데이터 필드를 대응하는 인증 데이터로 자동으로 채울 수 있다.

본 명세서에 기술된 시스템, 방법 및 수단의 다른 특징들이 이하의 상세한 설명 및 첨부 도면들에 제공되어 있다.

도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템의 시스템도.
도 1b는 도 1a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 WTRU(wireless transmit/receive unit)의 시스템도.
도 1c는 도 1a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 무선 액세스 네트워크 및 예시적인 코어 네트워크의 시스템도.
도 2는 다수의 SSO 기술을 사용하기 위한 아키텍처 프레임워크의 한 예시적인 실시예를 나타낸 도면.
도 3a 및 도 3b는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 예시적인 실시예를 나타낸 도면.
도 4는 다수의 SSO 기술을 사용하기 위한 아키텍처 프레임워크의 다른 예시적인 실시예를 나타낸 도면.
도 5는 한 예시적인 실시예에 따른 GBA 연동(GBA interworking)을 사용하는 예시적인 SSO 서브시스템의 블록도.
도 6은 다수의 SSO 프로토콜의 사용을 용이하게 해주는 다운로드가능 구성요소를 포함하는 아키텍처 프레임워크의 한 예시적인 실시예를 나타낸 도면.
도 7은 인터페이스 구성요소들을 갖는 SSO 시스템의 한 예시적인 실시예의 블록도.
도 8은 인증 요청자를 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 9는 LAE(local assertion entity, 로컬 어써션 엔티티)를 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 10은 통합된 OP(integrated OP)를 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 11은 프리페칭(pre-fetching)을 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 12는 서비스 제공자에 저장되어 있는 자바 애플릿을 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 13은 캐싱된 자바 애플릿을 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 14는 실시간 프로비저닝(on-the-fly provisioning)을 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.
도 15는 통합된 툴킷(integrated toolkit)을 갖는 SSO 프레임워크 아키텍처에 대한 프로토콜 흐름의 한 예시적인 실시예를 나타낸 도면.

예를 들어, 모바일 사용자 등의 사용자는, 크리덴셜의 프로비저닝에서의 사용자 상호작용이 최소화되거나 심지어 완전히 제거될 수 있도록, 사용가능한 보안 및/또는 인터넷 서비스들에 액세스하는 매끄러운 수단을 요망할 수 있다. 한 예시적인 실시예에서, SSO(Single Sign-On) IdM(identity management, ID 관리)은, 원하는 서비스들에 액세스하기 위한 사용자-보조 및 네트워크-보조 인증을 가능하게 해주면서, 다양한 특성들을 갖는 SSO 구현들을 제공하는 수단 ― 그에 의해 사용자는 이러한 사용 편의성을 제공받을 수 있음 ― 을 포함할 수 있다. 사용자-보조 인증은 사용자로부터의 입력이 사용되는 인증을 말하는 것일 수 있다. 이러한 사용자 입력은 반자동화되어 있거나(예컨대, 브라우저에 저장되어 있음) 사용자에 의해 입력될 수 있다. 예를 들어, 사용자-보조 인증은 사용자가 알고 있는 파라미터(예컨대, 사용자 이름, 비밀 번호) 및/또는 사용자의 특성[예컨대, 동적 서명(dynamic signature), 홍채 인식(iris scan), 지문, 또는 기타 생체 측정(biometric measurement)]에 기초할 수 있다. 네트워크-보조 인증은 사용자가 소유하고 있을 수 있는 엔티티(예컨대, 암호 키 및 프로토콜을 포함하는 UICC)에 기초할 수 있는 사용자 인증을 말하는 것일 수 있다. 예를 들어, 네트워크-보조 인증은 네트워크 액세스를 위해 네트워크 통신사업자에 의해 제공될 수 있는 기능들[예컨대, GBA(Generic Bootstrapping Architecture) 프로토콜]의 재사용에 의한 사용자의 SSO 인증을 말하는 것일 수 있다. 예를 들어, GBA는 셀룰러 네트워크 및/또는 IMS에의 액세스를 제공할 수 있는 (예컨대, UICC에 있는) 비밀 키 및 프로토콜의 재사용에 기초하여 SSO 인증을 발생할 수 있다. 각각의 사용자-보조 인증 입력 및 네트워크-보조 인증 입력은 인증 인자(authentication factor)라고 할 수 있다. SSO 구현들의 다양한 특성들은, 예를 들어, 매끄러운 인증 인자들을 갖는 SSO, 단일의 크리덴셜 세트를 갖는 SSO, 및 완전 SSO(full SSO)를 포함할 수 있다. 매끄러운 인증 인자들을 갖는 SSO는 성공적인 사용자-보조 인증 후에 자동으로(예컨대, 사용자 상호작용 없이) 진행되는 네트워크-보조 사용자 인증(network-assisted user authentication)을 말하는 것일 수 있다. 단일의 크리덴셜 세트를 갖는 SSO는 사용자가 다수의 서비스 제공자들에 대해 인증하기 위해 (예컨대, 사용자-보조 인증을 위한) 단일의 크리덴셜 세트를 사용할 수 있는 구현을 말하는 것일 수 있다. 한 예시적인 실시예에서, 사용자가 상이한 서비스 제공자에 액세스할 때마다 단일의 크리덴셜 세트가 제공될 수 있다. 완전 SSO 구현을 사용하는 한 예시적인 실시예에서, 사용자가 서비스 제공자에 액세스하기 위해 인증될 수 있고, 이어서, 또 다시 인증하라고 요청받는 일 없이, 다른 서비스 제공자들에 액세스할 수 있다. 예를 들어, 완전 SSO 구현은 매끄러운 인증 인자들을 갖는 SSO를 포함할 수 있다.

통합된 사용자 인터페이스 및 상이한 인증 프로토콜에 대한 프로토콜 계층 인터페이스를 통해 모바일 사용자에 대한 하나 이상의 인증 방법을 관리하는 통합된 프레임워크가 본 명세서에 개시되어 있다. 통합된 프레임워크 및 프로토콜 계층 둘 다는 최종 사용자에 대한 매끄러운 인증 서비스를 가능하게 해줄 수 있다. 그에 부가하여, 다수의 서비스 제공자를 지원하는 다수의 액세스 도메인을 수반하는 일 실시예가 또한 기술되어 있다.

본 명세서에 기술되어 있는 실시예들은 사용자에게 유연하고 및/또는 매끄러운 경험을 가능하게 해줄 수 있는 전체적인 SSO 아키텍처를 제공할 수 있다. 사용자 인증 인터페이스는 사용자/애플리케이션 엔티티(예컨대, 브라우저 또는 넌-브라우저 애플리케이션)와 SSO 서브시스템 사이의 경계로서 역할할 수 있다. 한 예시적인 실시예에서, SSO 서브시스템은 MNO(Mobile Network Operator)에 의해 제어될 수 있다. SSO 서브시스템은, 예를 들어, 생체 인식, 비밀 번호, PIN, 및/또는 기타 사용자 크리덴셜 입력 등의 각종의 다중-인자 크리덴셜 입력을 지원할 수 있다. 사용자 인증 인터페이스는 또한 다양한 인증 강도 레벨을 제공할 수 있다. 네트워크 인증 인터페이스는 SSO 서브시스템과 단일의 구조적 프레임워크 내의 몇개의 SSO 메커니즘을 수용하는 것을 가능하게 해줄 수 있는 다수의 네트워크-보조 인증 기술들 또는 프로토콜 모듈들 사이의 경계로서 역할할 수 있다. 기능 구조는 사용자-보조 인증을 네트워크-보조 인증(예컨대, SSO 네트워크-보조 인증)으로부터 분리시키는 것을 제공할 수 있다.

SSO 서브시스템은 사용자 크리덴셜에 대한 저장 및/또는 처리를 제공할 수 있고, 여기서 이러한 저장 장치는 신뢰된 컴퓨팅 환경(예컨대, UICC, 스마트 카드, 또는 기타 신뢰된 보안 환경) 상에 있거나 그로부터 벗어나 있을 수 있고, 다수의 보안 레벨들을 제공할 수 있다. 신뢰된 컴퓨팅 환경 상에 포함되어 있는 저장 장치는 사용자 크리덴셜의 재사용을 지원할 수 있다. SSO 서브시스템은 시행할 보안 레벨을 결정하고 사용할 SSO 프로토콜을 결정할 시에 외부 이해관계자(예컨대, MNO)의 기능들 및/또는 정책들을 수행하는 데 프록시로서 역할할 수 있다. 구현 관점에서 보아, 신뢰된 보안 환경(예컨대, UICC, 스마트 카드, 또는 기타 신뢰된 보안 환경) 상에 또는 그로부터 벗어나 위치해 있을 임의의 SSO 기능의 구분이 없을 수 있다.

예시적인 구현은 개별적인 격리된 SSO 클라이언트를 제공할 수 있다. 한 예시적인 실시예에서, 각각의 SSO 클라이언트는 다수의 이용가능한 연결 프로토콜들 및/또는 동일한 제공자에 의해 동시에 제공되는 서비스들의 정책-기반 관리를 가능하게 해줄 수 있는 방식으로 상이한 서비스 제공자에 서비스할 수 있다.

다른 예시적인 구현은 다수의 LAE(Local Assertion Entity)를 가능하게 해줄 수 있다. LAE는 UE 상에 위치해 있는 기능 엔티티를 말하는 것일 수 있다. 예를 들어, LAE는 사용자 ID 및/또는 인증에 관한 신뢰된 어써션(trusted assertion)을 원격 엔티티에 제공할 수 있다. 한 예시적인 실시예에서, 로컬 OP(local OP)는 RP에 OpenID 어써션을 제공하는 LAE의 인스턴스화를 말하는 것일 수 있다. 각각의 LAE는 UICC 상의 액세스 기술 관련 도메인(access-technology-specific domain)에서 구현될 수 있고, 각각은 하나의 격리된 도메인에 전용되어 있을 수 있다. 동일한 액세스 기술이 상이한 LAE들 간에 다중화될 수 있거나, 상이한 액세스 기술들이 LAE들에 의해 동시에 사용될 수 있다. 구현에 따라, LAE와 SSO 클라이언트 간의 관계는 일대일일 수 있거나, 하나의 SSO 클라이언트가 다수의 LAE를 제어하거나 그에 의해 서비스될 수 있다.

본 명세서에 기술되어 있는 실시예들은 무선 디바이스에서의 인증 프로토콜의 실행을 용이하게 해줄 수 있다. 예를 들어, 무선 디바이스 및 네트워크 엔티티 ― 예를 들어, RP(relying party) 또는 OP(OpenID Identity Provider Server) 등 ― 에 대한 OpenID 인증 프로세스의 실행을 용이하게 해주기 위해 인증 요청자가 사용될 수 있다. 예시적인 실시예에 따르면, 인증 요청자는 자바 애플릿으로서 구현될 수 있다. 인증 요청자는 OpenID 인증 등의 인증 방식을 위해 사용될 네트워크-보조 인증 메커니즘 ― 이는 넌-브라우저 애플리케이션 또는 브라우저 애플리케이션에 의해 기본적으로 지원되지 않을 수 있음 ― 을 가능하게 해줄 수 있다. 예를 들어, 인증 요청자는 SSO(single sign-on) 서브시스템과 인터페이스할 수 있고, SSO 서브시스템은 차례로 GBA, AKA, SIP Digest, 및 EAP-SIM 등의 네트워크-보조 인증 프로토콜과 인터페이스할 수 있다. 예를 들어, 스마트 폰 플랫폼 등의 모바일 디바이스 상에서 이용가능한 광범위한 플랫폼 프로세서 아키텍처, 운영 체제, 및 소프트웨어가 주어진 경우, 인증 요청자는 SSO 인증 기능을 수행할 수 있는 네트워크 인증 인터페이스를 SSO 서브시스템에 제공할 수 있다. 예를 들어, 인증 요청자는 애플리케이션 및/또는 브라우저가, 네트워크 및/또는 액세스 계층 인증 모듈(예컨대, GBA 모듈, UICC)과 연동하는 동안, 자동화된 및/또는 매끄러운 인증을 용이하게 할 수 있게 해줄 수 있다. 예를 들어, RP 및/또는 OP로부터 인증 요청자 단편들(supplicant pieces)을 다운로드함으로써, 인증 요청자는 OpenID 인증 프로토콜 동안 매끄럽게 디바이스 관련 소프트웨어를 제공할 수 있다.

본 명세서에 기술되어 있는 실시예들은 OpenID 등의 연합된 인증 프로토콜들(federated authentication protocols)을 사용하여 동작할 수 있고, 또한, 예를 들어, LAE를 사용하여 동작할 수 있다. 예를 들어, OpenID는 네트워크-보조 인증에 바인딩되어 있을 수 있다. 본 명세서에 기술되어 있는 실시예들은 브라우저 및/또는 넌-브라우저 애플리케이션이 액세스 계층(예컨대, UICC/비UICC) 네트워크-보조 인증 메커니즘과 어떻게 통신하는지를 결정하는 데 사용될 수 있다. 예를 들어, 인증 요청자 및 SSO 서브시스템은 브라우저 및/또는 넌-브라우저 애플리케이션 그리고 네트워크-보조 인증 메커니즘에 자동화 및/또는 매끄러운 동작을 제공할 수 있다. 인증 요청자는 통합된 인터페이스를 SSO 서브시스템에 제공할 수 있고, 다양한 인증 프로토콜들(예컨대, GBA, AKA, EAP-SIM)에 대해 사용자를 위해 자동화된 및/또는 매끄러운 인증을 수행할 수 있다. 예를 들어, 서명된 자바 애플릿 등의 다운로드가능 애플리케이션 또는 구성요소가 (예컨대, RP 및/또는 OP로부터) 다운로드될 수 있고, 상이한 비애플리케이션 계층 및/또는 액세스 계층 인증 프로토콜을 사용하여 동작할 수 있다. 이 구성요소는 SSO 서브시스템에 대해 그리고 브라우저/애플리케이션에 대해 균일한 방식으로 인터페이스할 수 있다.

도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템(100)의 도면이다. 통신 시스템(100)은 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 접속 시스템일 수 있다. 통신 시스템(100)은 다수의 무선 사용자가 시스템 자원(무선 대역폭을 포함함)의 공유를 통해 이러한 콘텐츠에 액세스할 수 있게 해줄 수 있다. 예를 들어, 통신 시스템(100)은 CDMA(code division multiple access, 코드 분할 다중 접속), TDMA(time division multiple access, 시분할 다중 접속), FDMA(frequency division multiple access, 주파수 분할 다중 접속), OFDMA(orthogonal FDMA, 직교 FDMA), SC-FDMA(single-carrier FDMA, 단일 반송파 FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다.

도 1a에 도시된 바와 같이, 통신 시스템(100)은 WTRU(wireless transmit/receive unit, 무선 송수신 유닛)(102a, 102b, 102c, 102d), RAN(radio access network, 무선 액세스 네트워크)(104), 코어 네트워크(106), PSTN(public switched telephone network, 공중 교환 전화망)(108), 인터넷(110), 및 기타 네트워크(112)를 포함할 수 있지만, 개시된 실시예가 임의의 수의 WTRU, 기지국, 네트워크 및/또는 네트워크 요소를 생각하고 있다는 것을 잘 알 것이다. WTRU(102a, 102b, 102c, 102d) 각각은 무선 환경에서 동작하고 및/또는 통신하도록 구성되는 임의의 유형의 디바이스일 수 있다. 일례로서, WTRU(102a, 102b, 102c, 102d)는 무선 신호를 송신 및/또는 수신하도록 구성될 수 있고, UE(user equipment), 이동국, 고정형 또는 이동형 가입자 유닛, 페이저, 휴대폰, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 가전 제품 등을 포함할 수 있다.

통신 시스템(100)은 또한 기지국(114a) 및 기지국(114b)을 포함할 수 있다. 기지국(114a, 114b) 각각은 하나 이상의 통신 네트워크 ― 코어 네트워크(106), 인터넷(110) 및/또는 네트워크(112) 등 ― 에 대한 액세스를 용이하게 해주기 위해 WTRU(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이스하도록 구성되는 임의의 유형의 디바이스일 수 있다. 일례로서, 기지국(114a, 114b)은 BTS(base transceiver station, 기지국 송수신기), 노드-B, eNode B, 홈 노드 B, 사이트 제어기, AP(access point), 무선 라우터 등일 수 있다. 기지국(114a, 114b) 각각이 단일 요소로서 나타내어져 있지만, 기지국(114a, 114b)이 임의의 수의 상호연결된 기지국 및/또는 네트워크 요소를 포함할 수 있다는 것을 잘 알 것이다.

기지국(114a)은 다른 기지국 및/또는 네트워크 요소 ― BSC(base station controller, 기지국 제어기), RNC(radio network controller, 무선 네트워크 제어기), 중계 노드, 기타 등등 ― (도시 생략)도 포함할 수 있는 RAN(104)의 일부일 수 있다. 기지국(114a) 및/또는 기지국(114b)은 특정의 지리적 지역 ― 셀(도시 생략)이라고 할 수 있음 ― 내에서 무선 신호를 송신 및/또는 수신하도록 구성될 수 있다. 셀은 여러 셀 섹터(cell sector)로 추가로 나누어질 수 있다. 예를 들어, 기지국(114a)과 연관된 셀이 3개의 섹터로 나누어질 수 있다. 따라서, 일 실시예에서 기지국(114a)은 3개의 송수신기(즉, 셀의 각각의 섹터마다 하나씩)를 포함할 수 있다. 다른 실시예에서, 기지국(114a)은 MIMO(multiple-input multiple output, 다중 입력 다중 출력) 기술을 이용할 수 있고, 따라서, 셀의 각각의 섹터에 대해 다수의 송수신기를 이용할 수 있다.

기지국(114a, 114b)은 임의의 적당한 무선 통신 링크[예컨대, RF(radio frequency, 무선 주파수), 마이크로파, IR(infrared, 적외선), UV(ultraviolet, 자외선), 가시광 등]일 수 있는 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 임의의 적당한 RAT(radio access technology, 무선 액세스 기술)를 사용하여 공중 인터페이스(116)가 설정될 수 있다.

보다 구체적으로는, 앞서 살펴본 바와 같이, 통신 시스템(100)은 다중 접속 시스템일 수 있고, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 접속 방식을 이용할 수 있다. 예를 들어, RAN(104) 내의 기지국(114a) 및 WTRU(102a, 102b, 102c)는 WCDMA(wideband CDMA, 광대역 CDMA)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 UTRA[UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access]와 같은 무선 기술을 구현할 수 있다. WCDMA는 HSPA(High-Speed Packet Access, 고속 패킷 액세스) 및/또는 HSPA+(Evolved HSPA)와 같은 통신 프로토콜을 포함할 수 있다. HSPA는 HSDPA(High-Speed Downlink Packet Access, 고속 하향링크 패킷 액세스) 및/또는 HSUPA(High-Speed Uplink Packet Access, 고속 상향링크 패킷 액세스)를 포함할 수 있다.

다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.

다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 IEEE 802.16[즉, WiMAX(Worldwide Interoperability for Microwave Access)], CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000(Interim Standard 2000), IS-95(Interim Standard 95), IS-856(Interim Standard 856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GSM EDGE(GERAN) 등과 같은 무선 기술을 구현할 수 있다.

도 1a의 기지국(114b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 또는 액세스 포인트일 수 있고, 사업장, 가정, 차량, 캠퍼스 등과 같은 국소화된 지역에서의 무선 연결을 용이하게 해주는 임의의 적당한 RAT를 이용할 수 있다. 일 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WLAN(wireless local area network, 무선 근거리 통신망)을 설정하기 위해 IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WPAN(wireless personal area network, 무선 개인 영역 네트워크)을 설정하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 피코셀(picocell) 또는 펨토셀(femtocell)을 설정하기 위해 셀룰러-기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수 있다. 도 1a에 도시된 바와 같이, 기지국(114b)은 인터넷(110)에의 직접 연결을 가질 수 있다. 따라서, 기지국(114b)은 코어 네트워크(106)를 통해 인터넷(110)에 액세스할 필요가 없을 수 있다.

RAN(104)은 음성, 데이터, 애플리케이션, 및 VoIP(voice over internet protocol) 서비스를 WTRU(102a, 102b, 102c, 102d) 중 하나 이상의 WTRU에 제공하도록 구성되는 임의의 유형의 네트워크일 수 있는 코어 네트워크(106)와 통신하고 있을 수 있다. 예를 들어, 코어 네트워크(106)는 호출 제어, 대금 청구 서비스, 모바일 위치-기반 서비스, 선불 전화(pre-paid calling), 인터넷 연결, 비디오 배포 등을 제공하고 및/또는 사용자 인증과 같은 고레벨 보안 기능을 수행할 수 있다. 도 1a에 도시되어 있지는 않지만, RAN(104) 및/또는 코어 네트워크(106)가 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용하는 다른 RAN과 직접 또는 간접 통신을 하고 있을 수 있다는 것을 잘 알 것이다. 예를 들어, E-UTRA 무선 기술을 이용하고 있을 수 있는 RAN(104)에 연결되는 것에 부가하여, 코어 네트워크(106)는 또한 GSM 무선 기술을 이용하는 다른 RAN(도시 생략)과 통신하고 있을 수 있다.

코어 네트워크(106)는 또한 WTRU(102a, 102b, 102c, 102d)가 PSTN(108), 인터넷(110) 및/또는 기타 네트워크(112)에 액세스하기 위한 게이트웨이로서 역할할 수 있다. PSTN(108)은 POTS(plain old telephone service)를 제공하는 회선-교환 전화 네트워크를 포함할 수 있다. 인터넷(110)은 TCP/IP 인터넷 프로토콜군 내의 TCP(transmission control protocol, 송신 제어 프로토콜), UDP(user datagram protocol, 사용자 데이터그램 프로토콜) 및 IP(internet protocol, 인터넷 프로토콜)와 같은 공통의 통신 프로토콜을 사용하는 상호연결된 컴퓨터 네트워크 및 디바이스의 전세계 시스템을 포함할 수 있다. 네트워크(112)는 다른 서비스 공급자가 소유하고 및/또는 운영하는 유선 또는 무선 통신 네트워크를 포함할 수 있다. 예를 들어, 네트워크(112)는 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용할 수 있는 하나 이상의 RAN에 연결된 다른 코어 네트워크를 포함할 수 있다.

통신 시스템(100) 내의 WTRU(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중-모드 기능을 포함할 수 있다 ― 즉, WTRU(102a, 102b, 102c, 102d)가 상이한 무선 링크를 통해 상이한 무선 네트워크와 통신하기 위한 다수의 송수신기를 포함할 수 있다 -. 예를 들어, 도 1a에 도시된 WTRU(102c)는 셀룰러-기반 무선 기술을 이용할 수 있는 기지국(114a)과 통신하도록, 그리고 IEEE 802 무선 기술을 이용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.

도 1b는 예시적인 WTRU(102)의 시스템도이다. 도 1b에 도시된 바와 같이, WTRU(102)는 프로세서(118), 송수신기(120), 전송/수신 요소(122), 스피커/마이크(124), 키패드(126), 디스플레이/터치패드(128), 비이동식 메모리(130), 이동식 메모리(132), 전원 공급 장치(134), GPS(global positioning system) 칩셋(136), 및 기타 주변 장치(138)를 포함할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 상기한 요소들의 임의의 서브컴비네이션을 포함할 수 있다는 것을 잘 알 것이다.

프로세서(118)가 범용 프로세서, 전용 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Array) 회로, 임의의 다른 유형의 IC(integrated circuit), 상태 기계 등일 수 있다. 프로세서(118)는 WTRU(102)가 무선 환경에서 동작할 수 있게 해주는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 임의의 다른 기능을 수행할 수 있다. 프로세서(118)는 전송/수신 요소(122)에 결합되어 있을 수 있는 송수신기(120)에 결합될 수 있다. 도 1b가 프로세서(118) 및 송수신기(120)를 개별 구성요소로서 나타내고 있지만, 프로세서(118) 및 송수신기(120)가 전자 패키지 또는 칩에 함께 통합되어 있을 수 있다는 것을 잘 알 것이다.

전송/수신 요소(122)는 공중 인터페이스(116)를 통해 기지국[예컨대, 기지국(114a)]으로 신호를 송신하거나 기지국으로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 전송/수신 요소(122)는 RF 신호를 송신 및/또는 수신하도록 구성된 안테나일 수 있다. 다른 실시예에서, 전송/수신 요소(122)는, 예를 들어, IR, UV 또는 가시광 신호를 송신 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 전송/수신 요소(122)는 RF 신호 및 광 신호 둘 다를 송신 및 수신하도록 구성될 수 있다. 전송/수신 요소(122)가 무선 신호의 임의의 조합을 송신 및/또는 수신하도록 구성될 수 있다는 것을 잘 알 것이다.

그에 부가하여, 전송/수신 요소(122)가 도 1b에 단일 요소로서 나타내어져 있지만, WTRU(102)는 임의의 수의 전송/수신 요소(122)를 포함할 수 있다. 보다 구체적으로는, WTRU(102)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, WTRU(102)는 공중 인터페이스(116)를 통해 무선 신호를 송신 및 수신하기 위한 2개 이상의 전송/수신 요소(122)(예컨대, 다수의 안테나)를 포함할 수 있다.

송수신기(120)는 전송/수신 요소(122)에 의해 송신되어야 하는 신호를 변조하고 전송/수신 요소(122)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, WTRU(102)는 다중-모드 기능을 가질 수 있다. 따라서, 송수신기(120)는 WTRU(102)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신할 수 있게 해주는 다수의 송수신기를 포함할 수 있다.

WTRU(102)의 프로세서(118)는 스피커/마이크(124), 키패드(126), 및/또는 디스플레이/터치패드(128)[예컨대, LCD(liquid crystal display, 액정 디스플레이) 디스플레이 유닛 또는 OLED(organic light-emitting diode, 유기 발광 다이오드) 디스플레이 유닛]에 결합될 수 있고 그로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(118)는 또한 사용자 데이터를 스피커/마이크(124), 키패드(126) 및/또는 디스플레이/터치패드(128)로 출력할 수 있다. 그에 부가하여, 프로세서(118)는 비이동식 메모리(130) 및/또는 이동식 메모리(132)와 같은 임의의 유형의 적당한 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(130)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 임의의 다른 유형의 메모리 저장 장치를 포함할 수 있다. 이동식 메모리(132)는 SIM(subscriber identity module, 가입자 식별 모듈) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(118)는 WTRU(102) 상에 물리적으로 위치하지 않은[예컨대, 서버 또는 가정용 컴퓨터(도시 생략) 상의] 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다.

프로세서(118)는 전원 공급 장치(134)로부터 전력을 받을 수 있고, WTRU(102) 내의 다른 구성요소로 전력을 분배하고 및/또는 전력을 제어하도록 구성될 수 있다. 전원 공급 장치(134)는 WTRU(102)에 전원을 제공하는 임의의 적당한 디바이스일 수 있다. 예를 들어, 전원 공급 장치(134)는 하나 이상의 건전지[예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 수소화금속(NiMH), 리튬-이온(Li-ion) 등], 태양 전지, 연료 전지 등을 포함할 수 있다.

프로세서(118)는 또한 WTRU(102)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수 있는 GPS 칩셋(136)에 결합될 수 있다. GPS 칩셋(136)으로부터의 정보에 부가하여 또는 그 대신에, WTRU(102)는 기지국[예컨대, 기지국(114a, 114b)] 공중 인터페이스(116)를 통해 위치 정보를 수신하고 및/또는 2개 이상의 근방의 기지국으로부터 수신되는 신호의 타이밍에 기초하여 그의 위치를 결정할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 임의의 적당한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.

프로세서(118)는 또한 부가의 특징, 기능 및/또는 유선 또는 무선 연결을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변 장치(138)에 결합될 수 있다. 예를 들어, 주변 장치(138)는 가속도계, 전자 나침반, 위성 송수신기, 디지털 카메라(사진 또는 비디오용), USB(universal serial bus) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated, 주파수 변조) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 1c는 일 실시예에 따른, RAN(104) 및 코어 네트워크(106)의 시스템도이다. 앞서 살펴본 바와 같이, RAN(104)은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위해 E-UTRA 무선 기술을 이용할 수 있다. RAN(104)은 또한 코어 네트워크(106)와 통신하고 있을 수 있다.

RAN(104)은 eNode B(140a, 140b, 140c)를 포함할 수 있지만, 실시예와 부합한 채로 있으면서 RAN(104)이 임의의 수의 eNode B를 포함할 수 있다는 것을 잘 알 것이다. eNode B(140a, 140b, 140c) 각각은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, eNode B(140a, 140b, 140c)는 MIMO 기술을 구현할 수 있다. 따라서, 예를 들어, eNode B(140a)는 WTRU(102a)로 무선 신호를 송신하고 그로부터 무선 신호를 수신하기 위해 다수의 안테나를 사용할 수 있다.

eNode B(140a, 140b, 140c) 각각은 특정의 셀(도시 생략)과 연관되어 있을 수 있고, 무선 자원 관리 결정, 핸드오버 결정, 상향링크 및/또는 하향링크에서의 사용자의 스케줄링 등을 처리하도록 구성되어 있을 수 있다. 도 1c에 도시된 바와 같이, eNode B(140a, 140b, 140c)는 X2 인터페이스를 통해 서로 통신할 수 있다.

도 1c에 도시된 코어 네트워크(106)는 MME(mobility management gateway, 이동성 관리 게이트웨이)(142), SGW(serving gateway, 서비스 제공 게이트웨이)(144), 및 PDN(packet data network, 패킷 데이터 네트워크) 게이트웨이(146)를 포함할 수 있다. 상기 요소들 각각이 코어 네트워크(106)의 일부로서 나타내어져 있지만, 이들 요소 중 임의의 것이 코어 네트워크 운영자 이외의 엔티티에 의해 소유되고 및/또는 운영될 수 있다는 것을 잘 알 것이다.

MME(142)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B(142a, 142b, 142c) 각각에 연결되어 있을 수 있고, 제어 노드로서 역할할 수 있다. 예를 들어, MME(142)는 WTRU(102a, 102b, 102c)의 사용자를 인증하는 것, 베어러 활성화/비활성화, WTRU(102a, 102b, 102c)의 초기 접속(initial attach) 동안 특정의 SGW(serving gateway)를 선택하는 것 등을 책임지고 있을 수 있다. MME(142)는 또한 RAN(104)과 GSM 또는 WCDMA와 같은 다른 무선 기술을 이용하는다른 RAN(도시 생략) 간에 전환하는 제어 평면 기능(control plane function)을 제공할 수 있다.

SGW(serving gateway)(144)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B(140a, 140b, 140c) 각각에 연결될 수 있다. 서비스 제공 게이트웨이(144)는 일반적으로 WTRU(102a, 102b, 102c)로/로부터 사용자 데이터 패킷을 라우팅하고 전달할 수 있다. SGW(serving gateway)(144)는 eNode B간 핸드오버 동안 사용자 평면을 앵커링(anchoring)하는 것, WTRU(102a, 102b, 102c)에 대해 하향링크 데이터가 이용가능할 때 페이징(paging)을 트리거하는 것, WTRU(102a, 102b, 102c)의 컨텍스트를 관리하고 저장하는 것 등과 같은 다른 기능도 수행할 수 있다.

SGW(serving gateway)(144)는, WTRU(102a, 102b, 102c)와 IP-기반(IP-enabled) 디바이스 사이의 통신을 용이하게 해주기 위해, 인터넷(110)과 같은 패킷 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있는 PDN 게이트웨이(146)에도 연결될 수 있다.

코어 네트워크(106)는 기타 네트워크와의 통신을 용이하게 해줄 수 있다. 예를 들어, 코어 네트워크(106)는, WTRU(102a, 102b, 102c)와 종래의 지상선(land-line) 통신 디바이스 사이의 통신을 용이하게 해주기 위해, PSTN(108)과 같은 회선 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다. 예를 들어, 코어 네트워크(106)는 코어 네트워크(106)와 PSTN(108) 사이의 인터페이스로서 역할하는 IP 게이트웨이[예컨대, IMS(IP multimedia subsystem, IP 멀티미디어 서브시스템) 서버]를 포함할 수 있거나 그와 통신할 수 있다. 그에 부가하여, 코어 네트워크(106)는 다른 서비스 공급자에 의해 소유되고 및/또는 운영되는 다른 유선 또는 무선 네트워크를 포함할 수 있는 네트워크(112)에 대한 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.

도 2는 다수의 SSO 프로토콜들 및/또는 모듈들을 사용하기 위한 아키텍처 프레임워크의 일 실시예를 나타낸 것이다. 도 2에 예시된 바와 같이, SSO 서브시스템(206)은 서비스 제공자로부터의 서비스들에 액세스하도록 구성되는 애플리케이션 ― 브라우저 애플리케이션(202) 및/또는 넌-브라우저 애플리케이션(204) 등 ― 과 통신하고 있을 수 있다. 애플리케이션[브라우저 애플리케이션(202) 및 넌-브라우저 애플리케이션(204)]은 사용자와 상호작용할 수 있는 애플리케이션일 수 있다. 브라우저 애플리케이션(202) 및/또는 넌-브라우저 애플리케이션(204)을 사용하여, 사용자는 각종의 서비스들(예컨대, 웹 사이트, 뱅킹 서비스, 공연에 대한 티켓 발급 서비스, 및/또는 서비스 제공자에 의해 제공되는 기타 서비스들)에 액세스할 수 있다.

SSO 서브시스템(206)은 SSO 프로세스에 대한 허브로서 역할할 수 있다. 한 예시적인 실시예에서, SSO 서브시스템(206)은 통신사업자에 의해 제어될 수 있다. SSO 서브시스템(206)은 사용자 인증(예컨대, 사용자-보조 인증 및/또는 네트워크-보조 인증)을 수행하는 것에 의해 네트워크 프록시로서 역할할 수 있다. 그에 부가하여, SSO 서브시스템(206)은 이어서, 네트워크-보조 인증을 위해, 서명된 또는 다른 방식으로 신뢰할 수 있는 사용자 ID 어써션 및/또는 인증 어써션을 생성하고 및/또는 서비스 제공자로 송신(submittal)하는 것을 수행할 수 있다. 보안 저장(secure storage) 및 처리 등의 SSO 서브시스템(206)의 기능들 중 일부가 신뢰된 보안 환경(218) 내에서 수행될 수 있다.

도 2에 예시되어 있는 아키텍처는 사용자-보조 인증 경험을 다수의 개별적인 독립적(self-contained) 네트워크-보조 인증 기술들(예컨대, SSO 기술 또는 SSO 프로토콜 또는 SSO 프록시라고도 함)과 통합시킬 수 있고, 이들 중 일부는 인증 및 키 교환을 위한 부트스트랩핑 메커니즘(bootstrapping mechanism)을 수행하기 위해 네트워크-보조 인증을 사용할 수 있다. 예를 들어, SSO 서브시스템(206)은 다수의 인증 모듈들(208, 210, 212, 214, 및/또는 216)과 통신하고 있을 수 있고, 각각의 인증 모듈은 상이한 네트워크-보조 인증 프로토콜을 사용하여 서비스 제공자에 대해 네트워크-보조 인증을 수행할 수 있다. 이들 네트워크-보조 인증 모듈(208, 210, 212, 214, 및/또는 216)은, 디지털 인증서(digital certificate), 공유 마스터 비밀(shared master secret), 또는 상이한 지원되는 인증 방식에 의한 임의의 다른 등록 방법 등의 사전 설치된 크리덴셜에 기초하여, 원하는 서비스에 대한 보안 사용자 액세스를 제공하기 위해 사용될 수 있다. 예시적인 실시예에 따르면, 인증 모듈들은 OpenID/SIP 다이제스트(OpenID/SIP digest) 모듈(208), 다른 OpenID 모듈(210), OpenID/GBA 모듈(212), OpenID/ISIM 모듈(214), 및/또는 OpenID/AKA 모듈(216)을 포함할 수 있다. 도 2에 예시되어 있는 네트워크-보조 인증 모듈들 각각이 OpenID 네트워크-보조 인증 프로토콜을 구현하지만, 그에 부가하여 또는 다른 대안으로서, 다른 유형의 네트워크-보조 인증 프로토콜들이 구현될 수 있다.

네트워크-보조 인증 모듈들 중 하나 이상은 주어진 서비스 제공자 및/또는 ID 제공자에 의해 지원될 수 있다. 각각의 네트워크-보조 인증 모듈은 그의 대응하는 인증 프로토콜을 구현하는 것에 의해, 예를 들어, 인증 알고리즘을 사용하는 것 등에 의해, 네트워크-보조 인증을 수행하도록 구성되어 있을 수 있다. OpenID/GBA 모듈(212), OpenID/ISIM 모듈(214), 및/또는 OpenID/AKA 모듈(216)은 신뢰된 보안 환경(218)과 통신하고 있을 수 있다. 신뢰된 보안 환경(218)은, 예를 들어, UICC, 스마트 카드, 또는 다른 신뢰된 보안 환경을 포함할 수 있다. 한 예시적인 실시예에서, 신뢰된 보안 환경(218)은 UE 상의 하드웨어-기반 엔티티일 수 있고, 민감한 데이터(예컨대, 암호 키, 가입자 크리덴셜)를 안전하게 저장하는 일 및 민감한 기능(예컨대, 암호 계산)의 보안 처리를 실행하는 일을 맡고 있을 수 있다.

도 2에 예시되어 있는 구성요소들 중 하나 이상은 이동 통신 디바이스에 존재할 수 있다. 도 2가 기술된 아키텍처를 갖는 기능 모듈들을 예시하고 있지만, 도 2는 임의의 비애플리케이션 기능(non-application function)이 신뢰된 보안 환경(218) 상에 또는 그를 벗어나 있는 것으로 존재할 것을 필요로 하는 것으로 되어 있지는 않다. 구성요소들 및 그들의 상호작용에 대해 본 명세서에서 더 상세히 기술한다. 인증이 OpenID 프로토콜을 참조하여 기술되어 있을 수 있지만, 동일한 개념이, 예를 들어, Liberty Alliance 등의 다른 인증 프로토콜들에 적용될 수 있다.

사용자는, 예를 들어, 네트워크 애플리케이션 서비스 제공자 등의 서비스 제공자[예컨대, RP(relying party)]에 처음으로 방문하기 위해 애플리케이션[예컨대, 브라우저 애플리케이션(202) 및/또는 넌-브라우저 애플리케이션(204)]을 사용할 수 있다. 서비스 제공자(예컨대, RP)는, 예를 들어, OpenID 사용자 식별자일 수 있는 사용자 ID(user identification)를 수신할 수 있다. OpenID의 경우에, 사용자는, RP 개시 발견(RP initiated discovery) 이후에, 네트워크-기반 ID 관리 엔티티[예를 들어, OP(OpenID Provider)일 수 있음]로 리디렉션될 수 있다[예컨대, 발견 메커니즘이 OP ID(identity)를 사용하여 OP의 인터넷 주소를 결정할 수 있다]. 한 예시적인 실시예에서, OP의 인터넷 주소를 RP에 제공하는 데 OP ID가 사용될 수 있다. 인증 프로세스가 이어서 시작될 수 있다.

SSO 서브시스템(226)은 애플리케이션 측에서 사용자와 상호작용하는 애플리케이션들과의 통신을 가능하게 하는 사용자 인증 인터페이스 및 네트워크-보조 인증 모듈(208, 210, 212, 214, 및/또는 216)에 대한 네트워크 인증 인터페이스를 제공할 수 있다. 이와 같이, 상이한 애플리케이션들[예컨대, 브라우저 애플리케이션(202) 및/또는 넌-브라우저 애플리케이션(204)]은 사용자 입력에 기초하여 SSO 서브시스템(206)에 입력들을 제공할 수 있거나, SSO 서브시스템(206)은 서비스 제공자에 대한 사용자의 네트워크-보조 인증 및/또는 UE에 대한 로컬 사용자-보조 인증을 가능하게 해주기 위해 인증 화면을 사용자에게 제시할 수 있다. 상이한 네트워크-보조 인증 모듈(208, 210, 212, 214, 및/또는 216)(예컨대, SSO 프로토콜)은 SSO 서브시스템(206)과 상호작용하도록 설계될 수 있다. 정책 관리가 또한 SSO 서브시스템(206)에 의해 수행될 수 있다.

SSO 서브시스템(206) 인증 구조(authentication structure)는 2가지 유형의 사용자 인증 ― 사용자-보조 인증 및 네트워크-보조 인증 ― 을 가지고 있을 수 있다. 이들 유형 둘 다는 하나가 다른 것에 독립적으로 행해질 수 있도록 분리되어 있을 수 있지만, 이 둘은 (예컨대, SSO 서브시스템에 의해 생성될 수 있는 어써션을 통해) 서로 바인딩되어 있고 서로 상호작용할 수 있다(예컨대, 사용자-보조 인증이 네트워크-보조 인증을 트리거할 수 있거나 그 반대로 할 수 있다). 사용자의 사용자-보조 인증 및 (사용자-보조 인증을 위한) 사용자로부터의 크리덴셜을 SSO 서브시스템(206)에 프로비저닝하는 것이 독립적으로 행해질 수 있고, 네트워크-보조 인증 프로토콜과 분리되어 있을 수 있다. 사용자가 네트워크-보조 인증 프로토콜로부터 은폐(shield)되어 있을 수 있다. 이 투명성은, 단일 세트의 사용자 크리덴셜이 서비스 제공자에 독립적일 수 있다는 사실과 함께, 사용자에 대한 매끄러운 SSO 경험을 가져올 수 있다. 더욱이, 2가지 인증 유형은 사용자 주장 ID(user claimed identity)를 그의 크리덴셜(생체 인식, 비밀 번호, PIN, 토큰, 다른 사용자 크리덴셜, 또는 그 조합 등)을 통해 UICC에 보유되어 있는 가입자 크리덴셜 또는 디바이스 ID(device identity)(IMSI 또는 IMPI 등)와 바인딩(binding)하는 것을 제공할 수 있다. 이러한 바인딩은, 양 유형의 인증의 구조적 분리와 함께, 중개자 계층(intermediary layer)으로서 역할하는 SSO 서브시스템(206)에 의해 달성될 수 있다. SSO 서브시스템은 자체적으로 또는 본 명세서에 기술되어 있는 바와 같은 하위 계층 인증 프로토콜들 중 하나를 호출하는 것에 의해 암호 바인딩(cryptographic binding)을 수행할 수 있다.

SSO 서브시스템(206)은, 예를 들어, MNO 등의 외부 이해관계자의 네트워크-보조 인증 기능들에 대한 프록시로서 기능할 수 있고, 프로비저닝된 정책 기능들에 관한 정보를 외부 이해관계자에 제공할 수 있다. 사용자가 (예컨대, 웹 브라우저에서 URL을 입력하거나 애플리케이션을 시작하는 것을 통해) 서비스에 대한 액세스를 개시할 때, 사용자-보조 인증 프로세스가 개시될 수 있다. 예를 들어, 사용자는 생체 인식 크리덴셜 및/또는 비밀 번호(예를 들어, PIN 등) 등의 사용자 크리덴셜을 입력하라고 요청받을 수 있다. 한 예시적인 실시예에서, 이동 통신 디바이스는 디바이스 자체에 액세스하기 위한 PIN 기능(역시 사용자 크리덴셜 정보의 일부일 수 있음)을 가지고 있을 수 있다. 예를 들어, UE의 사용자 인터페이스는 사용자-보조 인증 크리덴셜 정보, 액세스되고 있는 서비스(예컨대, 웹 URL 또는 활성화된 애플리케이션의 형태로 되어 있음), 및/또는 사용될 서비스에 관련된 기타 정보를 특정의 인터페이스를 통해 SSO 서브시스템(206)으로 전달할 수 있다. 이러한 전달은, 제공된 정보 및 프로비저닝된 정책들에 기초하여, 사용자를 인증하기 위해 SSO 서브시스템(206) 내의 기능들을 활성화시킬 수 있다. 예를 들어, 사용자-보조 인증으로부터의 파라미터들이 네트워크-보조 인증 프로토콜에 제공될 수 있다. 이러한 파라미터들은, 예를 들어, 사용자-보조 인증의 신뢰 수준, 사용자-보조 인증의 결과(예컨대, 통과 또는 실패), 및 사용자-보조 인증의 시각을 포함할 수 있다. SSO 서브시스템(206)은, 예를 들어, 액세스되고 있는 서비스에 적절한 것으로 간주되는 인증의 신뢰(보증) 수준 및 인증의 최소 신선성(minimum freshness)(예컨대, 완료된 시각) 등의 다양한 인증 관련 파라미터들을 포함할 수 있는 정책 기능을 실행할 수 있다. 예를 들어, 사용자는 청구서를 지불하기 위해 뱅킹 서비스를 사용하고자 할 수 있다. 이 시나리오에서, 프로비저닝된 정책은 강한 형태의 사용자-보조 인증[예컨대, 다중 인자(multi-factor)]을 필요로 할 수 있고, 프로비저닝된 정책은, 사용자를 서비스로 안내하기 직전에, 인증이 수행될 것을 필요로 할 수 있다. 서비스에 대해 낮은 레벨의 보안이 요망되는 경우(예컨대, 이메일 액세스), 정책들은 사용자-보조 인증 요구사항을 완화시킬 수 있다. 예를 들어, 낮은 레벨의 보안을 갖는 사용자-보조 인증에 대해 PIN이 사용될 수 있다. 한 예시적인 실시예에서, 사용자 인증을 주도하는 정책들은 외부 이해관계자 및/또는 서비스 제공자에 의해 수행될 수 있다. 예를 들어, 서비스 제공자에서(예컨대, 네트워크 상에서), UE에서(예컨대, 로컬적으로), 또는 그 조합에서(예컨대, 분산된 기능) 정책 기능이 수행될 수 있다.

한 예시적인 실시예에서, SSO 서브시스템(206)이 따라야 할 정책들은 네트워크-보조 인증을 위해 어느 SSO 인증 프로토콜[예컨대, 네트워크-보조 인증 모듈(208, 210, 212, 214, 및/또는 216)]이 선택되어야 하는지를 판정할 수 있다. 네트워크-보조 인증 모듈(예컨대, SSO 인증 프로토콜) 선택에 대한 기준은 액세스될 서비스의 이용가능한 자원 및/또는 보안 요구사항에 기초할 수 있다. 내부 정책 메커니즘은 외부 이해관계자(예컨대, MNO)가 선호된 인증 모듈들(예컨대, SSO 프로토콜들)의 우선순위화된 목록을 제공받는 것을 포함할 수 있다. 정책 결정이 행해지면, SSO 서브시스템(206)은 프로토콜 교환을 위해 어느 특정의 네트워크-보조 인증 모듈이 선택되었는지를 외부 이해관계자(예컨대, MNO)에 전달하는 메커니즘을 제공할 수 있다. 다른 대안으로서, SSO 서브시스템은 능력을 협상하고 사용될 인증 모듈에 합의할 수 있다.

도 3a 및 도 3b는 SSO 프레임워크 아키텍처를 사용하여 구현되는 프로토콜의 예시적인 실시예를 나타낸 것이다. OpenID와 관련하여, SSO 서브시스템은 어떤 기능들을 보안 방식으로 수행할 수 있고, 그 기능들 중 일부는 도 3a 및 도 3b에서의 호출 흐름을 참조하여 본 명세서에 기술되어 있다.

도 3a 및 도 3b에 예시되어 있는 바와 같이, 314에서, 사용자-보조 인증이 수행될 수 있다. 예를 들어, 사용자 크리덴셜이 인증 및/또는 처리될 수 있다. 사용자 크리덴셜은 사용자(302)와 연관되는 고유의 인증 파라미터들 ― 사용자 PIN, 비밀 번호, 사용자 식별자, 생체 인식 정보, 또는 다이제스트, 및/또는 기타 형태의 사용자-보조 인증 파라미터들 등 ― 을 포함할 수 있다. 사용자(302)는 로컬적으로, 디바이스(304)에서, 또는 외부 이해관계자(예컨대, MNO) 또는 ID 제공자(IdP)[예컨대, OpenID 제공자(312)] 등의 원격 엔티티와 결합하여 인증될 수 있다.

SSO 서브시스템(308)은 사용자(302)의 인증을 수행하도록 구성되는 사용자 디바이스(304) 상의 로컬 엔티티일 수 있다. SSO 서브시스템(308)은, 다양한 실시예들에 따라, LAE를 사용하거나 사용하지 않고 인증을 수행할 수 있다. 예를 들어, 도 3a는, 본 명세서에 기술되어 있는 바와 같이, SSO 서브시스템이 로컬적으로 인증을 수행할 수 있게 해줄 수 있는 예시적인 프로비저닝 프로토콜 흐름을 나타낸 것이다. 사용자-보조 인증이 완료되면, 316에서, SSO 서브시스템(308)은, 예를 들어, 인증 어써션(authentication assertion) 등의 인증 결과를 발생할 수 있다. 인증 어써션은, 예를 들어, 사용자-보조 인증이 완료된 시각 및 인증의 신뢰 수준 등의 데이터를 포함할 수 있다. 신뢰의 수준은 원격 당사자가 사용자 또는 UE의 인증에 둘 수 있는 보증의 수준(level of assurance)을 말하는 것일 수 있다. 사용자-보조 인증 결과(예컨대, 통과 또는 실패)는 디바이스(304)에 안전하게 그리고 로컬적으로 저장될 수 있고 및/또는 네트워크-보조 인증 프로토콜에서 사용될 수 있다. 사용자-보조 인증과 연관되는 기타 파라미터들도 역시 저장되고 및/또는 네트워크-보조 인증에서 사용될 수 있다. 예를 들어, 이들 파라미터는 인증의 시각, 인증의 강도, 및/또는 인증 파라미터(들)의 유형을 포함할 수 있다. 이들 파라미터는 인증 결과와 함께 저장되거나 네트워크-보조 인증에서 사용될 수 있다. 예를 들어, SSO 서브시스템은 그 정보를 사용하여 인증 데이터를 서비스 제공자에 중계할 수 있고, 서비스 제공자는 사용자에게 서비스에 대한 액세스를 제공하는 데 인증 데이터로 충분한지를 판정할 수 있다. 314에서의 사용자-보조 인증은 언제라도 그리고, 예를 들어, 원하는 보안 강도(security strength) 등의 다양한 인증 정책들에 기초하여 암시된 바와 같이 빈번히 또는 가끔 행해질 수 있다. 한 예시적인 실시예에서, 유효한 사용자-보조 인증 결과가 저장되는 경우, SSO 서브시스템은 사용자-레벨 인증이 수행될 필요가 없는 것으로 판정할 수 있다. 이러한 시나리오는 사용자가, 인증 프로세스에의 추가의 사용자 개입 없이, 다수의 서비스 제공자(예컨대, RP)에 액세스할 수 있게 해줄 수 있다. 정책이, 예를 들어, 특정의 서비스 제공자에서의 특정의 서비스에의 액세스에 대해 새로운 인증을 필요로 하는 경우, 기존의 인증 정보의 이러한 재사용이 허용되지 않을 수 있다.

318에서, RP(310)와 OP(312) 사이에 공유 비밀 키가 설정될 수 있다. 예를 들어, 사용자-제공 식별자를 포함할 수 있는 사용자의 OP 로그온 요청이 애플리케이션(예컨대, 브라우저 또는 넌-브라우저 애플리케이션)(306)으로부터 RP(310)로 전달될 수 있고, 이는 공유 비밀 키의 연관(association) 및/또는 설정을 트리거할 수 있다. 한 예시적인 실시예에 따르면, 사용자가 네트워크-기반 서비스에 처음으로 액세스하려고 시도할 때, 로그온 요청이 RP(310)로 전달될 수 있다. 수신된 로그온 요청에 기초하여, OP(312)와 RP(310) 사이에 공유 비밀 키를 설정할 수 있는 연관이 수행될 수 있다. 한 예시적인 실시예에서, 320에서, 키[예컨대, OP(312) 및 RP(310)로부터 도출된 키, 공유 키 및/또는 네트워크-보조 인증 동안 도출된 키] 및/또는 다른 크리덴셜이 SSO 서브시스템(308)에 프로비저닝될 수 있다. 프로비저닝된 크리덴셜은, 본 명세서에 기술되어 있는 바와 같이, 서비스들에 대한 추가적인 인증에서 사용될 수 있다.

예를 들어, 도 3b에 예시되어 있는 바와 같이, 프로비저닝 후에, 네트워크-보조 인증이 수행될 수 있다. 예를 들어, 네트워크-보조 인증이 RP(310)에 의한 OP(312)로의 리디렉션 이후에 행해질 수 있다. 리디렉션이 애플리케이션(306)(예컨대, 브라우저 애플리케이션 또는 넌-브라우저 애플리케이션)에 의해 수신될 수 있고, 애플리케이션(306)은, 네트워크-보조 인증 모듈 및/또는 프로토콜의 선택을 위해, 321에서, 메시지를 SSO 서브시스템(308)으로 리디렉션할 수 있다. 네트워크-보조 인증 모듈/프로토콜(예컨대, SSO 프로토콜)이 정책 구현을 통해 SSO 서브시스템(308)에 의해 선택되고 사용될 수 있다. 이 프로세스는, 본 명세서에 추가로 기술되어 있는 바와 같이, 부트스트랩핑 및 공유 키 설정을 포함할 수 있다.

도 2에 도시된 바와 같이, 몇가지 네트워크-보조 인증 프로토콜 방법들이 네트워크-보조 인증 모듈들(예컨대, SSO 프로토콜들)의 모음(suite)에 의해 암시될 수 있다. 다시 도 3b를 참조하면, 한 예시적인 실시예에 따르면, OpenID/SIP 다이제스트 및/또는 OpenID/GBA는 GBA 구조를 가지는 것으로 보일 수 있고 3GPP(3rd Generation Partnership Project) TS(Technical Specification) 번호 33.220(릴리스 10)에 규정되어 있는 메커니즘들을 이용할 수 있다. OpenID GBA에서, 네트워크와 공유될 마스터 세션 키(master session key)(예컨대, Ks로 표시되어 있음)를 부트스트랩하기 위해 UICC 가입자 크리덴셜이 사용될 수 있다. 네트워크-보조 인증의 결과, Ks로부터 도출되고 OP(312)와 사용자 디바이스(304) 사이에서 공유되는 애플리케이션 관련 키 Ks_NAF가 얻어질 수 있다. OP(312)에 대해 인증을 할 때, 애플리케이션 관련 키는 사용자 디바이스(304)에 의해 비밀 번호로서 사용될 수 있다. 예를 들어, 애플리케이션 관련 키는, 예를 들어, 3GPP TR(Technical Report) 번호 33.924(릴리스 9)에 기술되어 있는 바와 같이, 사용자 디바이스(304)에 의해 비밀 번호로서 사용될 수 있다.

OpenID/SIP 다이제스트의 경우, 유사한 GBA 프로세스를 통해 유사한 키 구조가 얻어질 수 있다. 네트워크-보조 인증에 대한 이 방식은 비UICC 기반(non-UICC based)일 수 있고, 예를 들어, UICC 크리덴셜보다는 SIP 다이제스트 크리덴셜이 사용될 수 있다. OpenID/SIP 다이제스트의 한 예시적인 실시예가 3GPP TR 33.914(릴리스 11)에 기술되어 있다.

OpenID/AKA의 경우, 네트워크-보조 인증은 비GBA 기반(non-GBA based)일 수 있고, 사용자 디바이스(304) 및 OP(312)는 직접 키를 인증하고 공유하기 위해 3GPP AKA를 이용할 수 있다. OpenID/AKA의 한 예시적인 실시예는 3GPP SA3에서의 Alcatel-Lucent pCR S3-100757에 기술되어 있다.

종래의 OpenID의 경우, SSO 서브시스템(308)은 수신된 사용자 크리덴셜을 네트워크-보조 인증 프로토콜에서 제공할 수 있다.

OpenID/GBA, OpenID/SIP 다이제스트, 및 OpenID/AKA가 구조상 차이를 가질 수 있지만, 네트워크 HSS(Home Subscription Server)로부터 수신된, 한 유형 또는 다른 유형의 인증 벡터(authentication vector, AV)의 적용이 각자의 프로토콜에 가장 중요할 수 있다. 그에 부가하여, 정책들 및 원하는 보안 강도에 따라, 네트워크-보조 인증이 수행될 때 사용자의 재인증(사용자-보조 인증)이 수행될 수 있다. 한 예시적인 실시예에서, 이러한 네트워크-보조 인증 동안, 디바이스가 네트워크 연결을 설정하였고, 서비스 제공자에 대해 UE를 인증하기 위해 네트워크-보조 인증이 사용될 수 있는 것으로 가정될 수 있다.

성공적인 네트워크-보조 인증 후에, SSO 서브시스템(308)은 네트워크-보조 인증이 성공적이었다는 표시를 애플리케이션(306)에 제공할 수 있다. 예를 들어, SSO 서브시스템은 (예컨대, LAE를 통해), 322에서, 인증 어써션[예컨대, ID 어써션(identity assertion)]에 서명하고, 324에서, 어써션 메시지를 RP(310)로 전송할 수 있다. SSO 서브시스템(308)으로부터 RP(310)로의 서명된 어써션 메시지는 성공적인 인증을 나타낼 수 있고, 이전에 프로비저닝된 크리덴셜(예컨대, 도 3a에서 320에 도시되어 있음)을 사용하여 SSO 서브시스템(308)에 의해 자율적으로 서명될 수 있다. 사용자(302)가 RP(310)에서의 원하는 서비스에 액세스하기 전에, 성공적인 네트워크-보조 인증을 이와 같이 통지하는 것이 수행될 수 있다. 인증 프로세스(예컨대, SSO 프로세스)에서 조기에, OP(312)와 RP(310) 사이에 공유 비밀 키를 설정하는 연관이 수행되었을 수 있다. 하나의 예시적인 실시예에서, 어써션 메시지가 이 공유 비밀 키 및/또는 키의 도출에 의해 서명될 수 있다. RP(310) 및/또는 사용자 디바이스(304)가 [예컨대, 애플리케이션(306)을 통해] 네트워크-보조 인증이 성공적이었다는 표시를 수신하면, 사용자 디바이스(304)는 [예컨대, 애플리케이션(306)을 통해] 자신이 로그온해 있는 RP(310)에서의 서비스에 액세스할 수 있다.

RP(310)에 제공되는 어써션 메시지는 네트워크에 대한 인증 및 서비스에 대한 인증 둘 다가 완료되었을 수 있다는 것과 사용자-보조 인증에서 구현되는 사용자 주장 ID가 네트워크-보조 인증에서 구현되는 가입자 크리덴셜(예를 들어, IMSI 또는 IMPI 등)에 바인딩되어 있을 수 있다는 것을 나타낼 수 있다. 예를 들어, 사용자-제공 크리덴셜과 UICC-기반(또는 SIP 다이제스트) 크리덴셜 간의 연결을 알고 있는 메커니즘을 통해 바인딩이 수행되어야 하는 것은 선택된 SSO 기능의 일부일 수 있다. 어써션 메시지는 바인딩을 전체 SSO 프로토콜의 일부로서 나타내는 정보를 포함할 수 있다. 또한, 한 예시적인 실시예에서, 어써션 메시지는 인증 강도 레벨 또는 신뢰 수준(예컨대, 낮음, 중간, 높음, 아주 높음)을 제공할 수 있다. 예를 들어, 어써션 메시지에서의 낮은 인증 강도는 OP(312)가 어써트된 ID를 거의 또는 전혀 신뢰하고 있지 않다(예컨대, 비밀 번호의 형식에 대한 최소 규칙에 의한 사용자 이름/비밀 번호의 자동 삽입)는 것을 나타낼 수 있고; 중간 인증 강도는 OP(312)가 어써트된 ID를 얼마간 신뢰하고 있다(예컨대, 비밀 번호의 형식에 적용되는 규칙에 의한 사용자 이름/비밀 번호의 수동 사용)는 것을 나타낼 수 있으며; 어써션 메시지에서의 높은 인증 강도는 OP(312)가 어써트된 ID에 높은 수준의 신뢰를 가지고 있다(예컨대, 생체 인식 또는 암호 네트워크-액세스 토큰 및 사용자 이름/비밀 번호의 사용)는 것을 나타낼 수 있고; 아주 높은 인증 강도는 OP(312)가 어써트된 ID에 아주 높은 수준의 신뢰를 가지고 있다(예컨대, 생체 인식 및 암호 토큰)는 것을 나타낼 수 있다. 한 예시적인 실시예에서, "낮음" 및 "중간" 레벨은 사용자 크리덴셜만이 사용된다는 것을 나타낼 수 있고, "높음" 및 "아주 높음" 레벨은 네트워크-보조 상호작용이 행해질 것을 필요로 할 수 있고, 생체 인식 및 비밀 번호 등의 보다 강력한 형태의 인증을 필요로 할 수 있다.

다시 도 2를 참조하면, 도 2는 네트워크 제어(network controlled) 부트스트랩핑 및 키 설정을 위해 이용가능할 수 있는 예시적인 SSO 기술(프로토콜)을 나타낸 것이다. 예를 들어, OpenID/ISIM(214) 및 OpenID/AKA(216)는 UlCC-기반일 수 있고, UICC 상에 안전하게 존재할 수 있는 크리덴셜(네트워크와의 공유 비밀 등)을 사용할 수 있다. OpenID/GBA(212)는, 예를 들어, 네트워크와 공유되는 크리덴셜에 따라, UICC 기반일 수 있거나 그렇지 않을 수 있다. 한 예시적인 실시예에서, OpenID/SIP 다이제스트(208)는 UICC 기반이 아닐 수 있다. 예를 들어, 종래의 사용자-제공 OpenID ID 및 비밀 번호가 수용될 수 있다. SSO 서브시스템의 네트워크 인증 인터페이스는 다양한 SSO 프로토콜들[예컨대, 도 2에서의 모듈들(208, 210, 212, 214, 216)]이 단일의 아키텍처 프레임워크 내에 수용될 수 있게 해줄 수 있다.

한 예시적인 실시예에 따르면, 2가지 인증 유형 바인딩을 사용하여 사용자가 검증될 수 있다. 사용자 검증(user verification)이 OpenID 프로토콜을 참조하여 기술되어 있을 수 있지만, 동일한 개념이, 예를 들어, Liberty Alliance 등의 다른 인증 프로토콜들에 적용될 수 있다. 예를 들어, UE의 전원을 켤 때, 사용자-보조 인증이 행해질 수 있다. 예를 들어, 사용자는 디바이스 기능들에 액세스하기 위해 사용자-보조 인증 크리덴셜(예컨대, PIN, 생체 인식)을 제공할 수 있다. 예를 들어, 사용자는 아이폰(iPhone)에 액세스하기 위해 PIN을 제공할 수 있다. 이러한 인증 메커니즘은 전원 켜짐 시에 한번 또는 세션 전체에 걸쳐 간헐적으로 제공될 수 있다. 사용자를 인증하는 것에 대한 빈도수 요구사항은 정책 기반(policy driven)일 수 있다. SSO 서브시스템은 사용자-제공 PIN을 검증할 수 있고, 그 결과(PIN이 입력되고 검증되었다는 것을 확인해주는 어써션의 형태로 되어 있을 수 있음)를 저장할 수 있다. 이러한 어써션은 사용자-보조 인증을 확립할 수 있다. 사용자-보조 인증이 확립된 후에, 사용자는, 예를 들어, 웹 브라우저를 RP 웹 페이지로 가게 함으로써 OpenID 프로토콜을 지원할 수 있는 서비스 제공자(예컨대, RP)에 대한 로그인을 시도할 수 있다. SSO 서브시스템은 사용자-보조 인증의 상태를 검사할 수 있고, 상태가 유효한 경우, 사용자 ID를 RP에 제공할 수 있다. RP는 OpenID 제공자(OP)의 발견을 수행할 수 있고, 2개의 엔티티가 연관을 설정할 수 있다. 이러한 연관의 결과, 공유 키가 얻어질 수 있다. 디바이스는 SSO 서브시스템에 의해 수행될 수 있는 UE 상의 로컬 OpenID 프록시 기능(on-UE local OpenID proxy function)일 수 있는 LAE로 리디렉션될 수 있다. 한 예시적인 실시예에서, SSO에 의해 수행되는 (예컨대, 외부 이해관계자의) 정책은 강력한 네트워크-보조 인증(예컨대, GBA, SIP, AKA)이 수행될 것을 필요로 할 수 있다. 인증 모듈(예컨대, SSO 프로토콜)이 선택될 수 있다. 이러한 선택은 인증 프로토콜에서 SSO 서브시스템에 의해, 예를 들어, MNO에 보고될 수 있다. UE의 인증이 선택된 네트워크-보조 인증 모듈(예컨대, SSO 프로토콜)을 사용하여 수행될 수 있다. 한 예시적인 실시예에서, 인증 프로토콜이 선택된 결과, 네트워크-보조 인증 기능과 UE 간의 공유 애플리케이션 관련 키가 부트스트랩핑될 수 있다. 이러한 키는 UE를 인증하는 데 사용될 수 있다.

UE는 인증 완료의 표시를 수신할 수 있고, LAE는 강력한 인증이 행해졌다는 것을 표시하는 어써션 메시지에 서명하여 RP로 보낼 수 있다. 어써션은 (예컨대, 초기 사용자 PIN 입력을 통한) 사용자-보조 인증과 (예컨대, 선택된 SSO 인증 프로토콜을 통한) 후속하는 네트워크-보조 인증 간의 바인딩을 나타낼 수 있다. 어써션은 본 명세서에 정의되어 있는 인증 신뢰 수준들 중 하나를 나타낼 수 있다. 로컬 SSO 프록시(예컨대, LAE)와 RP 사이의 연관을 통해 설정된 키를 사용하여 어써션 메시지가 서명될 수 있다. RP 및 LAE는 직접 통신하지 않을 수 있고, 따라서 2개의 엔티티 간의 통신을 용이하게 해주기 위해 OPSF(OP service function)이 네트워크 상에 생성될 수 있다. 한 예시적인 실시예에서, OPSF는, 마치 자신이 OP인 것처럼, 이 기능과 통신할 수 있는 RP에 의해 공중 인터넷을 통해 도달가능할 수 있다. 로컬 SSO(LAE) 프록시는 OPSF 키 배포 메커니즘을 통해 연관 키를 획득할 수 있다. OPSF는 또한 LAE로부터 오는 서명된 어써션과 관련하여 RP를 위해 서명 검증을 지원할 수 있다. 사용자는 이어서 RP 웹 페이지로 매끄럽게 보내질 수 있다. 한 예시적인 실시예에서, 사용자가 나중에 상이한 서비스 제공자에 액세스하고자 할 때, SSO 서브시스템은 사용자-보조 인증 결과가 이미 저장되어 있는지와 (예컨대, 로컬적으로 저장된 정책에 따라) 그 인증이 여전히 유효한지를 검사할 수 있다. 예를 들어, 유효한 저장된 결과가 있는 경우, SSO 서브시스템은 이 때 사용자-보조 인증을 수행하지 않을 수 있다. 그러면, 새로운 서비스 제공자는 본 명세서에 기술되어 있는 바와 같이 ID 제공자의 발견을 수행할 수 있다. 이와 같이, 사용자는 UE에서 크리덴셜을 입력하는 일 없이 새로운 서비스 제공자에 액세스할 수 있고, 사용자는 네트워크-보조 인증에 관여되지 않을 수 있다. 이러한 시나리오는 일 실시예에 따른 완전 SSO 구현을 구성할 수 있다.

한 예시적인 실시예에서, 사용자는 선호하는 서비스 및/또는 애플리케이션의 등록을 통해 선호하는(예컨대, 제휴된) 서비스에 액세스할 수 있다. 예를 들어, 웹 또는 다른 온라인 애플리케이션 서비스 제공자[예컨대, RP(relying party)]는 서비스 제공자가 선택한 IdP를 사용하여 통신사업자의 네트워크-기반 SSO 시스템에 등록할 수 있다. 예를 들어, 지불 거래 제공자(payment transaction provider)는 특정의 IdP로부터 위임된 인증을 획득하기 위해 OpenID를 사용할 수 있고, 그 결과 지불 거래 제공자가 제휴된 서비스로 될 수 있다. 이 등록은 서비스 제공자(예컨대, RP), 선택된 IdP, 통신사업자의 SSO 시스템, 또는 서비스의 최종 사용자에 의해 개시될 수 있다. 게다가, 이 등록은 웹 페이지에 액세스하는 사용자 또는 UE에 존재하는 SSO 서브시스템에 의해 개시될 수 있다. 예를 들어, UE에 존재하는 SSO 서브시스템은 네트워크-기반 SSO 서브시스템의 데이터베이스에 "동기화"될 수 있고, 그에 의해, 등록되어 있는 제휴된 서비스 및 애플리케이션의 목록 및 유형을 알게 될 수 있다.

RP는 SSO 프로토콜을 명시적으로 선택하지 않으면서 IdP를 선택하도록 허용되어 있을 수 있다. 예시적인 실시예에 따르면, IdP의 선택과 사용될 SSO 프로토콜 사이에 암시적 연관(implicit association)이 있을 수 있다. 예를 들어, RP는 특정의 IdP를 선택할 수 있는데, 그 이유는 IdP가 OpenID 등의 특정의 SSO 프로토콜을 지원할 수 있기 때문이다.

사용자는 이어서 UE를 사용하여 SSO(예컨대, OpenID) 지원 웹-기반 애플리케이션 서비스에 액세스할 수 있다. UE에 존재하는 SSO 서브시스템은 통신사업자가 프로비저닝한 정책을 따를 수 있고, 등록되어 있는 제휴된 서비스/애플리케이션 및/또는 선호하는 서비스/애플리케이션을 선택할 수 있다. UE에 존재하는 SSO 서브시스템은 또한, 예를 들어, 사용자가 (예컨대, URL에 타이핑하는 것을 통해) 자신이 선호하는 서비스를 나타낸 후에, 가로채기(개입)할 수 있고, 사용자가 타이핑한 URL을, 동일한 서비스의 등록되어 있는 제휴된 버전에 대응하는 대안의 서비스의 URL로 변환 또는 대체할 수 있다. 이러한 대체 서비스는 동일한 제공자에 의해 제공될 수 있지만, 제휴 우선적(preferential, affiliated) 방식으로 제시되고 액세스될 수 있다. 예를 들어, 액세스가 상기한 서비스들/애플리케이션들에 대한 상기한 등록-기반 제휴를 가지는 통신사업자(예컨대, 이러한 서비스들/애플리케이션들을 제공할 수 있는 IdP 및 RP)에 의해 서비스되는 UE의 사용자로 제한될 수 있다.

예시적인 실시예에 따르면, 서비스/애플리케이션의 선택 후에, UE는, 사용자를 위해, 투명하고 및/또는 매끄러운 방식으로, 선호하는 액세스 네트워크-보조 인증 메커니즘 및 적절한 크리덴셜을 선택할 수 있다. 예를 들어, UE는 선택된 액세스 네트워크-보조 인증 메커니즘을 SSO 인증 프로토콜 내에 나타낼 수 있다. 네트워크는 선택된 선호하는 액세스 네트워크-보조 인증 메커니즘을 인식할 수 있고, 사용자를 인증할 수 있다. 성공적인 인증 시에, 나머지 SSO 동작(예컨대, 서비스를 획득하기 위해 UE가 RP로 리디렉션되는 것)이 행해질 수 있다.

본 명세서에 기술된 바와 같이, 통신사업자의 SSO 시스템을 통해 통신사업자의 신뢰 기반구조(trust infrastructure)에 연결함으로써, 가입되고 제휴된 서비스는 통신사업자에 의해 제공되는 네트워크-보조 인증 강도를 효과적으로 획득할 수 있다.

보다 일반적으로, 본 명세서에 기술되어 있는 SSO 아키텍처는 보다 정형화된(formalized) 기능 계층구조를 포함하는 것으로 보일 수 있다. 예를 들어, SSO 서브시스템은 하나 이상의 SSO 클라이언트(예컨대, 또는 로컬 SSO 프록시)를 관리할 수 있다. 기초를 이루는 디바이스 기술이 다중-서비스 제공자 구성을 지원하는 경우, 다수의 SSO 클라이언트가 SSO 서브시스템 내에서 다중-서비스 관리자에 대한 서브기능으로서 실행될 수 있다. 이 일반화된 아키텍처는 아마도 독립적인 정책을 사용하여 다수의 서비스를 지원하기 위해 사용되는 분리를 제공할 수 있다.

이러한 프레임워크 내의 각각의 SSO 클라이언트는 몇개의 하위 서브기능을 관리할 수 있다. 예를 들어, 로컬 어써션 서브기능이 LAE(Local Assertion Entity)에 의해 수행될 수 있다. LAE는 로컬 어써션을 수행하는 서브기능의 공식 명칭(formal designation)을 말하는 것일 수 있다. 예를 들어, 구현에 따라, 하나 이상의 LAE가 SSO 클라이언트에 의해 제어될 수 있다. 예를 들어, 이 구성은 SSO 클라이언트-LAE 쌍(일대일) 또는 하나의 클라이언트가 다수의 LAE를 제어하는 것을 수반할 수 있다. 어느 구성에서든, SSO 클라이언트는 제어 엔티티(controlling entity)일 수 있다. SSO 인증 프로토콜은 본 명세서에서 SSO 기술이라고도 할 수 있다. 예를 들어, SSO 클라이언트는 선택된 SSO 인증 프로토콜에 의해 수행되는 메커니즘들의 처리를 제어할 수 있다. SSO 클라이언트는 어느 인증 방법이 사용될 수 있는지를 결정할 수 있는 정책 시행 동작들을 관리할 수 있다. 예를 들어, 적용되는 정책들이 MNO 등의 외부 이해관계자의 제어 하에 있을 수 있다.

다른 실시예에 따르면, UE는 다중-서비스 관리자 내에서 서브기능으로서 실행되는 다수의 SSO 클라이언트의 구현을 지원할 수 있다. 이러한 구현은, 동일한 제공자에 의해 동시에 제공되는 다수의 이용가능한 연결 기술들 및 서비스들의 정책-기반 관리를 가능하게 해주면서, 상이한 서비스 제공자들이 그 특정의 제공자에만 서비스하는 개별적인 격리된 SSO 클라이언트를 필요로 할 수 있는 환경에서 기능하는 것으로 보일 수 있다. 예를 들어, ME는 SSO 클라이언트 A 및 SSO 클라이언트 B를 가질 수 있고, 이들 SSO 클라이언트 각각은 개별적으로 제어될 수 있고 서로로부터 격리되어 있을 수 있다. SSO 측면들은 제공자에 특유할 수 있다.

다수의 SSO 클라이언트들과 함께, 한 예시적인 실시예에서, 다수의 LAE가 있을 수 있다. 예를 들어, 각각의 LAE는 UE 상의 액세스 기술 관련 도메인에 구현될 수 있다. SSO 클라이언트 격리로 인해, 격리된 도메인마다 하나의 LAE가 있을 수 있다. 또한, 예를 들어, LAE는 디바이스에 의해 지원되는 이용가능한 액세스 기술들에 따라 구성되어 있을 수 있다. 동일한 액세스 기술이 상이한 LAE들 간에 다중화될 수 있거나, 상이한 액세스 기술들이 LAE들에 의해 동시에 사용될 수 있다. 이와 같이, UE는 다수의 LAE를 지원할 수 있다. 예를 들어, 구현에 따라, LAE와 SSO 클라이언트 간의 관계는 일대일일 수 있거나, 하나의 SSO 클라이언트가 다수의 LAE를 제어하거나 그에 의해 서비스될 수 있다.

본 명세서에 기술된 바와 같이, SSO 서브시스템 내에서 수행되는 기능들은 각종의 방식으로 구성되어 있을 수 있다. 예를 들어, UE에서, UICC-기반 아키텍처와 비UICC-기반(또는 대안적으로 보안 환경-기반) 아키텍처가 나누어져 있을 수 있다. 또한, UE와 MNO 네트워크 간에 기능들의 구분이 있을 수 있다. 이하는 다양한 실시예들에 따른 몇몇 가능한 구성들이다.

암호 AKA 함수가 비UICC 스마트 카드 상에 존재할 수 있다. 이러한 함수는 완전 프로그램가능 비UICC 스마트 카드(G&D의 MSC 등) 상에서 수행될 수 있고, 네트워크-보조 인증(예컨대, AKA)와 유사할 수 있지만, 이 카드는 이동식이고 사용자 제어 하에 있을 수 있다. 암호 함수가 UICC 상에 존재할 수 있다. 이러한 함수들은 UICC 상에 구현되는 LAE의 기본적인 암호 함수들(예를 들어, 키 도출 및 어써션 서명 등)을 포함할 수 있다. 이 기능은 네트워크-보조 인증(AKA)과 유사할 수 있다. 그에 부가하여, IMSI에 대한 바인딩 및 MNO에의 사용자 등록이 실현될 수 있다.

한 예시적인 실시예에 따르면, LAE 기능들은 UICC 또는 신뢰된 보안 환경 상에 존재할 수 있다. 예를 들어, LAE는 스마트 카드 웹 서버(smartcard web server, SCWS) 또는 다른 웹 브라우저 애플리케이션 상에서의 OpenID의 완전한 구현일 수 있다. 한 예시적인 실시예에서, 네트워크-보조 인증 구성은 LAE(예컨대, 로컬 어써션) 인증을 임의의 형태의 강력한 네트워크-보조 인증(예컨대, 로컬 OpenID/GBA)에 바인딩하는 것일 수 있다. 강력한 인증은 생체 인식 또는 유사한 로컬 인증을 부가함으로써 부가의 인자로서 강력한 로컬 사용자-보조 인증에 적용될 수 있다. 예를 들어, 임의의 형태의 강력한 로컬 인증이 네트워크-보조 인증과 결합되고 그에 바인딩될 수 있다.

도 4는 다수의 SSO 프로토콜들 및/또는 모듈들을 사용하기 위한 아키텍처 프레임워크의 다른 예시적인 실시예를 나타낸 것이다. 도 4에 예시된 바와 같이, UE(402)의 SSO 서브시스템(400)은 웹 서비스(406)(예컨대, RP) 등의 서비스 제공자로부터의 서비스에 액세스하도록 구성되는 애플리케이션[예컨대, 브라우저 애플리케이션(404)]과 통신하고 있을 수 있다. SSO 서브시스템(400)은 사용자에게 SSO 기능을 제공할 수 있고, 인증 서비스에 대한 사인온(sign-on) 프로세스에서의 자동화를 생성할 수 있다. 예를 들어, 자동화 특징은, 사용자 상호작용 없이, 사용자 식별자를 웹 서비스(406)에 및/또는 크리덴셜들을 ID 제공자[예컨대, OpenID 제공자(OP)(408)]에 제공할 수 있는 기능들을 포함할 수 있다. 자동화는 또한 인증 크리덴셜을 OP(408)의 인증자(authenticator)(410)에 자동으로 프로비저닝하는 것은 물론, 인증 모듈(예컨대, 인증 방법)을 자동으로 선택하고 협상하는 것을 특징으로 가질 수 있다. 예시적인 실시예에 따르면, 인증 모듈들은 OpenID/SIP 다이제스트 모듈(4188), OpenID/GBA 모듈(412), EAP/SIM 모듈(416), 및/또는 OpenID/AKA 모듈(414)을 포함할 수 있다. 예를 들어, 도 5는 GBA 모듈(412)이 SSO 서브시스템(400)에 의해 선택되는 한 예시적인 실시예를 나타낸 것이다. 도 4에 예시되어 있는 네트워크-보조 인증 모듈들 각각이 OpenID 네트워크-보조 인증 프로토콜을 구현할 수 있지만, 그에 부가하여 또는 다른 대안으로서, 다른 유형의 네트워크-보조 인증 프로토콜들이 구현될 수 있다. SSO 서브시스템(400)에 의해 제공되는 자동화는, 무선 디바이스[예컨대, UE(402)] 상에 저장되어 있고, 예를 들어, OP(408)에 의해 프로비저닝되는 이전에 정의된 정책(들)에 기초하여, 실행될 수 있다. 이러한 자동화는 [예컨대, 브라우저(404)에 저장되어 있는] 쿠키, 자바 애플릿, 브라우저 캐시 저장 폼 데이터(browser cache storing form data) 등에 의해 제공될 수 있다. 한 예시적인 실시예에서, 자동화는, 예를 들어, 채워질 폼을 자동으로 검출할 수 있는 긁기 함수(scraping function)에 의해 제공될 수 있다.

예를 들어, 자바 애플릿을 사용하는 한 예시적인 실시예에서, 자동화 특징은 인증 프로세스 동안 다운로드될 수 있는 자바 애플릿에 포함될 수 있다. 본 명세서에서 논의되는 자동화 특징이 자바 애플릿에 의해 구현될 수 있지만, 본 명세서에 기술되어 있는 실시예들은 그것으로 제한되지 않는다. 일부 실시예에서, 영속적 특징(예컨대, 사용자 로그인 상태)이 자바 애플릿에 위치해 있지 않을 수 있는데, 그 이유는, 예를 들어, 애플릿이 브라우저 캐시로부터 제거될지도 모르기 때문이다. 그에 부가하여, 본 명세서에 기술된 바와 같이, 프로토콜 실행 프로세스에서 다운로드 후에 자바 애플릿이 이용가능하게 될 수 있다. 자바 애플릿을 사용하는 기능들은 애플릿이 디바이스(UE 등)로 다운로드된 후에 수행될 수 있다. 예를 들어, 자바 애플릿이 OP로 리디렉션된 후에 OP로부터 다운로드되는 경우, 자바 애플릿 자체는 긁기 특징을 제공하지 않을 수 있다.

도 6은 다수의 SSO 기술 및/또는 모듈의 사용을 용이하게 해주는 다운로드가능 구성요소를 포함하는 아키텍처 프레임워크의 한 예시적인 실시예를 나타낸 것이다. 예시적인 다운로드가능 구성요소[예컨대, 인증 요청자(622)]는 브라우저 애플리케이션 및/또는 넌-브라우저 애플리케이션[예컨대, 애플리케이션(604)]에 대한 인터페이스를 네트워크-보조 모듈[예를 들어, 인증 모듈, 프로토콜, 및 API 등(예컨대, 모듈들(612, 614, 616, 618, 및 620)]에 제공할 수 있다. 한 예시적인 실시예에서, 다운로드가능 구성요소[예컨대, 인증 요청자(622)]는 완전 SSO 서브시스템(600)이 UE(602) 상에 존재하는 것에 바인딩되어 있지 않다. 예를 들어, 구성요소[예컨대, 인증 요청자(622)]는, 무선 디바이스[예컨대, UE(602)] 상의 완전 SSO 서브시스템(600) 특징들을 사용하여 또는 사용하는 일 없이 그 구성요소가 사용될 수 있다는 점에서, 독립적일 수 있다. 인증 요청자(622)의 예시적인 특징들을 기술하기 위해, 도 6은 인증 요청자(622)를 SSO 서브시스템과 별도의 구성요소로서 예시하고 있지만, 인증 요청자는 SSO 서브시스템(600) 내에 포함되어 있을 수 있다. 그에 부가하여, 본 명세서에 기술되어 있는 실시예들은 SSO 서브시스템의 서브셋을 갖거나 갖지 않는 인증 요청자의 변형들을 포함할 수 있다.

한 예시적인 실시예에서, 인증 요청자(622)는 자바 애플릿 등으로 구현될 수 있다. 예를 들어, 자바 애플릿은 인증 프로세스 동안 다운로드될 수 있고, 브라우저[또는 애플리케이션(604)]와 UE(602)에 있는 네트워크-보조 인증 모듈들[예컨대, GBA 모듈(612), AKA 모듈(614), EAP SIM 모듈(616), SIP 다이제스트 모듈(618), 로컬 OP 모듈(620)] 사이에 계층을 생성할 수 있다. 이러한 계층은, 예를 들어, 인증 모듈들을 갖는 네트워크 인증 인터페이스를 가능하게 하는 소프트웨어 계층일 수 있는데, 그 이유는 기본 브라우저(native browser)가 어떤 인증 메커니즘들을 지원하지 않을 수 있기 때문이다.

인증 요청자(622)(예컨대, 자바 애플릿)는, 일단 다운로드되면, 실행될 수 있고 HTTP 요청을 발행 및/또는 처리할 수 있다는 점에서, 브라우저로부터 독립적일 수 있다. 예를 들어, 자바 애플릿은 인증 신청(authentication challenge)을 검색하라는 요청을 OP(608)에 대해 발행할 수 있다. 자바 애플릿은 인증 모듈들[예컨대, GBA 모듈(612), AKA 모듈(614), EAP SIM 모듈(616), SIP 다이제스트 모듈(618), LAE 모듈]과는 물론 SSO 서브시스템(600)과도 인터페이스할 수 있다. 예를 들어, UE(602)는 인증 모듈들에 대한 액세스가 SSO 서브시스템(600)을 통해 이용가능하게 될 수 있는 계층별 액세스(layered access)를 제공할 수 있다. SSO 서브시스템(600)과 인증 모듈들 사이의 네트워크 인증 인터페이스는 인증을 용이하게 해주기 위해 사용될 수 있다. 예를 들어, 자바 애플릿은 ID 제공자[예컨대, OP(608)]로부터의 신청을 네트워크-보조 인증 모듈로 전송할 수 있고, 인증 모듈은 다이제스트 응답(digest response)을 계산할 수 있으며, 자바 애플릿은 그 응답을 직접 OP(608)로 또는 브라우저를 통해 OP(608)로 전송할 수 있다.

도 6에 예시된 바와 같이, LAE[예컨대, 로컬 OP(620)]는 [예컨대, SSO 서브시스템(600)에 의해] 다른 인증 모듈로 보일 수 있지만, LAE(620)는 인증 이외의 기능들을 수행할 수 있다. LAE에 대한 자바 애플릿의 역할은 인증 모듈에 대한 자바 애플릿의 역할과 상이할 수 있는데, 그 이유는, 예를 들어, LAE가 순수한 인증 방법보다 더 많은 기능들을 포함할 수 있기 때문이다. 예를 들어, LAE는 인증 응답을 계산하지 않을 수 있고, 능동적으로 인증을 수행할 수 있다. 그 결과, LAE는 검증을 위해 서비스 제공자[웹 서비스(606)(예컨대, RP) 등]로 직접 전송될 수 있는 어써션 메시지를 생성할 수 있다. LAE와 관련하여, 인증 요청자(622)(예컨대, 자바 애플릿)는 애플리케이션(604)(예컨대, 브라우저)으로부터 LAE로의 통신을 가능하게 해줄 수 있다. 한 예시적인 실시예에 따르면, SSO 서브시스템(600)은 SIMAlliance에 의해 표준화되어 있는 OpenMobile API 등의 소프트웨어 미들웨어 구성요소를 포함하고 그를 기반으로 할 수 있다. 이러한 소프트웨어 미들웨어 구성요소는, 예를 들어, 사용자/OS 레벨 애플리케이션으로부터 SIM 카드 애플리케이션으로의 통신을 용이하게 해줄 수 있다.

도 6에 도시되어 있는 예시적인 아키텍처를 여전히 참조하면, 인증 요청자(622)(예컨대, 서명된 자바 애플릿)는 브라우저를 통해 다운로드될 수 있고, 각각의 디바이스[예컨대, UE(602)] 유형에 대해 커스터마이즈될 수 있다. 인증 요청자는, 예를 들어, Symbian, iOS, Android 등과 같은다양한 디바이스 유형에 대해 커스터마이즈될 수 있다. 인증 요청자(622)는 브라우저로부터 SSO 서브시스템(622)의 구성요소들[예를 들어, GBA 모듈(612), AKA 애플리케이션(614), 및 SIP 다이제스트 인증자(618) 등]로의 통신을 가능하게 해줄 수 있다. 인증 요청자(622)는 ID 제공자의 서버[예컨대, OP 서버(608)] 및/또는 웹 서비스(606)(예컨대, RP)에 의해 제공될 수 있다. 인증 요청자(622)는 자동화된 및/또는 매끄러운 사용자 인증을 수행하는 데 사용되는 인터페이스 기능들을 제공할 수 있다. 한 예시적인 실시예에서, SSO 서브시스템(600)은 애플리케이션(604)(예컨대, 브라우저)이 네트워크-보조 인증 모듈들(612, 614, 616, 618, 및 620)과 통신할 수 있게 해줄 수 있다. 예를 들어, 인증 요청자(622)는 애플리케이션(604)(예컨대, 브라우저)이 SSO 서브시스템(600)의 특징들을 사용할 수 있게 해줄 수 있다. 예를 들어, LAE가 UE(602) 상에서 이용가능한 경우, 인증 요청자(622)는 LAE(620)를 발견하는 데 그리고 LAE에 연결하는 데 도움을 줄 수 있다. 인증 요청자(622)는 사용자를 ID 제공자의 원격 변형례[예컨대, LAE 또는 원격 OP(608)]로 그리고 다시 웹 서비스(606)(예컨대, RP)로 리디렉션할 수 있다. 인증 요청자(622)는 SSO 서브시스템(600)을 인증 모듈로서 사용하는 것을 가능하게 해줄 수 있고, 예를 들어, 서명된 어써션을 직접 발생하기 위해, SSO 서브시스템(600)의 LAE 부분[예컨대, 로컬 OP(620)]을 사용하는 것을 가능하게 해줄 수 있다. SSO 서브시스템(600)은 모바일 디바이스[예컨대, UE(602)]에 사전 로드되어 있을 수 있고 및/또는 다른 메커니즘들을 통해 디바이스에 다운로드될 수 있다. 한 예시적인 실시예에서, SSO 서브시스템(600)은 서비스들에 걸쳐 영속적일 수 있는 반면, 인증 요청자(622)는 사용자가 웹 서비스(606)(예컨대, RP)르르 방문할 때마다 재로드될 수 있다.

일 실시예에서, 도 6의 인증 요청자(622) 등의 인증 요청자는 자바 애플릿 등으로서 구현될 수 있고, 제한된 운영 환경(예컨대, 'Sandbox')에서 실행될 수 있다. 이러한 인증 요청자는 시스템 자원들에 대한 제한된 액세스를 가질 수 있다. 한 예시적인 실시예에서, 인증이 수행된 후에(예컨대, 브라우저가 서비스 웹 사이트를 빠져나올 때), 인증 요청자는 언로드될 수 있다. 도 7을 참조하면, SSO(single-sign-on) 특징이 상이한 서비스들 사이의 사용자 인증들에 걸쳐 있을 수 있기 때문에, SSO 기능의 영속적 측면은 SSO 서브시스템(700)의 비인증 요청자 부분(non-supplicant part)에 의해 제공될 수 있다. 도 7은 SSO 서브시스템(700)의 예시적인 인터페이스 구성요소들을 갖는 도 6의 아키텍처 프레임워크의 한 예시적인 실시예를 나타낸 것이다. 도 7에 도시된 바와 같이, SSO 서브시스템은 인증 요청자를 포함할 수 있고, SSO 서브시스템(700)은, 예를 들어, 사용자(704), 원격 서버(708), 생체 인식 유닛(710), 및 다양한 다른 디바이스들(706) 등의 다양한 구성요소들과 인터페이스할 수 있다. SSO 서브시스템(700)의 인증 요청자 단편의 연동 기능이 이하에 예로서 기술되어 있다.

여전히 도 7을 참조하면, 인증 요청자는 일반적으로 인증 함수에 직접 액세스하지 않을 수 있거나, LAE[예컨대, 로컬 OP(620)]에 의해 제공되는 인증 함수들에 액세스할 수 있다. 이러한 경우에, 네트워크-보조 인증 방법들을 사용하는 어떤 인증 요청들은 SSO 서브시스템(700)을 통해 호출될 수 있다. 이러한 호출은 SSO 서브시스템(700)에 대한 인증 요청자의 적절한 허가 및/또는 (예컨대, 코드 서명의 검사에 의한) 이전의 유효성 확인을 포함할 수 있다. 인증 요청자는 다양한 인터페이스를 제공할 수 있다. 예를 들어, 인증 요청자는 특정의 서비스 제공자(예컨대, RP)에 의해 사용될 식별자를 선택하는 인터페이스를 SSO 서브시스템(700)에 제공함으로써 인증 프로세스의 자동화를 가능하게 하는 기능을 제공할 수 있다. 인증 요청자는 ID 제공자[예컨대, OP(608)]에 대한 인증을 위해 크리덴셜을 제공하는 인터페이스를 SSO 서브시스템(700)에 제공할 수 있다. 인증 요청자는 또한 네트워크-보조 인증 모듈 또는 메커니즘의 선택 및/또는 협상을 위한 인터페이스(예컨대, 네트워크 인증 인터페이스)를 SSO 서브시스템(700)에 제공할 수 있다. 하나의 예시적인 실시예에서, 인증 요청자는, 예를 들어, 인증을 위한 웹 서비스(606)(예컨대, RP)로부터 ID 제공자[예컨대, OP(608)]로의 리디렉션 메시지 및 인증 후의 웹 서버(606)로부터 OP(608)로의 리디렉션 메시지 등의 리디렉션 메시지를 대체하는 기능들을 제공할 수 있다.

앞서 기술된 바와 같이, SSO 서브시스템(700)은 사용자-보조 인증을 위한 사용자 인증 인터페이스[예컨대, 도 6에서의 사용자 인터페이스(624)]를 제공할 수 있고, 이 인터페이스를 통해 사용자-보조 인증을 수행할 수 있다. 사용자 인증 인터페이스는, 예를 들어, OP(608)에 의해 OP 인증 요청자 기능의 일부로서 제공될 수 있거나, SSO 서브시스템(700)의 영속적 기능의 일부일 수 있다. SSO 서브시스템(700)은 사용자-보조 인증 정책들에 관한 정보를 수집하기 위해 ID 제공자[예컨대, OP(608)]와 인터페이스(예컨대, 통신)할 수 있다. 정책들에 관한 이러한 정보는, 예를 들어, ID 제공자 또는 서비스 제공자에 의해 요구되는 신선성(예컨대, 인증이 수행되었을 때) 및 인증 강도 레벨(예컨대, 생체 인식 또는 사용자 이름/비밀 번호) 등의 사용자-보조 인증 파라미터들을 포함할 수 있다. SSO 서브시스템은 또한 네트워크-보조 인증 모듈 및/또는 인터페이스의 선택을 용이하게 해주기 위해 OP(608)와 인터페이스할 수 있다. 사용자 인터페이스를 통해 및/또는 선택된 네트워크-보조 인증 방법[예컨대, GBA 모듈(612), AKA 모듈(614), EAP SIM(616), SIP 다이제스트(618)]을 사용하여 사용자(704) 및/또는 사용자 장비(UE)(602)를 성공적으로 인증한 후에, SSO 서브시스템(700)은 어떤 기간(예컨대, 유효성 기간) 동안 사용자 인증의 영속적 상태를 설정할 수 있다. (예컨대, 로컬 트리거에 의한 또는 네트워크에 의한) 재인증 요청을 수신할 시에, SSO 서브시스템(700)은 사용자(704)를 재인증할 수 있다. 한 예시적인 실시예에서, 이러한 재인증은 매끄러운 로그온 경험을 사용자(704)에게 제공할 수 있다.

SSO 서브시스템(700)은, 예를 들어, 무선 인터페이스를 통해 UE(602)에 연결된 토큰으로부터 인증 정보를 획득하기 위해, UE(602)의 외부에 있는 구성요소들[예컨대, 다른 디바이스(706)]로의 인터페이스를 사용할 수 있다. SSO 서브시스템(700)은 인증을 위해 생체 인식 유닛(710)으로의 또는 원격 서버(708)로의 보조 통신 채널을 설정할 수 있다.

도 8은 인증 요청자(예컨대, 자바 애플릿)의 다운로드를 트리거하는 인증 흐름을 나타낸 흐름도이다. 도 8에 예시되어 있는 예시적인 흐름은 본 명세서에 기술되어 있는 SSO 프레임워크 아키텍처 내에서 구현될 수 있다. 도면들에서의 예시적인 실시예들이 OpenID 용어를 사용하여 기술되어 있지만, 예시적인 흐름들은, 예를 들어, Liberty Alliance 등의 임의의 수의 SSO(single sign-on) 보안 프로토콜에 적용될 수 있다.

도 8을 참조하면, 808에서, UE(802)는 사용자의 OP 로그온 요청을 RP(804)로 전송할 수 있다. 로그온 요청은 사용자-제공 식별자를 포함할 수 있고, RP(804)로 전달될 수 있으며, RP(804)는, 810에서, RP(804)와 OP(806) 간의 공유 비밀 키의 연관 및/또는 설정을 트리거할 수 있다. 810 후에, 네트워크-보조 인증이 수행될 수 있다. 예를 들어, 네트워크-보조 인증이 RP(804)에 의한 OP(806)로의 리디렉션 이후에 행해질 수 있다. 단계(812)에서, UE(802)에 의해 리디렉션이 수신될 수 있다. 814에서, UE는 인증 요청자를 사용하여 인증하라는 요청을 OP(806)로 전송할 수 있다. 이 요청은, 예를 들어, 넌-브라우저 애플리케이션의 ID(identity) 또는 UE(802)에 의해 사용되는 브라우저 에이전트의 ID 등의 애플리케이션의 ID를 포함할 수 있다. 한 예시적인 실시예에서, 자바 애플릿은 요청에서의 브라우저 에이전트의 유형에 따라 정합될 수 있다. 예를 들어, 다수의 및/또는 상이한 자바 애플릿들이 다수의 디바이스들에 대해 사용될 수 있고, 따라서 UE(802)의 다양한 구성요소들(예를 들어, 프로세서, OS 및/또는 브라우저 등)에 따라 자바 애플릿이 선택될 수 있다. 이 요청에 응답하여, 816에서, UE(802)는 인증 요청자(820)(예컨대, 자바 애플릿)를 OP(806)로부터 다운로드할 수 있다.

자바 애플릿은 OP(806)에 의해 서명될 수 있다. 자바 애플릿에 대한 발행자 인증서는, 예를 들어, UE 시스템 인증서 저장소(UE system certificate store)를 사용하여 브라우저에 의해 검사될 수 있다. 예를 들어, 수정된 시스템 또는 브라우저 인증서 저장소 구현은 UE(802)의 보안 요소(예컨대, UICC) 상에 저장되어 있는 인증서/키를 사용하여 자바 애플릿 서명을 검사할 수 있다. 자바 애플릿은 RP(804)에 대해 어느 네트워크-보조 인증 모듈(800)을 사용할지를 결정하는 논리를 포함할 수 있다. 자바 애플릿은 또한 UE(802)에서 어느 인증 모듈/메커니즘이 이용가능한지를 OP(806)에 알려주는 논리를 포함할 수 있다. 한 예시적인 실시예에서, 자바 애플릿은 하나의 단일 인증 모듈(800)에 특유할 수 있고, OP(806)는 어느 자바 애플릿을 UE(802)에 제공할지를 선택할 수 있다. 한 예시적인 실시예에서, 814에서, HTTP 요청이 전송된다. HTTP 요청은, UE(802)의 OS가 식별될 수 있게 해주고 대응하는 애플릿 버전이 OP(806)에 의해 선택되어 (816에서) UE(802)로 전송될 수 있게 해주는, 브라우저 에이전트를 포함할 수 있다.

818에서, 네트워크-보조 인증이 수행될 수 있다. 도 3과 관련하여 본 명세서에 기술되어 있는 바와 같이, 네트워크-보조 인증이 RP(804)에 의한 OP(806)로의 리디렉션 이후에 행해질 수 있다. 리디렉션이 인증 요청자(820)에 의해 수신될 수 있고, 인증 요청자(820)는, 네트워크-보조 인증 모듈 및/또는 프로토콜[예컨대, 인증 모듈(800)]의 선택을 위해, 메시지를 SSO 서브시스템(308)으로 리디렉션할 수 있다. 네트워크-보조 인증 모듈/프로토콜(예컨대, SSO 프로토콜)이 정책 구현을 통해 SSO 서브시스템에 의해 선택되고 사용될 수 있다. 이 프로세스는, 본 명세서에 추가로 기술되어 있는 바와 같이, 부트스트랩핑 및 공유 키 설정을 포함할 수 있다.

도 2, 도 4, 도 6 및 도 7에 도시된 바와 같이, 몇가지 네트워크-보조 인증 프로토콜 모듈들이 네트워크-보조 인증 모듈들(예컨대, SSO 프로토콜들)의 모음에 의해 암시될 수 있다. 다시 도 8을 참조하면, 822에서, 818에서의 인증으로부터의 인증 결과가 인증 요청자(820)로부터 OP(806)로 전송될 수 있다. 예를 들어, 인증 결과는 UE(802)와 OP(806) 간에 공유되는 애플리케이션 관련 키 등을 포함할 수 있다. 성공적인 네트워크-보조 인증 후에, OP(806)는 네트워크-보조 인증이 성공적이었다는 표시를 RP(804)에 제공할 수 있다. 예를 들어, OP(806)는, 824에서, ID 어써션에 서명하고, 824에서, 어써션 메시지를 전송할 수 있다. UE(802)가 RP(804)에서의 원하는 서비스에 액세스하기 전에, 성공적인 네트워크-보조 인증의 서명된 통지가 수행될 수 있다. RP(804) 및/또는 UE(802)가 [예컨대, 애플리케이션을 통해] 네트워크-보조 인증이 성공적이었다는 표시를 수신하면, UE(802)는 (예컨대, 애플리케이션을 통해) (826에서) RP(804)에 로그온할 수 있고, (828에서) RP(804)에서의 서비스에 액세스할 수 있다.

도 9는 ID 제공자의 기능들이 UE(802)에 로컬적으로 수행되는 한 예시적인 실시예를 나타낸 것이다. 예를 들어, UE(802)는 SSO 서브시스템 및 LAE[예컨대, 로컬 OP(900)]를 포함할 수 있다. 단계들(808, 810, 814, 및 816)이 도 8과 관련하여 기술된 바와 같이 진행될 수 있다. 902 및 904에서, 인증 요청자(908)와 SSO 서브시스템(900) 간의 상호작용을 통해 그리고 SSO 서브시스템(900)과 하나 이상의 인증 모듈들(800) 간의 상호작용을 통해, 서명된 어써션이 생성될 수 있다. 906에서, UE(802)는 서명된 어써션을 RP(804)로 전송할 수 있다. RP가 서명된 어써션을 수신한 후에, UE(802)의 사용자는 (824에서) RP(804)에 의해 제공된 서비스에 액세스할 수 있다. 도 10은 SSO 서브시스템이 자바 애플릿(1002)으로 구현되는 한 예시적인 실시예를 나타낸 것이다. 도 10을 참조하면, SSO 서브시스템(1002)은 UICC(1000) 상의 로컬 OP 암호를 사용하여 네트워크-보조 인증을 수행할 수 있다. 성공적인 네트워크-보조 인증 후에, 서명된 어써션이 생성되고 RP(804)로 리디렉션될 수 있다.

본 명세서(예컨대, 도 11 내지 도 15)에 기술되어 있는 바와 같이, LAE(예컨대, 로컬 OP)가 자바 애플릿에 통합되어 있을 수 있거나, 자바 애플릿으로부터 분리되어 있을 수 있다. 대안의 예시적인 실시예에서, 예를 들어, OpenID 프로토콜은 로컬 OP 구성요소 없이 구현될 수 있다. 이러한 실시예에서, 프로토콜 흐름의 제1 부분은 LAE를 가지는 일 실시예와 동일하거나 유사하게 보일 수 있지만, 인증 및/또는 어써션 발생은 UE와 OP 간의 통신(예컨대, 도 16에 도시되어 있음)에 의해 행해질 수 있다.

도 11은 연관을 프리페칭하는 프로토콜 흐름의 한 예시적인 실시예를 나타낸 것이다. 예를 들어, 연관들이 프리페칭될 수 있고, 이는 사용자로부터의 인증 시도 이전에 RP가 연관들(예컨대, 연관 핸들 및/또는 연관 비밀)을 검색할 수 있게 해줄 수 있다. 이것은, 예를 들어, OpenID의 식별자 선택 모드(identifier select mode)를 사용하여 구현될 수 있다. RP는 전체 OpenID 식별자 URL을 알고 있을 필요는 없지만, 어떤 알고 있는 OP에 대한 연관들을, 예를 들어, 그의 OP 종단점 URL에 기초하여, 프리페칭할 수 있다. 도 11을 참조하면, UE(802)의 식별자를 알기 전에, 810에서, RP(804)는 연관들을 얻을 수 있다. 812에서, RP(804)는, 예를 들어, 프리페칭된 연관들 중 하나를 사용하여 UE(802)를 OP(806)로 직접 리디렉션할 수 있다. 이러한 실시예에서, UE(802)는 자바 애플릿(1100)을 OP(806)로부터 다운로드할 수 있고, 이는 UE(802)와 OP(806) 사이의 인터페이스를 통한 트래픽을 생성할 수 있다. 한 예시적인 실시예에서, UE(802)와 OP(806) 간의 인터페이스는 공중 인터페이스일 수 있는 반면, RP(804)와 OP(806) 사이의 인터페이스는 고정된 인터넷일 수 있다.

프리페치 단계의 한 예시적인 실시예에서, 도 12에 예시되어 있는 바와 같이, 자바 애플릿이 RP에 의해 저장될 수 있다. RP(804)는 OP(806)에 의해 서명되어 있는 한 세트의 자바 애플릿(1202)을 수신할 수 있다. RP(804)는 810으로부터의 연관들과 함께 자바 애플릿(1202)을 저장할 수 있다. UE(802)가, 예를 들어, 1204에서, 인증을 하고자 할 때, 1206에서, RP(804)는 대응하는 자바 애플릿(1202)을 UE(802)에 제공할 수 있다. 다수의 및/또는 상이한 자바 애플릿들은, 예를 들어, 넌-브라우저 애플리케이션 또는 브라우저 에이전트의 프로세서 및 OS와 일치하도록, 상이한 디바이스들에 대해 사용될 수 있다.

예시적인 실시예에 따르면, 예를 들어, OpenID 라이브러리가 OP로 아웃소싱될 수 있다. 예를 들어, OP는 RP에 대한 OpenID 관련 동작들을 처리하는 API를 RP에 제공할 수 있다. Google Identity Toolkit은, UE 상에 RP의 기능을 일반화할 있고 동일한 인증 요청자를 사용할 수 있는 다수의 RP들에 대한 공통의 프레임워크를 제공할 수 있는 한 예시적인 구현이다. RP는 OpenID 인증을 개시하라고 API에 요청할 수 있고, (OP에 의해 제공/호스팅되는) API는 UE 인증을 개시하기 위해 RP로부터 UE로 전송될 코드를 반환할 수 있다. 그 후에, UE 결과가 다시 RP로 전송될 수 있고, RP는 (예컨대, 자체적으로 또는 OP의 도움을 받아) 인증 결과를 검증할 수 있다. 한 예시적인 실시예에서, 연관들의 프리페칭은 UE와 OP 간의 통신을 절감(감소)할 수 있고, 오프라인 시나리오를 가능하게 해줄 수 있다.

도 13은 캐싱된 자바 애플릿에 대한 프로토콜 흐름의 다른 실시예를 나타낸 것이다. 예를 들어, 자바 애플릿(1306) 등은 스마트 폰 등의 UE(802) 상에 저장될 수 있다. 한 예시적인 실시예에서, 자바 애플릿(1306)은 이전의 실행으로부터 UE(802)의 브라우저 캐시에 저장될 수 있다. 이러한 실시예에서, 저장된 자바 애플릿이 호출될 수 있다. 예를 들어, 애플릿이 브라우저 캐시에 없는 것으로 추정되는 경우, 브라우저는 예고 없이 다운로드된 자바 애플릿을 삭제할 수 있다. 예를 들어, 애플릿이 동일한 발신지(예컨대, 동일한 RP)로부터 호출될 때, 이전에 다운로드된 자바 애플릿이 호출될 수 있다. OP에 의해 제공된 API는, 1300에서, 이전에 다운로드된(그리고 캐싱된) 자바 애플릿에 대한 호출을 발행하는 코드를 반환할 수 있다. 1302에서, 예를 들어, 자바 애플릿(1306)에 대한 호출은 RP(804)에 제공된다. 1304에서, 이 호출은 UE(802)에 제공된다. 본 명세서에 기술되어 있는 실시예들은 자바 스크립트(JavaScript) 등의 대안의 구현들을 사용할 수 있다.

도 14는 자바 애플릿이 실시간으로(on the fly) 프로비저닝되는 한 예시적인 실시예를 나타낸 것이다. 예시적인 실시예에 따르면, 브라우저는 자바 애플릿을 캐시에 저장하지 않을 수 있다. 이러한 실시예에서, 애플릿(1402)은 (1400에서) OP(806)에 의해 RP(804)에 제공될 수 있고, 1404에서, RP(804)는 이를 UE(802)로 전달할 수 있다. HTTP 요청이 브라우저 에이전트를 포함할 수 있기 때문에, UE(802)의 OS가 식별될 수 있고, 대응하는 애플릿 버전이 UE(802)로 전송될 수 있다. 여기서, RP(804)는, 예를 들어, OP(806)가 올바른 자바 애플릿 버전을 선택하도록, API 호출(1300)에서 UE 스트링(예컨대, OS 및/또는 브라우저 에이전트를 포함함)을 계속 OP(806)로 전달할 수 있다.

본 명세서에 기술된 바와 같이, 다양한 실시예들은 브라우저 애플리케이션을 사용하여 서비스에 액세스하기 위해 OpenID 등을 사용할 수 있다. OpenID는 HTTP 프로토콜에 기초할 수 있고 및/또는 자바 애플릿은 자바 런타임(Java Runtime)을 구현할 수 있다. 한 예시적인 실시예에서, 브라우저는 HTTP 프로토콜 및 자바 런타임 환경 둘 다를 사용할 수 있다. OpenID 및/또는 본 명세서에서 제시된 다른 개념들을 사용하는 것은 브라우저 애플리케이션으로 제한되지 않는다. 본 명세서에 기술된 바와 같이, 다양한 실시예들은 OpenID 프로토콜 등을 구현하기 위해 넌-브라우저 애플리케이션을 사용할 수 있다. 그 애플리케이션들에 대해, 동일한 개념이 적용될 수 있다. 넌-브라우저 애플리케이션에 대한 실시예들은 자바 애플릿의 다운로드 및 실행을 지원하기 위한 인터페이스 및/또는 방법을 제공할 수 있다. 본 명세서에서의 설명이 다양한 프로토콜 흐름들의 설명을 위해 브라우저라는 용어를 사용할 수 있지만, 흐름들이 그것으로 제한되지 않으며 넌-브라우저 애플리케이션을 포함할 수 있다.

다양한 실시예들이 자바 애플릿을 구현하는 것으로 기술되어 있지만, 이러한 실시예들은 그것으로 제한되지 않는다. 본 명세서에 기술되어 있는 자바 애플릿은 서비스 액세스 애플리케이션(예컨대, 브라우저/넌-브라우저)과 인증 모듈(예컨대, OP, 로컬 OP, GBA, AKA) 간의 디바이스 내부에서의 인증 통신을 용이하게 해줄 수 있는 구성요소(예컨대, 인증 요청자)의 다운로드에 대한 하나의 구현 변형을 나타낸다. 예를 들어, 본 명세서에 기술되어 있는 실시예들은 대역외에서(out of band) 로드되거나 동적으로 무선 디바이스에 다운로드될 수 있는 라이브러리 또는 API 등의 구성요소에 의해 구현될 수 있다. 다운로드된 구성요소(예컨대, 애플릿, 라이브러리)는, 애플리케이션이 구성요소를 어떻게 처리할지(예컨대, 어떻게 로드할지, 어느 함수를 호출할지)를 알고 있을 수 있다는 점에서, 애플리케이션에 특유할 수 있다.

Google Identity Toolkit(GITkit)은 RP 기능의 통합 및/또는 구현을 쉽게 해줄 수 있는 몇가지 기능 및 특징을 제공할 수 있다. 네트워크 측에서, 예를 들어, 네트워크 측 인증 요청자 기능 롤아웃 특징들을 포함시킴으로써, 서비스 제공자가 OpenID 연합 ID 프로토콜(OpenID federated identity protocol)을 채택하는 것을 쉽게 해주기 위해 RP 기능이 추가로 향상될 수 있다. 클라이언트 측에서, 예를 들어, 사용자 자동화를 수행하기 위해 긁기(scraping)를 사용하는 실시예들과 같이, 자바 스크립트는 인증 요청자 기능들을 일반화하고 이들을 GITkit에 맞춰 정렬하는 데 사용되는 요소들 중 일부를 제공할 수 있다.

본 명세서에 기술되어 있는 다양한 실시예들은, GITkit의 사용자에 의해 제공되는 보통의 호출 흐름에 부합한 채로 있으면서, LAE(예컨대, 로컬 OP)의 개념을 Google Identity Toolkit과 통합할 수 있다. 예를 들어, 로컬 OP가 호출될 수 있고 브라우저가 로컬 OP로 리디렉션될 수 있는 몇가지 상이한 방식들이 본 명세서에 기술되어 있다. 한 예시적인 실시예에서, 리디렉션이 OP의 URL에 적용될 수 있고, 여기서 디바이스는 어디에서 로컬 OP에 도달하는지를 알고자 할 수 있따. 다른 예시적인 실시예에서, GITkit API에 의해 제공된 웹 사이트는 (예컨대, 자바 스크립트를 통해) 호출을 OS API에 제공할 수 있고, OS API는, 예를 들어, 브라우저를 로컬 OP로 리디렉션하는 일 없이, 로컬 OP 인증 프로세스를 트리거할 수 있다. 또 다른 예시적인 실시예에서, OS API 대신에, 브라우저 플러그인(browser plugin)이 호출될 수 있다.

도 15는 GITkit(1500)이 로컬 OP(900) 및 자바 애플릿(1508)과 통합되어 있을 수 있는 한 예시적인 실시예를 나타낸 것이다. 예시적인 통합 단계들이 이하에 열거되어 있지만, 예를 들어, 넌-브라우저 애플리케이션을 충족시키는 것들을 비롯한 다른 구현들이 사용될 수 있기 때문에, 본 명세서에 기술되어 있는 실시예들은 그것으로 제한되지 않는다.

도 15를 참조하면, 사용자는 RP(804)를 방문하고 및/또는 그의 IdP를 선택하거나 그의 이메일 주소 식별자를 입력할 수 있다. 하나의 예시적인 실시예에서, 이 식별자는, 예를 들어, 인증 프로세스의 자동화를 제공하기 위해 (예컨대, 브라우저 저장 폼 데이터 또는 쿠키 등의 기존의 기술을 사용하여) 미리 채워져 있을 수 있고, 사용자가 URL을 브라우저에 입력하는 것에 의해 트리거될 수 있다. GITkit 라이브러리 함수 "createAuthUrl"이 호출될 수 있다. GITkit 라이브러리는 IdP 발견을 수행할 수 있다. GITkit는 IdP의 허가 종단점 URL[예컨대, OP(806)의 URL]을 반환할 수 있다. 자바 스크립트 위젯은 사용자를 그 종단점으로 리디렉션시키는 로그인 창을 팝업시킬 수 있다. 그 팝업 창에서의 리디렉션은 사용자를 디바이스 상에서 실행 중인 로컬 OP 인스턴스로 데리고 갈 수 있다. 로컬 OP 인스턴스는, 로컬 OP의 암호 함수들이 실행되는 SIM 카드 또는 다른 보안 요소에 대한 인터페이스를 통합하면서, 예를 들어, 브라우저 쪽에 HTTP 인터페이스 및 웹 서버와 유사한 기능들을 제공하는 애플리케이션으로 이루어져 있을 수 있다. 대안의 실시예에서, 자바 스크립트는 리디렉션을 사용하지 않을 수 있고, 스크립트로부터 직접 로컬 OP 인증을 트리거하기 위해 (1502에서) OS API를 호출할 수 있다. 예를 들어, 로컬 OP 애플리케이션이 SIM 카드 상에 존재하는 경우, 자바 스크립트는 어쩌면 스마트 카드 상의 로컬 OP 애플리케이션과 직접 통신하기 위해 OS API(예컨대, Simalliance OpenMobile API)를 호출할 수 있다. 다른 실시예들은 순수 자바 스크립트 해결 방안을 사용하지 않을 수 있다. 이들 실시예에서, 브라우저는 로컬 OP 인증을 트리거하기 위해 자바 스크립트에 의해 호출될 수 있는 플러그인을 포함할 수 있다. 이 플러그인은, 예를 들어, OS 애플리케이션 계층 및/또는 보안 요소 상의 로컬 OP 애플리케이션 간의 통신을 위한 송신 계층 논리를 제공할 수 있는 어떤 OS API를 사용할 수 있다. 다른 실시예에서, GITkit API는, 첫번째 호출 후에, 자바 애플릿을 UE로 다운로드하는 것을 가능하게 해줄 수 있는 코드를 RP에 제공할 수 있다. 자바 애플릿은 본 명세서에 기술되어 있는 바와 같이 로컬 OP을 사용하여 인증을 수행할 수 있다. 실시예들은 UE가 로컬 OP로의 리디렉션을 수신하는 것에 의해 트리거되는 인증 프로세스의 자동화를 제공하기 위해 (예컨대, 브라우저 저장 폼 데이터 또는 쿠키 등과 같은 기존의 기술을 사용하여) 크리덴셜을 미리 채울 수 있다.

1102에서, 사용자는 로컬 OP에 로컬적으로 인증될 수 있다. 로컬 OP는 네트워크에 있는 OP(SF)와의 장기 공유 비밀로부터 OpenID 서명 비밀을 도출할 수 있고, OpenID에 대한 서명 키를 생성하기 위해 키 도출 함수에의 제2 입력으로서 연관 핸들을 사용할 수 있다. 로컬 OP/자바 스크립트/플러그인은 서명된 어써션 메시지를 생성할 수 있고, 브라우저를 RP에 있는 이전에 생성된 "continueURL"("createAuthUrl" GITkit 라이브러리 호출에 의해 생성되었을 수 있음)로 리디렉션할 수 있다. RP는 (906에서) 서명된 어써션 메시지를 수신할 수 있고, 1510에서, 검증을 위해 이를 GITkit 라이브러리로 전달할 수 있다. 1512에서, GITkit(1500)은 OP(SF)로 어써션 메시지를 유효성 확인하기 위해 "verifyAssertion" API를 사용할 수 있다. GITkit 라이브러리가 Google에 의해 호스팅되고 있을 수 있기 때문에, GITkit 라이브러리는 서명 검증을 위해 OPSF를 사용할 수 있다. OPSF는 ID 정보(identity information)(이메일, 또는, 예를 들어, OpenID의 속성 교환 방법에 의해 정의되는 바와 같은 다른 속성들 등)를 반환할 수 있다. 그 계정/이메일이 이미 존재하는 경우, 사용자는 로그인되어 있을 수 있다. 그렇지 않은 경우, RP는 어써트된 이메일 주소를 사용자에 대한 변경할 수 없는 식별자로서 사용하여 새로운 계정을 생성할 수 있다. 속성 교환 메커니즘에 의해 수신된 정보에 기초하여, 부가의 속성들이 자동으로 채워질 수 있다.

부가의 배경 지식으로서, GITkit 프로토콜 흐름의 개요는 http://code.google.com/intl/de-DE/apis/identitytoolkit/vl/openid.html에서 찾아볼 수 있다. 보통의 GITkit 프로토콜 흐름은 다음과 같이 요약될 수 있다.

사용자는 RP 웹 사이트를 방문할 수 있고, 그의 IdP의 버튼을 클릭할 수 있다. RP는 GITkit 서비스 API에 대한 호출을 빌드할 수 있고, 이는 차례로 발견 단계들을 수행하고 콜백 URL을 반환할 수 있으며, RP는 사용자의 복귀를 기다리기 위해 이 콜백 URL을 설정해야만 할지도 모르고 GITkit는 IdP에 대해 인증하기 위해 사용자에게 디스플레이되어야 하는 HTML 코드를 반환한다. 이 HTML 코드는 IdP의 인증 URL로의 리디렉션을 포함하고 있을 수 있다. 이 코드는 또한 RP들에 대해 동일한 사용자 인터페이스를 생성할 수 있다. 사용자는 그의 IdP에 대해 인증을 한다. 사용자는 RP에서의 콜백 URL로 리디렉션될 수 있다. RP는 GITkit API(verifyAssertion)를 호출하기 위해 콜백 URL에서 수신된 파라미터(IdP 응답)를 사용할 수 있다. GITkit API는 IdP 응답을 검증할 수 있고, 결과(검증된 이메일 + 부가의 속성들)를 RP로 전송한다.

GITkit는, 이하에 예시되어 있는 바와 같이, RP가 2개의 단계에서 호출할 수 있는 적어도 2개의 API를 제공함으로써 OpenID/OAuth 프로토콜을 노출시킬 수 있다:

하나의 단계는 createAuthUrl API 호출을 포함할 수 있다. 예를 들어, 사용자가 IDP 아이콘을 클릭할 때 또는 이메일 주소를 직접 입력할 때, 이 API 호출이 행해질 수 있다. GITkit 백엔드는, 예를 들어, OpenID 2.0 프로토콜에 따라, IDP 발견을 수행할 수 있다. IDP가 실제로는 OAuth 프로토콜을 사용하는 경우, GITkit은 사전 정의된 IDP 종단점을 직접 사용할 수 있다. 최종 결과는 GITkit이 IDP의 허가 종단점을 나타낼 수 있는 URI(파라미터 "authUri")를 반환하는 것일 수 있고, GITkit 로그인 위젯은 그 종단점으로 리디렉션할 수 있는 로그인 창을 팝업할 수 있다. (이 단계는 보통의 OpenID 프로토콜의 첫번째 리디렉션에 대응할 수 있고, 여기서 브라우저는 OP로 리디렉션된다. 로컬 OP에 대해 이전과 동일한 메커니즘을 사용함으로써, 사용자의 브라우저는 이 스테이지에서 그 대신에 로컬 OP로 리디렉션될 수 있다.) createAuthUrl을 호출할 때, RP는 사용자가 대응하는 IDP에 의해 성공적으로 인증된 후에 리디렉션될 수 있는 URL인 "continueUrl"(즉, 콜백 URL)을 전달할 수 있다. "realm"은 OpenID의 영역(realm)을 식별해주는 선택적인 파라미터일 수 있는 반면, "identifier"는 어느 IDP를 사용할지를 지정할 수 있다.

다른 단계는 verifyAssertion을 포함할 수 있다. IDP가 사용자를 성공적으로 인증한 후에(이것은 로컬 OP가 사용되는 경우 로컬적으로 행해질 수 있는 실제의 사용자 인증을 말하는 것일 수 있음), IDP는 브라우저를 createAuthUrl의 "continueUrl" 파라미터에 지정되어 있는 URL로 리디렉션할 수 있고, 사용자의 ID 정보는 그의 비밀 키로 서명되어 있다. 일 실시예에 따르면, 이것은 처리되지 않을 수 있는 이진 블로브(binary blob)과 유사할 수 있고, 이는 다시 유효성 확인을 위해 GITkit로 전송될 수 있다. 이것은 OP로부터 RP로의 OpenID에서의 두번째 리디렉션일 수 있다. 이것은 로컬 OP에서 사용될 수 있다. 콜백 URL에 대한 HTTP 요청은 RP의 백엔드에서의 GITkit 클라이언트 라이브러리에 의해 포착될 수 있고, 클라이언트 라이브러리는 "requestUri"(IDP가 반환하는 URI) 및 "postBody"(IDP에 의한 서명된 블로브)로 GITkit의 verifyAssertion API를 호출할 수 있다. GITkit 백엔드는 OpenID 프로토콜을 사용하여 IDP 응답을 유효성 확인할 수 있고, ID 정보(또한, 예를 들어, AX가 사용되는 경우 그 ID와 연관되는 속성들)를 RP의 백엔드로 반환할 수 있다. 이 단계는 보통의 OpenID의 어써션 서명 검증에 대응할 수 있다. 이것은, 예를 들어, OpenID의 무상태 모드(stateless mode)와 유사할 수 있다. GITkit 라이브러리는 또 다시 서명을 검증하고 부가의 속성들(예컨대, 이메일 주소)을 요청하기 위해 (예컨대, 네트워크에 있는) OP와 접촉할 수 있다. RP는 "verifiedEmail" 필드를 검사하고 그에 따른 동작을 할 수 있다. 예를 들어, 그 이메일 주소를 갖는 계정이 유효한 경우, 사용자는 로그인되어 있을 수 있고, 및/또는 자바 스크립트 위젯은 로그인 창을 닫을 수 있고 및/또는 사용자의 브라우저를 RP의 홈 페이지로 리디렉션할 수 있다. 그 이메일에 대해 발견되는 계정이 없는 경우, RP는 사용자를, 예를 들어, 이메일 필드가 미리 채워져 있고 편집할 수 없으며 또한 계정에 대한 다른 속성들이 채워져 있는 계정 생성 페이지로 리디렉션할 수 있다.

OAuth 기반 IDP 인증의 경우, RP는 동일하거나 유사한 호출을 사용할 수 있고, 동일하거나 유사한 응답을 GITkit로부터 다시 얻을 수 있다. 그렇지만, GITkit은, IDP와 통신하고 올바른 처리(예를 들어, 액세스 토큰에 대한 교환 등)를 하기 위해, 그의 백엔드에서 OAuth 프로토콜을 사용할 수 있다. GITkit API 종단점은 GITkit API 호출에 대한 요청을 수신하고, (보통 API 키를 사용하여) 사용자를 인증하며, 올바른 파라미터로 GITkit 서버를 호출한다. GITkit 서버는 OpenID/OAuth 호출을 완료하기 위해 대응하는 IDP에 접촉할 수 있다.

본 명세서에 기술되어 있는 예시적인 실시예들이 OpenID와 관련하여 수행되고 있지만, 앞서 기술한 기법들이 Liberty Alliance 등의 임의의 수의 SSO(single sign-on) 보안 프로토콜들에 적용될 수 있다. 그에 부가하여, 다양한 실시예가 다양한 도면과 관련하여 기술되어 있지만, 본 발명을 벗어나지 않고 다양한 실시예의 동일한 기능을 수행하기 위해, 다른 유사한 실시예가 사용될 수 있거나 기술된 실시예에 대해 수정 및 추가가 행해질 수 있다는 것을 잘 알 것이다. 따라서, 실시예가 임의의 하나의 측면으로 제한되어서는 안되고, 오히려 첨부된 특허청구범위에 따라 범위 및 폭이 해석되어야 한다.

더욱이, 특징 및 요소가 특정의 조합으로 앞서 기술되어 있고, 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와 임의의 조합으로 사용될 수 있다. 본 명세서에 기술되어 있는 시스템들, 방법들 및 프로세스들 중 일부 또는 전부가 컴퓨터 판독가능 저장 매체 상에 저장되어 있는 컴퓨터 또는 프로세서 실행가능 명령어(즉, 프로그램 코드, 소프트웨어 및/또는 펌웨어)의 형태로 구현될 수 있고, 이 명령어는, 프로세서 등의 기계에 의해 실행될 때, 본 명세서에 기술되어 있는 시스템들, 방법들 및 프로세스들을 수행하고 및/또는 구현한다는 것을 잘 알 것이다. 구체적으로는, 앞서 기술한 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 실행가능 명령어의 형태로 구현될 수 있다. 컴퓨터 판독가능 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘 다를 포함한다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CDROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터 또는 프로세서에 의해 액세스될 수 있는 임의의 다른 매체를 포함하지만, 이들로 제한되지 않는다.

Claims

사용자 장비(user equipment, UE)에 있어서,
서비스에 액세스하기 위해 서비스 제공자와 통신하도록 구성되는 사용자 애플리케이션;
복수의 네트워크-보조 인증 모듈들 ― 각각의 네트워크-보조 인증 모듈은 상이한 네트워크-보조 인증 프로토콜에 대응하고, 상기 복수의 네트워크-보조 인증 모듈들 중 하나 이상은 상기 서비스에 액세스하기 위해 상기 서비스 제공자에 대해 네트워크-보조 인증(network-assisted authentication)을 수행하도록 구성됨 ― ; 및
사용자-보조 인증(user-assisted authentication) 정보에 기초하여 상기 UE의 사용자를 인증하도록 그리고 상기 복수의 네트워크-보조 인증 모듈들 중에서 상기 서비스 제공자에 대해 상기 네트워크 보조 인증을 수행하기 위한 네트워크-보조 인증 모듈을 선택하도록 구성되는, 싱글 사인-온(single sign-on, SSO) 서브시스템
을 포함하고, 상기 SSO 서브시스템은 또한 하나 이상의 정책들에 기초하여, 상기 사용자-보조 인증을 수행하고 상기 네트워크-보조 인증 모듈을 선택하도록 구성되는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 사용자-보조 인증 정보는 사용자 ID(identity) 또는 사용자 크리덴셜(credential) 중 적어도 하나를 포함하고, 상기 SSO 서브시스템은 상기 사용자 ID를 사용하여 상기 사용자-보조 인증을 수행하도록 구성되며, 상기 UE는 UE ID를 사용하여 상기 네트워크-보조 인증을 수행하도록 구성되는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 네트워크-보조 인증 정책들은 상기 사용자-보조 인증과 연관되는 사용자-보조 인증 강도 또는 상기 네트워크-보조 인증과 연관되는 네트워크-보조 인증 강도 중 적어도 하나를 표시하는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 네트워크-보조 인증은 상기 사용자가 인증되었다는 것을 표시하는 어써션 메시지(assertion message)를 상기 서비스 제공자로 전송하는 것에 의해 수행되는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 SSO 서브시스템은 또한 상기 사용자-보조 인증으로부터 얻어지는 적어도 하나의 파라미터를 사용하여 상기 네트워크-보조 인증을 수행하도록 구성되는 것인, 사용자 장비(UE).
제5항에 있어서,
상기 사용자-보조 인증으로부터 얻어지는 상기 적어도 하나의 파라미터는 사용자-보조 인증 상태, 사용자-보조 인증 시간, 또는 사용자-보조 인증 강도를 포함하는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 SSO 서브시스템은 또한 상기 네트워크-보조 인증을 위해 사용될 ID 제공자의 선택을 수신하도록 구성되고, 상기 ID 제공자는 상기 복수의 네트워크-보조 인증 모듈들 중의 한 인증 모듈과 연관되는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 UE는 복수의 서비스 제공자들에 의해 제공되는 서비스들을 지원하도록 구성되고, 각각의 서비스 제공자는 상이한 세트의 정책들과 연관되는 것인, 사용자 장비(UE).
제1항에 있어서,
상기 애플리케이션으로부터 상기 복수의 네트워크-보조 인증 모듈들로의 통신을 가능하게 하는 인증 요청자(supplicant)를 추가로 포함하는 UE.
제9항에 있어서,
상기 인증 요청자는 상기 SSO 서브시스템에 포함되는 것인, 사용자 장비(UE).
제9항에 있어서,
상기 인증 요청자는 상기 서비스 제공자 또는 ID 제공자 중 적어도 하나로부터 다운로드되는 것인, 사용자 장비(UE).
제9항에 있어서,
상기 인증 요청자는 상기 사용자 애플리케이션이 상기 SSO 서브시스템의 하나 이상의 특징들을 사용하는 것을 허용하도록 구성되는 것인, 사용자 장비(UE).
제9항에 있어서,
상기 인증 요청자가 상기 사용자 애플리케이션 및 상기 SSO 서브시스템과 통신할 수 있도록, 상기 인증 요청자는 상기 사용자 애플리케이션에 대응하는 것인, 사용자 장비(UE).
복수의 네트워크-보조 인증(network-assisted authentication) 모듈들을 포함하는 사용자 장비(user equipment, UE)에서의 방법에 있어서,
각각의 네트워크-보조 인증 모듈은 상이한 네트워크-보조 인증 프로토콜에 대응하고, 상기 복수의 네트워크-보조 인증 모듈들 중 하나 이상은 서비스에 액세스하기 위해 서비스 제공자에 대해 네트워크-보조 인증을 수행하도록 구성되며, 상기 방법은,
사용자-보조 인증 정보에 기초하여 상기 UE의 사용자를 인증하는 단계;
상기 복수의 네트워크-보조 인증 모듈들 중에서 상기 서비스 제공자에 대해 상기 네트워크-보조 인증을 수행하기 위한 네트워크-보조 인증 모듈을 선택하는 단계; 및
하나 이상의 정책들에 기초하여, 상기 사용자-보조 인증(user-assisted authentication)을 수행하고 상기 네트워크-보조 인증 모듈을 선택하는 단계
를 포함하는, 복수의 네트워크-보조 인증 모듈들을 포함하는 사용자 장비(UE)에서의 방법.
제14항에 있어서,
상기 UE에 의해, 상기 서비스 제공자의 하나 이상의 데이터 필드들을 검출하는 단계; 및
상기 검출에 응답하여, 상기 하나 이상의 데이터 필드들을 대응 인증 데이터로 파퓰레이팅하는(populating) 단계
를 더 포함하는, 복수의 네트워크-보조 인증 모듈들을 포함하는 사용자 장비(UE)에서의 방법.
제14항에 있어서,
상기 사용자-보조 인증으로부터의 적어도 하나의 파라미터에 기초하여, 상기 네트워크-보조 인증을 수행하는 단계를 더 포함하는, 복수의 네트워크-보조 인증 모듈들을 포함하는 사용자 장비(UE)에서의 방법.
제16항에 있어서,
상기 사용자-보조 인증으로부터 얻어지는 상기 적어도 하나의 파라미터는 사용자-보조 인증 상태, 사용자-보조 인증 시간, 또는 사용자-보조 인증 강도를 포함하는 것인, 복수의 네트워크-보조 인증 모듈들을 포함하는 사용자 장비(UE)에서의 방법.
제14항에 있어서,
상기 사용자-보조 인증에 응답하여, 상기 사용자를 상기 서비스 제공자에 대해 인증하기 위한 인증 요청자(supplicant)를 다운로드하는 단계를 더 포함하고, 상기 인증 요청자는 상기 UE의 사용자 애플리케이션과 매칭되는 것인, 복수의 네트워크-보조 인증 모듈들을 포함하는 사용자 장비(UE)에서의 방법.