KR20180048766A - 서비스 계층 동적 권한부여 - Google Patents
서비스 계층 동적 권한부여 Download PDFInfo
- Publication number
- KR20180048766A KR20180048766A KR1020187008346A KR20187008346A KR20180048766A KR 20180048766 A KR20180048766 A KR 20180048766A KR 1020187008346 A KR1020187008346 A KR 1020187008346A KR 20187008346 A KR20187008346 A KR 20187008346A KR 20180048766 A KR20180048766 A KR 20180048766A
- Authority
- KR
- South Korea
- Prior art keywords
- slda
- service layer
- resource
- authorization
- request
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- 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/16—Implementing security features at a particular protocol layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/086—Access security using security domains
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Mobile Radio Communication Systems (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Computer And Data Communications (AREA)
Abstract
확장가능한 정책 기반 서비스 계층의 동적 권한부여 프레임워크는 등록자가 현재 적합한 액세스 권한들이 없는 서비스 계층에 의해 호스팅되는 리소스 또는 서비스에 대한 등록자의 액세스를 승인할지 또는 거부할지 여부를 서비스 계층이 결정할 수 있게 한다. 또한, 이 방법은 서비스 계층이 그 정적으로 구성된 부여 권한들을 (그 동적 권한부여 결과들을 활용하여) 동적으로 업데이트하게 하여 동일한 등록자로부터의 향후 요청들, 및 동일한 리소스 및 서비스에 대한 향후 요청들에 대해 동적 권한부여가 수행될 필요가 없게 할 수 있다.
Description
관련 출원들에 대한 상호 참조
본 출원은 2015년 8월 28일자로 출원된 미국 가특허 출원 제62/211,471호의 이득을 주장하며, 그 개시 내용은 전체가 본 명세서에 참조로 포함된다.
프로토콜 스택 측면에서, 미들웨어 서비스 계층들(middleware service layers)은 일반적으로 기존의 네트워크 프로토콜 스택들 위에 계층화되고 클라이언트 애플리케이션들 및 기타 서비스들에 부가가치 서비스들을 제공한다. 따라서, 서비스 계층들은 흔히 '미들웨어' 서비스 계층들로 분류된다. 예를 들어, 도 1은 IP 네트워킹 스택과 애플리케이션들 사이에 위치하는 서비스 계층(102)을 도시한다. 다른 예는 TCP 또는 UDP와 같은 전송 프로토콜 또는 SOAP(도 1에 도시되지 않음)와 같은 비RESTful 프로토콜을 통해 직접적으로 서비스 계층(102)을 계층화하는 것을 포함할 수 있음에 유의해야 한다.
네트워크 내의 미들웨어 서비스 계층 인스턴스들의 예시적인 전개 시나리오가 도 2에 도시된다. 이 예에서, 서비스 계층 인스턴스들은 다양한 네트워크 노드들(게이트웨이들 및 서버들) 상에 전개되며 네트워크 애플리케이션들, 디바이스 애플리케이션들 및 네트워크 노드들 그 자체에 부가가치 서비스를 제공한다.
M2M/IoT 서비스 계층(102)은 M2M/IoT 유형의 디바이스들 및 애플리케이션들에 부가가치 서비스들을 제공하는 것을 구체적인 목표로 하는 한 가지 유형의 미들웨어 서비스 계층의 예이다. 최근에는, 몇몇 산업 표준 기관들(예를 들어, oneM2M 기능 아키텍처, oneM2M-TS-0001 oneM2M 기능 아키텍처-V-1.10.0, ETSI M2M 통신 기능 아키텍처에 설명된 oneM2M, ETSI TS 102 690 1.1.1 (2011-10) 드래프트, 및 OMA 경량 M2M(Lightweight M2M)(LWM2M) 기술 사양, 드래프트 버전 1.0(2013년 3월 14일)에 설명된 OMA LWM2M)은 M2M/IoT 유형의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업 및 홈 네트워크들과 같은 전개들에 통합하는 것과 관련된 도전들을 해결하기 위해 M2M/IoT 서비스 계층들을 개발하여 왔다.
M2M 서비스 계층(102)은 애플리케이션들 및 디바이스들에게 서비스 계층(102)에 의해 지원되는 M2M 중심 능력들의 수집을 위한 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속 관리를 포함한다. 이러한 능력들은 M2M 서비스 계층(102)에 의해 지원되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 애플리케이션들에 이용가능하게 된다.
oneM2M의 목적 및 목표는, 다양한 하드웨어 및 소프트웨어 플랫폼들 내에 용이하게 내장될 수 있고 관련 분야에서의 매우 다양한 디바이스들을 전세계의 M2M 애플리케이션 서버들과 접속시키는데 의존될 수 있는 공통 M2M 서비스 계층(102)에 대한 필요성을 해결하는 기술 사양들을 개발하는 것이다.
oneM2M 서비스 계층은 공통 서비스 기능들(Common Service Functions)(CSFs)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는, 상이한 유형들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 CSE(Common Services Entity)(즉, 서비스 계층)라고 지칭된다. 이들 공통 기능들은 도 3에 도시된 바와 같이 Mca, Mcc 및 Mcn 기준점들을 통해 노출된다. Mca 기준점은, AE(Application Entity)와 CSE 사이의 통신 흐름들을 지정하고, 한편 Mcc 기준점은 동일한 M2M 서비스 제공자 도메인에서의 2개의 CSE들 사이의 통신 흐름들을 지정한다. Mca와 Mcc에 걸친 통신들은 쌍을 이룬 요청/응답 메시지들을 통해 이루어질 수 있고, 각각의 요청은 목표로 한 CSE 상에 호스팅되는 리소스에 대해 특정한 RESTful 동작(예를 들어, 생성, 검색, 업데이트 및 삭제)을 수행한다. Mcc'는 상이한 M2M SP들의 인프라스트럭처 도메인에 위치한 CSE들 사이에서 이용된다. Mcn은 전송 및 접속 이외의 서비스들에 대해 CSE와 하위(underlying) NSE(Network Services Entity) 사이에 이용된다.
CSE들은 "노드들"로 지칭되는 아키텍처 엔티티들 상에 호스팅된다. 노드는, a) 하나의 CSE와 0개 이상의 AE, 또는 b) 하나 이상의 AE를 포함하는 기능 엔티티이다. oneM2M 아키텍처는 도 4에 도시된 바와 같이 다양한 유형들의 노드 구성들을 지원한다.
oneM2M에 의해 지원되는 CSF의 초기 세트가 도 5에 도시되어 있다. 특정한 CSE 구현은 모든 기능을 지원하지 않을 수 있지만, 완전한 구현은 도면 내의 모든 기능들을 포함할 것이다.
oneM2M RESTful 아키텍처마다, CSF들은 "리소스들"의 세트로 표현된다. 리소스는 생성, 검색, 업데이트 및 삭제와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처 내의 고유하게 주소지정가능한 엔티티이다. 이러한 리소스들은 URI들(Universal Resource Identifiers)을 이용하여 주소지정가능하게 된다. 리소스는 자식 리소스들 및 속성들을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 그 자식 리소스들에 대한 참조들(references)을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 그 리소스에 관한 정보를 저장하는 "속성들"의 세트를 지원한다.
인증은 서비스 계층 등록자의 아이덴티티가 신뢰할 수 있는 자격증명과 관련되어 있는지 검증하는 프로세스이다. 인증 프로세스를 수행하는 방법은 이용된 인증 메커니즘에 의존할 것이다. 예를 들어, 증명서 기반 인증의 경우, 인증은 일반적으로 디지털 서명을 확인하는 것을 포함한다. 대칭 키 인증의 경우, 인증은 일반적으로 메시지 인증 코드(MAC)를 확인하는 것을 포함한다. 상호 인증은 등록자와, 등록자가 등록하는 서비스 계층 간에 발생하는 양방향 인증이다. 따라서, 상호 인증은 서비스 계층이 등록자의 아이덴티티를 검증하고 또한 등록자가 그 서비스 계층의 아이덴티티를 검증하는 프로세스이다.
서비스 계층 권한부여(authorization) 메커니즘들은 서비스 계층에서 호스팅되는 리소스들 및/또는 서비스들에 대한 액세스를 제어하는데 이용된다. 권한부여는 일반적으로 인증된 등록자들이 정적으로 프로비저닝된 권한부여 정책들 및 할당된 역할들을 기반으로 서비스 계층에서 호스팅되는 리소스들 및 서비스들에 액세스하게 하는 것을 포함한다. 권한부여 정책은 주어진 서비스 계층 등록자가 서비스 계층에서 호스팅되는 보호된 리소스들 또는 서비스들에 액세스 허용되는지 여부를 정의하는 규칙들의 세트이다. 이러한 정책들은 서로 다른 메커니즘들을 기반으로 할 수 있다. 세 가지 통상적인 유형의 권한부여 정책은 권한부여 리스트(ACL), 역할 기반 권한부여(RBAC) 및 가입 기반 권한부여(SBAC)이다.
서비스 계층 ACL은 어떤 서비스 계층 등록자들이 어떤 리소스들 및 서비스들에 액세스 허용되는지뿐만 아니라 어떤 동작들이 주어진 리소스들 또는 서비스들에 대해 수행하도록 허용되는지를 정의한다. 예를 들어, 등록자(123)는 리소스 ABC를 판독하도록 허용된다(그러나 기입하도록 허용되지는 않는다).
서비스 계층 RBAC는 등록자에게 할당된 특정한 역할에 따라 리소스들 또는 서비스들에 대해 특정한 동작들을 수행할 권한들을 정의한다. 예를 들어, 등록자(123)는 '관리자' 역할을 가질 수 있는 반면 등록자(456)는 '이용자' 역할을 가질 수 있다. RBAC는 '관리자'가 특정한 리소스들에 대해 판독과 기입 액세스 모두를 갖는 반면 '이용자'는 판독 액세스만을 갖는 권한들을 정의할 수 있다.
서비스 계층 SBAC는 등록자의 가입 레벨에 따라 리소스들 또는 서비스들에 대해 특정한 동작들을 수행할 권한들을 정의한다. 예를 들어, 등록자(123)는 특정한 유형들의 서비스들에 액세스할 자격이 주어지지만, 가입 비용에 기반하여 다른 유형들의 서비스들에는 액세스하지 못하게 가입할 수 있다.
ACL, RBAC 및 SBAC 권한들은 서비스 계층 가입 모델에 기반하여 사전 프로비저닝(즉, 대역 외 구성)될 수 있다. 예를 들어, 등록자가 자신과 서비스 계층 제공자 간에 사전 설정된 서비스 계층 가입 유형에 기반하여, 가입은, 등록자가 서비스 계층 리소스들 및 서비스들에 액세스하려고 시도할 때 등록자에게 부여된 권한들의 유형들을 결정할 수 있다.
M2M 서비스 계층들(예를 들어, oneM2M, ETSI M2M, OMA LWM2M)은 위에 설명된 메커니즘들과 같은 권한부여 메커니즘들을 지원하는 서비스 계층들의 예들이다.
본 개시 내용의 초점은 (식별 및 인증이 아닌) 서비스 계층 권한부여와 관련된 권한부여 기능의 향상들에 초점을 두고 있다는 점에 유의해야 한다.
oneM2M은 도 6a에 도시된 바와 같이 권한들의 구성된 세트를 지원하는 기존의 <accessControlPolicy> 리소스를 정의한다. 권한들은 인증된 서비스 계층 등록자들이 <accessControlPolicy> 리소스와 관련된 리소스들에 액세스할 수 있는 권한들을 갖는 것을 정의하는 권한부여 규칙들(즉, 정책들)의 세트로 구성될 수 있다. 권한들이 구성되면, 이러한 권한들은 일반적으로 서비스 계층의 관점에서 정적이다. 서비스 계층은 즉석에서 동적으로 권한들을 생성, 업데이트 또는 삭제하지 않는다.
현재까지, oneM2M은 ACL 정책에 기반하여 권한들을 정의하였다. oneM2M은 이 ACL 정책을 권한들 속성 내에 저장될 수 있는 액세스 제어 규칙 투플들의 세트로 정의하며, 각각의 투플은 세 가지 구성요소, 즉 accessControlOriginators, accessControlOperations, accessControlContext로 구성된다.
accessControlOriginators - 이 권한부여 정책과 관련된 리소스들에 액세스하도록 권한부여된 서비스 계층 등록자들의 세트(예를 들어, CSE-ID들 또는 AE-ID들의 리스트).
accessControlOperations - 각각의 권한부여된 서비스 계층 등록자가 수행하도록 권한부여된 동작들의 세트(예를 들어, 생성, 검색, 업데이트 및 삭제).
accessControlContext - oneM2M은 현재 다음 세 가지 유형의 권한부여 컨텍스트를 정의한다.
o accessControlTimeWindows - 요청들이 허용되는 동안의 시간 윈도우. 이 권한부여 정책과 관련된 리소스들에 대해 이 시간 외에 발생하는 요청들은 거부될 것이다.
o accessControlLocationRegions - 서비스 계층 등록자들이 권한부여 정책과 관련된 리소스들에 액세스할 때 위치하도록 허용되는 위치들의 리스트. 이 리스트에 없는 위치들의 서비스 계층 등록자들로부터의 요청들은 거부될 것이다.
o accessControlIpAddresses - 이 권한부여 정책과 관련된 리소스들에 액세스하도록 허용된 서비스 계층 등록자들의 IP 주소들이다. 이 리스트에 없는 IP 주소들을 가진 서비스 계층 등록자들의 요청들은 거부될 것이다.
OAuth 2.0 권한부여 프레임워크는 제3자 클라이언트 애플리케이션이 리소스 소유자를 대신하여 HTTP(Hypertext Transfer Protocol) 리소스에 대한 액세스를 획득하게 한다. OAuth는 리소스 소유자들이 자격증명들을 공유하지 않고 그들의 리소스들에 대한 제3자 액세스 권한을 부여하는 프로세스를 지정한다. HTTP와 함께 동작하도록 특별히 설계된 OAuth는 본질적으로 리소스 소유자의 승인을 받아 권한부여 서버에 의해 액세스 토큰들이 제3자 클라이언트 애플리케이션들에게 발행되게 한다. 그 다음, 애플리케이션은 액세스 토큰을 이용하여 도 6b에 도시된 바와 같이 리소스 서버에 의해 호스팅되는 보호된 리소스들에 액세스한다.
도 6b의 단계(A)에서, 클라이언트는 리소스 소유자로부터 권한부여를 요청한다. 권한부여 요청은 리소스에 직접 이루어질 수 있다.
도 6b의 단계(B)에서, 클라이언트는 리소스 소유자의 권한부여를 나타내는 자격증명인 권한부여 승인을 수신한다.
도 6b의 단계(C)에서, 클라이언트는 권한부여 서버로 인증하고 권한부여 승인을 제시함으로써 액세스 토큰을 요청한다.
도 6b의 단계(D)에서, 권한부여 서버는 클라이언트를 인증하고 권한부여 승인을 검증하며, 유효한 경우, 액세스 토큰을 발행한다.
도 6b의 단계(E)에서, 클라이언트는 리소스 서버로부터 보호된 리소스를 요청하고 액세스 토큰을 제시함으로써 인증한다.
도 6b의 단계(F)에서, 리소스 서버는 액세스 토큰을 검증하고, 유효한 경우, 요청을 처리한다.
확장가능한 정책 기반 서비스 계층의 동적 권한부여 프레임워크는 등록자가 현재 적합한 액세스 권한들이 없는 서비스 계층에 의해 호스팅되는 리소스들 또는 서비스들에 대한 등록자 액세스를 승인할지 또는 거부할지를 서비스 계층이 결정할 수 있게 한다. 또한, 이 방법은 서비스 계층이 그 정적으로 구성된 부여 권한들을 (그 동적 권한부여 결과들을 활용하여) 동적으로 업데이트하여 동일한 등록자로부터의 향후 요청들, 및 동일한 리소스 및 서비스에 대한 향후 요청들에 대해 동적 권한부여가 수행될 필요가 없게 할 수 있다.
서비스 계층 등록자가 서비스 계층이 그 리소스들 또는 서비스들에 액세스하기 위한 다른 서비스 계층 등록자들의 권한을 승인할지 또는 거부할지를 결정하기 위해 등록자와 협의하는데 이용할 수 있는 그 리소스들 또는 서비스들에 대한 협의 기반 동적 권한부여 정책들을 지정하게 하는 방법이 이용될 수 있다.
서비스 계층 등록자가 서비스 계층이 다른 등록자들에 대한 동적 권한부여를 지원하는데 이용할 수 있는 그 리소스들 또는 서비스들에 대한 결제 기반 동적 권한부여 정책들을 지정하는 방법이 이용될 수 있다. 다른 서비스 계층 등록자들이 리소스들 또는 서비스들에 액세스하기 위해 기꺼이 결제하는 비율에 기반하여 권한들이 승인되거나 거부되는 것이 이용될 수 있다.
서비스 계층 등록자가 그 리소스들 또는 서비스들에 대한 바터(barter) 기반 동적 권한부여 정책들을 지정하는 방법이 이용될 수 있으며, 이러한 정책들은 서비스 계층이 다른 등록자의 리소스들 및 서비스들에 대해 액세스를 획득하고자 하는 등록자 대신에 그 자신의 리소스들 또는 서비스들에 대한 액세스와 교환하는 식으로 동적으로 바터링하게 한다.
서비스 계층 등록자가 그 리소스들 또는 서비스들에 대한 보안 평가 기반 동적 권한부여 정책들을 지정하는 방법이 이용될 수 있으며, 이러한 정책들은 서비스 계층이 다른 등록자의 리소스들 및 서비스들에 대해 액세스를 획득하고자 하는 등록자의 보안 레벨을 동적으로 평가하고 그 보안 레벨이 동적 권한부여 요건들을 충족시키는지 여부를 결정하게 한다.
서비스 계층 등록자가 그 리소스들 또는 서비스들에 대한 평판 기반 동적 권한부여 정책들을 지정하는 방법이 이용될 수 있으며, 이러한 정책들은 서비스 계층이 다른 등록자의 리소스들 및 서비스들에 대해 액세스를 획득하고자 하는 등록자의 평판 레벨을 동적으로 평가하고 그 평판이 동적 권한부여 요건들을 충족시키는지 여부를 결정하게 한다.
oneM2M 기반 시스템에 대해 제안된 서비스 계층 동적 권한부여 특징들의 실시예들이 설명된다. 이러한 실시예들은 본 개시 내용에 의해 정의되는 서비스 계층 동적 권한부여 특징들이 oneM2M 시스템에서 어떻게 실현될 수 있는지를 설명하는 oneM2M 아키텍처, 리소스 레벨, 메시징 레벨 및 절차 레벨의 제안들을 포함한다.
본 개시 내용에서 정의되는 방법들 및 실시예들이 M2M/IoT 서비스 계층들의 면에서 설명되었지만, 이러한 아이디어들은 또한 다른 유형들의 서비스 계층들에도 적용될 수 있음에 유의해야 한다.
본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들의 선택을 단순화된 형태로 소개하도록 제공된다. 본 내용은 청구되는 주제의 주요한 특징들 또는 필수적 특징들을 식별하고자 의도되는 것도 아니고, 청구되는 주제의 범위를 제한하는데 이용되고자 의도되는 것도 아니다. 게다가, 청구되는 주제는 본 개시 내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한들에 국한되지 않는다.
첨부 도면들과 관련하여 예로서 주어져 있는 이하의 설명으로부터 보다 상세한 이해가 이루어질 수 있다.
도 1은 미들웨어 서비스 계층을 지원하는 프로토콜 스택의 도면이다.
도 2는 네트워크 내의 예시적인 미들웨어 서비스 계층 전개의 도면이다.
도 3은 oneM2M 아키텍처의 도면이다.
도 4는 oneM2M 아키텍처 구성들의 도면이다.
도 5는 oneM2M CSF들의 도면이다.
도 6a는 oneM2M <accessControlPolicy> 리소스들의 도면이다.
도 6b는 OAuth 2.0 권한부여 프레임워크의 도면이다.
도 7은 서비스 계층에 의해 로컬적으로 수행된 서비스 계층 동적 권한부여의 도면이다.
도 8은 협의를 통해 수행된 서비스 계층 동적 권한부여의 도면이다.
도 9는 서비스 계층 동적 권한부여 기능의 도면이다.
도 10은 서비스 계층에서 로컬 기능으로서 전개된 SLDA(902)의 도면이다.
도 11은 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 12는 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 13은 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 14는 정적 및 동적 정책 관리의 도면이다.
도 15는 정책 프로비저닝 프로세스의 도면이다.
도 16은 리소스에 대한 액세스 정책들의 생성 및 호스팅의 도면이다.
도 17은 액세스 제어된 리소스를 요청하는 클라이언트의 도면이다.
도 18은 푸시 모델을 이용하는 리소스 액세스의 도면이다.
도 19는 결제 권한부여 프로세스의 도면이다.
도 20은 풀 모델에 기반한 권한부여의 도면이다.
도 21은 푸시 확인 모델에 기반한 권한부여의 도면이다.
도 22는 간접 푸시 모델에 기반한 권한부여의 도면이다.
도 23은 oneM2M MEF(2304), MAF(2302) 또는 CSE 엔티티에 중앙집중 전개된 SLDA 기능의 도면이다.
도 24는 oneM2M MEF(2304), MAF(2302) 및 CSE 엔티티들에 걸쳐 분산 전개된 SLDA 기능의 도면이다.
도 25는 <dynAuthPolicy> oneM2M 리소스의 도면이다.
도 26은 dynAuthPolicyIDs 속성을 통한 <dynAuthPolicy>에의 연결의 도면이다.
도 27은 <accessControlPolicy>의 자식 리소스들로서의 <dynAuthPolicy>의 도면이다.
도 28은 <accessControlPolicy>에 추가된 dynAuthPolicyIDs 속성을 통한 <dynAuthPolicy> 연결의 도면이다.
도 29는 <accessControlPolicy>에 병합된 <dynAuthPolicy> 속성들의 도면이다.
도 30은 <dynAuthRequest> 가상 리소스의 도면이다.
도 31은 CSEBase하에서 인스턴스화된 <dynAuthRequest>의 도면이다.
도 32는 <AE> 리소스하에서 인스턴스화된 <dynAuthRequest>의 도면이다.
도 33은 <consult> 가상 리소스의 도면이다.
도 34는 서비스 계층 동적 권한부여 정책들의 구성 도면이다.
도 35는 자율적 서비스 계층 동적 권한부여 처리의 도면이다.
도 36은 명시적 서비스 계층 동적 권한부여 요청 처리의 도면이다.
도 37은 협의 기반 서비스 계층 동적 권한부여의 도면이다.
도 38은 결제 기반 서비스 계층 동적 권한부여의 도면이다.
도 39는 바터 기반 서비스 계층 동적 권한부여의 도면이다.
도 40은 보안 평가 기반 서비스 계층 동적 권한부여의 도면이다.
도 41은 서비스 계층 가입 검증 기반 동적 권한부여의 도면이다.
도 42는 평판 기반 서비스 계층 동적 권한부여의 도면이다.
도 43은 일 실시예의 그래픽 이용자 인터페이스의 도면이다.
도 44a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 44b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들 및 통신 네트워크를 위한 서비스들을 제공하는 필드 도메인 내의 예시적인 M2M 서비스 계층의 도면이다.
도 44c는 본 명세서에서 설명된 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 예시적인 디바이스의 도면이다.
도 44d는 본 명세서에서 설명된 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.
도 1은 미들웨어 서비스 계층을 지원하는 프로토콜 스택의 도면이다.
도 2는 네트워크 내의 예시적인 미들웨어 서비스 계층 전개의 도면이다.
도 3은 oneM2M 아키텍처의 도면이다.
도 4는 oneM2M 아키텍처 구성들의 도면이다.
도 5는 oneM2M CSF들의 도면이다.
도 6a는 oneM2M <accessControlPolicy> 리소스들의 도면이다.
도 6b는 OAuth 2.0 권한부여 프레임워크의 도면이다.
도 7은 서비스 계층에 의해 로컬적으로 수행된 서비스 계층 동적 권한부여의 도면이다.
도 8은 협의를 통해 수행된 서비스 계층 동적 권한부여의 도면이다.
도 9는 서비스 계층 동적 권한부여 기능의 도면이다.
도 10은 서비스 계층에서 로컬 기능으로서 전개된 SLDA(902)의 도면이다.
도 11은 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 12는 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 13은 서비스 계층으로부터 분리 전개된 SLDA(902)의 도면이다.
도 14는 정적 및 동적 정책 관리의 도면이다.
도 15는 정책 프로비저닝 프로세스의 도면이다.
도 16은 리소스에 대한 액세스 정책들의 생성 및 호스팅의 도면이다.
도 17은 액세스 제어된 리소스를 요청하는 클라이언트의 도면이다.
도 18은 푸시 모델을 이용하는 리소스 액세스의 도면이다.
도 19는 결제 권한부여 프로세스의 도면이다.
도 20은 풀 모델에 기반한 권한부여의 도면이다.
도 21은 푸시 확인 모델에 기반한 권한부여의 도면이다.
도 22는 간접 푸시 모델에 기반한 권한부여의 도면이다.
도 23은 oneM2M MEF(2304), MAF(2302) 또는 CSE 엔티티에 중앙집중 전개된 SLDA 기능의 도면이다.
도 24는 oneM2M MEF(2304), MAF(2302) 및 CSE 엔티티들에 걸쳐 분산 전개된 SLDA 기능의 도면이다.
도 25는 <dynAuthPolicy> oneM2M 리소스의 도면이다.
도 26은 dynAuthPolicyIDs 속성을 통한 <dynAuthPolicy>에의 연결의 도면이다.
도 27은 <accessControlPolicy>의 자식 리소스들로서의 <dynAuthPolicy>의 도면이다.
도 28은 <accessControlPolicy>에 추가된 dynAuthPolicyIDs 속성을 통한 <dynAuthPolicy> 연결의 도면이다.
도 29는 <accessControlPolicy>에 병합된 <dynAuthPolicy> 속성들의 도면이다.
도 30은 <dynAuthRequest> 가상 리소스의 도면이다.
도 31은 CSEBase하에서 인스턴스화된 <dynAuthRequest>의 도면이다.
도 32는 <AE> 리소스하에서 인스턴스화된 <dynAuthRequest>의 도면이다.
도 33은 <consult> 가상 리소스의 도면이다.
도 34는 서비스 계층 동적 권한부여 정책들의 구성 도면이다.
도 35는 자율적 서비스 계층 동적 권한부여 처리의 도면이다.
도 36은 명시적 서비스 계층 동적 권한부여 요청 처리의 도면이다.
도 37은 협의 기반 서비스 계층 동적 권한부여의 도면이다.
도 38은 결제 기반 서비스 계층 동적 권한부여의 도면이다.
도 39는 바터 기반 서비스 계층 동적 권한부여의 도면이다.
도 40은 보안 평가 기반 서비스 계층 동적 권한부여의 도면이다.
도 41은 서비스 계층 가입 검증 기반 동적 권한부여의 도면이다.
도 42는 평판 기반 서비스 계층 동적 권한부여의 도면이다.
도 43은 일 실시예의 그래픽 이용자 인터페이스의 도면이다.
도 44a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 44b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들 및 통신 네트워크를 위한 서비스들을 제공하는 필드 도메인 내의 예시적인 M2M 서비스 계층의 도면이다.
도 44c는 본 명세서에서 설명된 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 예시적인 디바이스의 도면이다.
도 44d는 본 명세서에서 설명된 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.
AAA
인증, 권한부여 및 계정관리
ACL
액세스 제어 리스트
ACP
액세스 제어 정책
AE
애플리케이션 엔티티
API
애플리케이션 프로그래밍 인터페이스
CSF
능력 서비스 기능
CSE
능력 서비스 엔티티
IoT
사물 인터넷
MAC
메시지 인증 코드
MAF
M2M 인증 기능
MEF
M2M 등록 기능
M2M
머신 투 머신
NSE
네트워크 서비스 엔티티
PA
정책 관리
PD
정책 결정
PE
정책 시행
PI
정책 정보
RBAC
역할 기반 권한부여
SBAC
가입 기반 권한부여
SLDA
서비스 계층 동적 권한부여
SLSA
서비스 계층 정적 권한부여
SP
서비스 제공자
URI
범용 리소스 식별자
네트워크 노드는 리소스들 또는 서비스들을 호스팅하는 네트워크 내의 주소지정가능한 엔티티일 수 있다. 네트워크 노드는 네트워크 내의 물리적 엔티티(예를 들어, 디바이스, 게이트웨이 또는 서버) 또는 가상 엔티티(예를 들어, 가상 머신) 중 어느 하나일 수 있다.
리소스는 생성, 검색, 업데이트 및 삭제와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 주소지정가능한 엔티티일 수 있다.
서비스는 지원되는 인터페이스(예를 들어, 데이터 저장 서비스)를 통해 액세스되는 관련 소프트웨어 기능들의 세트일 수 있다.
서비스 계층(102)은 애플리케이션 프로그래밍 인터페이스들(API들) 및 하위 네트워킹 인터페이스들의 세트를 통해 서비스 계층 등록자들이 이용할 수 있게 되는 리소스들 및 서비스들을 호스팅하는 소프트웨어 계층일 수 있다.
서비스 계층 등록자는 서비스 계층에 등록하는 엔티티일 수 있다. 예를 들어, 애플리케이션, 개별적인 서비스 또는 서비스 계층의 다른 인스턴스이다.
일 실시예에서, 서비스 계층 동적 권한부여는, 1) 요청자가 현재 적합한 액세스 권한들이 없는 서비스 계층에 의해 호스팅되는 리소스 또는 서비스에 액세스하기 위한 권한들을 승인 또는 거부할지 여부 및 2) 동일한 등록자로부터의 향후 요청들, 및 동일한 리소스 및 서비스에 대한 향후 요청들에 대해 동적 권한부여가 수행될 필요가 없도록 정적 부여 권한들을 동적 권한부여 결과들로 업데이트할지 여부를 포함할 수 있다.
공통 서비스 기능(CSF)은 서비스 계층에 의해 지원되는 서비스에 대한 oneM2M 용어이다. 공통 서비스 엔티티(CSE)는 서비스 계층에 대한 oneM2M 용어이다. 기존의 서비스 계층들(예를 들어, oneM2M 기능 아키텍처, oneM2M-TS-0001 oneM2M 기능 아키텍처-V-1.10.0, ETSI M2M 통신 기능 아키텍처에 설명된 oneM2M, ETSI TS 102 690 1.1.1 (2011-10) 드래프트, 및 OMA 경량 M2M(LWM2M) 기술 사양, 드래프트 버전 1.0(2013년 3월 14일)에 설명된 OMA LWM2M)은 그 등록자들(예를 들어, M2M/IoT 디바이스들)에게 액세스를 허용하는 서비스들 또는 리소스들을 제어하기 위한 권한부여 메커니즘들뿐만 아니라 이러한 리소스들 및/또는 서비스들에 대해 등록자들이 수행하도록 허용된 동작들의 유형들을 지원한다. 그러나, 이러한 서비스 계층 권한부여 메커니즘들은 전형적으로 사실상 정적인(예를 들어, 사전 프로비저닝된) 것으로 구성되며, 이에 따라 다음의 단점들을 갖는다.
단점 #1 - 서비스 계층 등록자가 새로운 허가들을 동적으로 추가하여 액세스 허가가 없는 리소스에 대해 액세스를 획득하게 하는 지원이 부족한다. 그 결과, 등록자들은 액세스하기 위한 정적으로 사전 프로비저닝된 권한부여 정책들을 갖는 리소스들 및/또는 서비스들에만 액세스하도록 제한된다.
단점 #2 - 서비스 계층에서 호스팅되는 리소스들 또는 서비스들을 소유 또는 관리하는 등록자가 서비스 계층에 의해 등록자에게 수행되는 협의와 관련한 권한부여를 지정하여 리소스들 또는 서비스들에 액세스하려고 시도하지만 그렇게 할 적합한 권한들을 갖지 않은 다른 등록자들에 대한 액세스를 등록자가 승인 또는 거부하길 원하는지 여부를 결정하게 하는 고급 권한부여 메커니즘들에 대한 지원이 부족하다. 그 결과, 등록자들은 다른 등록자들이 그 리소스들 또는 서비스들에 액세스하려고 하는지/언제 액세스하려고 하는지, 및 그 요청들에 대한 액세스를 동적으로 권한부여할지 여부를 알아낼 수 없다.
단점 #3 - 서비스 계층에서 호스팅되는 리소스들 또는 서비스들을 소유 또는 관리하는 등록자가 요청 등록자가 액세스에 대해 결제하려는 요금들/수수료들과 관련한 권한부여를 지정하게 하는 고급 권한부여 메커니즘들에 대한 지원이 부족하다. 그 결과, 등록자들은 서비스 계층이 그 액세스 결제 의사에 기반하여 다른 등록자들에 대한 액세스를 동적으로 권한부여하게 할 수 없다.
단점 #4 - 서비스 계층에서 호스팅되는 리소스들 또는 서비스들을 소유 또는 관리하는 등록자가 요청 등록자가 동의하려는 바터 합의와 관련한 권한부여를 지정하게 하는 고급 권한부여 메커니즘들에 대한 지원이 부족하다. 예를 들어, 등록자들 간 쌍방 합의는 서로의 리소스들에 대한 액세스를 승인할 것이다. 그 결과, 등록자들은 다른 등록자의 리소스들 또는 서비스들에 대한 액세스를 동적으로 획득하기 위한 상품으로서 그 리소스들을 바터링 및 이용할 수 없다.
단점 #5 - 서비스 계층에서 호스팅되는 리소스들 또는 서비스들을 소유 또는 관리하는 등록자가 충족해야 하는 필수 보안 평가 레벨과 관련한 권한부여를 지정하게 하는 고급 권한부여 메커니즘들에 대한 지원이 부족하다. 예를 들어, 등록자는 서비스 계층에 의해 동적으로 수행되는 보안 레벨 평가들을 만족시키는 것(예를 들어, 플랫폼은 특정한 보안 요건들을 충족시킴)에 기반하여 서비스 계층이 다른 등록자들에게 그 리소스들 또는 서비스들에 대한 액세스를 동적으로 권한부여하도록 구성할 수 없다.
단점 #6 - 서비스 계층에서 호스팅되는 리소스들 또는 서비스들을 소유 또는 관리하는 등록자가 권한부여되기 위해 충족해야 하는 필수 평판 평가 레벨과 관련한 권한부여를 지정하게 하는 고급 권한부여 메커니즘들에 대한 지원이 부족하다. 예를 들어, 등록자는 평판 레벨 평가를 만족시키는 것(예를 들어, 등록자의 동료 평가들이 '별 5개 중 4개'와 같이 특정 레벨의 만족도를 충족시킴)에 기반하여 서비스 계층이 다른 등록자들에게 그 리소스들 또는 서비스들에 대한 액세스를 동적으로 권한부여하도록 구성할 수 없다.
다음의 이용 사례는 서비스 계층과 그 부가가치 서비스 계층이 서비스 계층 동적 권한부여를 어떻게 지원할 수 있는지 설명한다. 이러한 이용 사례에서, App #1(202)은 서비스 계층에서 호스팅되는 XYZ로 명명된 리소스를 생성한다. 그 다음, App #1(202)은 정적 액세스 권한들의 세트로 리소스 XYZ에 대한 액세스 제어 정책을 구성한다. 정적 액세스 권한들은 리소스 XYZ에 액세스하도록 허용된 다른 애플리케이션들의 리스트 및 대응 리소스에서 수행할 수 있는 동작들과 같은 규칙들을 정의한다. 이러한 권한들은 리소스에 액세스할 수 있는 애플리케이션들과 리소스에 대해 수행할 수 있는 동작들을 제어하기 위해 서비스 계층에 의해 이용된다. App #1(202)은 알고 있고 액세스 승인하길 원하는 알려진 애플리케이션들로 이러한 권한들을 구성할 수 있다. App #1(202)은 또한 리소스에 대한 동적 권한부여 정책을 구성할 수 있다. 이 정책은 정적 액세스 권한들을 동적으로 생성, 업데이트 또는 삭제하는 것을 지원하기 위해 서비스 계층에 의해 이용될 수 있는 규칙들을 정의한다. 이는 새로운/상이한 애플리케이션들이 리소스에 액세스하려고 하는 사례들을 지원하는데 특히 유용하지만, App #1(202)은 이러한 애플리케이션들과의 관계를 사전에 알지 못하므로 리소스에 대한 액세스를 승인하도록 정적 권한들을 구성하지 않았다.
이러한 이용 사례에서, App #2(204)는 App #1이 정적 액세스 권한들을 승인하지 않은 애플리케이션의 예이다. App #2(204)는 리소스 XYZ에 대한 요청을 수행한다. 서비스 계층은 먼저 정적 액세스 권한들을 체크하여 App #2(204)에 권한들이 부여되지 않았음을 찾는다. 그 다음, 서비스 계층(102)은 동적 권한부여 정책이 구성되었는지를 체크한다. 구성되었다면, 서비스 계층(102)은 정적 액세스 권한들을 업데이트할지 여부 및 이들 애플리케이션들에 대한 액세스 권한들을 승인할지 여부를 평가하는 기능을 지원할 수 있다. 동적 권한부여 기능은 도 7에 도시된 바와 같이, 구성된 동적 권한부여 정책들을 이용하여 서비스 계층(102)에 의해 로컬로 수행될 수 있다. 대안적으로, 서비스 계층(102)은 시스템 내의 다른 엔티티들(예를 들어, 권한부여 서버)과의 협의를 지원하여 도 8에 도시된 바와 같이 동적 권한부여 수행시 서비스 계층(102)을 돕도록 할 수 있다.
도 7 및 도 8에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 7 내지 도 9에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 7 및 도 8에 도시된 단계들을 수행한다. 또한, 도 7 및 도 8에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
서비스 계층 동적 권한부여 기능
제안된 프레임워크는 도 9에 도시된 바와 같이 서비스 계층 동적 권한부여(SLDA) 기능(902)으로 구성된다. 이 기능은 요청자가 아직 액세스할 수 있는 사전 설정된 권한들이 없는 서비스 계층에 의해 호스팅되는 원하는 리소스 또는 서비스에 대한 액세스 권한들을 요청자에게 승인해야 하는지 여부를 결정하기 위한 요청 서비스를 지원한다. 이 기능은 도 9에 또한 도시된 다음의 네 가지 하위 기능으로 구성된다.
● 정책 관리 기능(SLDA-PA)(904) - 서비스 계층 동적 권한부여 정책들을 관리한다.
● 정책 결정 포인트(SLDA-PD)(908) - 서비스 계층 동적 권한부여 결정들을 평가하고 발행한다.
● 정책 시행 포인트(SLDA-PE)(910) - 서비스 계층 리소스 또는 서비스에 대한 요청을 인터셉트하고 SLDA-PD의 결정을 시행한다.
● 정책 정보 포인트(SLDA-PI)(906) - 보안, 결제, 위치 및 평판 평가들과 같은 추가 컨텍스트 정보를 SLDA-PD(908)에 제공한다.
도 9에 도시된 기능은, 후술되는 도 44c 또는 도 44d에 예시되는 것들 중 하나와 같은, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 또한 이 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 것으로 이해된다.
서비스 계층 동적 권한부여 전개 방안들
SLDA 기능(902)은 몇 가지 유연한 전개 방안들을 지원한다. SLDA 기능(902)은 서비스 계층의 로컬 기능으로서 전개될 수 있으며, 이 경우 서비스 계층은 도 10에 도시된 바와 같이 기본적으로 동적 권한부여 기능을 지원할 수 있다.
SLDA 기능(902)은 또한 도 11에 도시된 바와 같이 서비스 계층과 별도로 전개될 수 있다. 이 경우, SLDA(902)는 네트워크에서 독립형 기능으로서 전개될 수 있거나 또는 다른 엔티티(예를 들어, 보안 서버)의 하위 기능으로서 전개될 수 있다.
SLDA(902)는 또한 중앙집중화된 방식으로 전개될 수 있으며, 이 경우 단일 SLDA 기능(902)은 애플리케이션들뿐만 아니라 복수의 서비스 계층 인스턴스들로부터의 동적 권한부여 요청을 서비스할 수 있다. 이 전개 방안에서, 모든 동적 권한부여 관리, 결정들 및 시행은 도 12에 도시된 바와 같이 중앙집중화된 SLDA(902)에 의해 수행된다.
역으로, SLDA(902)는 분산 방식으로 전개될 수 있으며, 이 경우 SLDA(902) 또는 그 하위 기능들은 네트워크 전체에 분산될 수 있다. 예를 들어, SLDA-PI, SLDA-PA(904) 및 SLDA-PD(908)의 하위 기능은 네트워크 내의 중앙집중화된 노드 상에 전개될 수 있는 반면에, 별도의 SLDA-PE(910)의 하위 기능들은 도 13에 도시된 바와 같이 네트워크 전체에서 서비스 계층 인스턴스 각각 내에서 로컬적으로 전개될 수 있다. 이 분산 방안에서, 동적 권한부여 정책 정보, 관리 및 결정들은 중앙집중화된 SLDA-PD(908)에 의해 수행될 수 있는 반면에, 이러한 결정들의 결과는 그들이 처리하는 각각의 요청에 대해 개별적인 서비스 계층들의 개별적인 SLDA-PE들에 의해 시행될 수 있다.
도 10 내지 도 13에 도시된 기능은, 후술되는 도 44c 또는 도 44d에 예시되는 것들 중 하나와 같은, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 또한 이 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 것으로 이해된다.
서비스 계층 동적 권한부여 프로세스
권한부여 프로세스: 권한부여 프로세스는 다음을 포함한다.
● 일반 권한부여 규칙들의 프로비저닝
o SLSA-PD(1406), SLSA-PE(1410) 및 SLSA-PI(1412)에 대한 정적 규칙들 및 파라미터들의 프로비저닝
o SLDA-PD(908), SLDA-PE(910) 및 SLDA-PI(906)에 대한 동적 규칙들 및 파라미터들의 프로비저닝
o 정적 규칙과 동적 규칙 사이를 조정하기 위한 논리/규칙들의 프로비저닝
● 세분화된 리소스 특정 권한부여 규칙들의 생성
o 리소스에 대한 액세스를 위한 정적 규칙들의 생성
o 리소스에 대한 액세스를 위한 동적 규칙들의 생성
● 권한부여된 엔티티에 리소스 액세스 권한을 제공하는 것은 다음을 포함한다.
o 엔티티에 동적 권한부여 규칙들을 전달
o 엔티티가 다양한 레벨들의 권한부여(AuthLevel)를 획득하기 위한 메커니즘들을 제공
o 다양한 유형들의 동적 권한부여(다음 중 하나 이상의 조합)를 제공
· 인증됨(단일 인자, 다중 인자)
· 플랫폼 무결성
· 애플리케이션 또는 디바이스 유형
· 인증되지 않음
· 결제 또는 가입 기반
· 평판 기반
· 바터 기반(데이터/리소스의 교환)
권한부여 규칙들의 프로비저닝
도 14는 정적 및 동적 정책들 모두를 포함하는 정책 관리(프로비저닝, 결정 및 시행) 프레임워크를 보여준다. IoT 서비스 제공자는 동적 권한부여의 도입과 함께 기존의 정적 액세스 정책 관리를 가질 수 있으며, SL-PCF(Service Layer Policy Coordination Function)(1408)는 동적 및 정적 정책들의 조정 및 그 정책들의 시행을 처리할 수 있다. SLDA-PA(904) 및 SLSA-PA(1404) 기능들은 동적 정책들 및 정적 정책들을 각각 프로비저닝한다. SLSA-PA(1404)는 (보안 서버(2)에서) 적합한 PD 정책들뿐만 아니라 각각의 엔티티들(예를 들어, 보안 게이트웨이)에서 PE 정책들을 구성한다.
도 14에 도시된 기능은, 후술되는 도 44c 또는 도 44d에 예시되는 것들 중 하나와 같은, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 또한 이 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 것으로 이해된다.
도 15는 SLDA-PE(910), SLDA-PD(908) 및 SLDA-PI(906) 기능들을 구현하는 엔티티(1502)가 적합한 정책들로 프로비저닝되는 정책 프로비저닝 프로세스를 도시한다. 자세한 메시징은 이하에 제공된다.
적용가능하고 보안이 중요한 곳에서 엔티티와 다른 엔티티 간에 발생하는 모든 통신은 보안 통신 채널을 통해(예를 들어, TLS/SSL 접속을 이용하여) 발생할 수 있으며 종단간 방식으로 보호된다.
도 15의 단계(1)에서, 엔티티(1502)는 PI에 대한 파라미터들뿐만 아니라 PE 및 PD에 관한 적합한 정책 세트의 검색을 요청한다. 검색 프로세스는 주기적으로 트리거링되거나 SLDA-PA(904)를 구현하는 정책 서버(1504)로부터의 대역 내 또는 대역 외 시그널링에 의해 트리거링될 수 있다. 정책 서버(1504)는 디바이스 관리 서버의 서비스들을 호출할 수 있거나 공동 호스팅될 수 있다. 엔티티(1502)는 리소스를 식별하는 임의의 정책-id를 포함시킴으로써 정책들에 대한 요청을 보낸다.
도 15의 단계(2)에서, SLDA-PA(904)는 엔티티(1502)가 정책들을 획득하도록 권한부여하는 기존의 정적 액세스 제어 정책(S-ACP)이 있는지를 체크한다. SLSA(1402)/SLDA(902)-PA는 PA와 관련된 SAPD-PA(904)(정적 권한부여 정책 데이터베이스)를 체크하여 PD/PE 관련 정책들이 엔티티(1502)에 프로비저닝될 권한이 부여되었는지를 체크한다. 엔티티(1502)에 대한 엔트리가 존재하고, 권한부여 레벨이 정책 프로비저닝에 대한 요건을 충족시킨다면, 처리는 단계(10)로 점프한다.
도 15의 단계(3)에서, SAPD에서 엔티티(1502)에 대한 엔트리가 없다면, PA는 엔티티(1502)가 어떻게 권한부여될 수 있는지를 결정하기 위해 동적 권한부여 정책 데이터베이스(DAPD)에 질의한다.
도 15의 단계(4)에서, 정책 서버(1504)는 동적 권한부여 규칙들(DAR)을 포함하는 동적 권한부여 요청(DARequest) 메시지를 수행하도록 엔티티(1502)에 요청한다. 규칙들은 다음을 나타낼 수 있다.
a. 권한부여 레벨
b. 명시적 권한부여 메커니즘들(예를 들어, 인증, 결제/가입, 플랫폼 검증/무결성 체크 등)
도 15의 단계(5)에서, 엔티티(1502)는 대응하는 동적 권한부여 인에이블링 기능들(DAEF)(1802)과 함께 필수 권한부여 체크 프로세스들을 수행하며, 이에 대해서는 이후 섹션에서 상세히 설명된다. 수행된 체크들에 기반하여, 엔티티(1502)는 대응하는 DAEF들로부터 동적 권한부여 파라미터들(DAP)을 획득하거나 엔티티(1502)에 의해 결정되거나 생성될 수 있다. DAP는 디지털 서명(예를 들어, 서명된 권한부여 토큰, 액세스 토큰), 서명되지 않은 메시징(XML 메시징), JSON 데이터 등의 암호화 자격증명일 수 있다. DAP는 다양한 권한부여 체크들의 결과들을 포함하는 파라미터들을 포함할 수 있거나, 또는 권한부여 체크들 각각이 별도의 DAP를 초래할 수 있다.
도 15의 단계(6)에서, 엔티티(1502)는 동적 권한부여 응답(DAResponse) 메시지를 이용하여 DAP(들)를 정책 서버(1504)/PA에 보낸다.
도 15의 단계(7)에서, 정책 서버(1504)/DA는 DAP들을 검증하고 DAR이 충족되었는지를 보장하기 위해 체크한다.
도 15의 단계(8)에서, 정책 서버(1504)는 엔티티-id, res-id, 허용된 동작(예를 들어, 검색), DAP를 식별하는 DAP-Id, 및 허용된 권한부여의 지속기간을 포함하도록 정적 정책(SAPD)을 업데이트한다.
도 15의 단계(9)에서, SAPD-PA는 PE-규칙들, PA-규칙들 및 PI-데이터뿐만 아니라 AAR(Approved Authorization Rules)을 프로비저닝한다. AAR은 다음에 관한 정보를 포함할 수 있다.
a. 권한부여 레벨(AuthLevel) 달성
b. 수행될 수 있는 동작들의 유형(생성/업데이트/검색/삭제)
c. 동작들이 수행될 수 있는 리소스/리소스 트리
d. 권한부여 기간(유효 기간/만료 기간)
e. AuthLevel을 향상시키기 위해 수행되어야 하는 메커니즘들의 리스트
f. 절대 수행될 수 없는 리소스/동작들
도 15에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 15에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 15에 도시된 단계들을 수행한다. 또한, 도 15에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
리소스 특정 권한부여 규칙들의 생성
리소스 생성자 또는 소유자일 수 있는 엔티티(엔티티 A(1602))는 리소스 호스팅 기능(RHF)(1604) 상으로 데이터의 호스팅을 요청한다. RHF(1604)는 SLDA 기능들(PE, PD 및 PI)을 구현할 수 있다. 엔티티들과 관련된 권한부여 규칙들에 관한 모든 정책들이 사전 프로비저닝되어 SAPD에 채워지고, 동적 정책들이 6.3.1에 설명된 메커니즘들을 기반으로 DAPD에 프로비저닝된다고 가정한다. 예시적인 도 16에 대한 메시징 세부사항들은 다음과 같다.
도 16의 단계(1)에서, 관련 정적 ACP(S-ACP) 및 동적 ACP(D-ACP)와 함께 관련 리소스-id를 갖는 리소스(TempReading1)의 호스팅/생성을 요청하는 엔티티는 리소스 등록 요청(RRRequest) 메시지의 일부로서, SLDA를 구현하는 RHF(1604)에 보내진다.
도 16의 단계(2)에서, RHF(1604)는 엔티티 A(1602)가 SAPD로 수행된 체크들에 기반하여 권한부여를 갖는지를 체크한다. 엔트리가 있으면, 메시징은 단계(9)로 건너 뛴다.
도 16의 단계(3)에서, 엔티티로부터의 요청에 대해 S-ACP가 일치하지 않으면, RHF(1604)는 DAPD로부터 동적 권한부여 규칙들을 획득한다.
도 16의 단계(4)에서, RHF(1604)는 동적 권한부여 요청(DAR) 메시지를 이용하여 규칙들(DAR)을 엔티티 A(1602)에 보낸다.
도 16의 단계(5)에서, 엔티티 A(1602)는 RHF(1604)로부터 획득된 DAR에 기반하여 다양한 권한부여 체크들을 수행한다. 엔티티 A(1602)는 권한부여 체크들을 보증하는 DAP(들)를 획득/생성한다.
도 16의 단계(6)에서, 엔티티 A(1602)는 DAResponse 메시지를 이용하여 DAP를 RHF(1604)로 보낸다.
도 16의 단계(7)에서, RHF(1604)는 DAP(들)에 대한 체크들을 수행하고 DAP가 DAR과 일치하는지를 검증한다.
도 16의 단계(8)에서, DAP(들)가 성공적으로 검증되면, SAPD는 엔티티-id, 허용된 동작들, 액세스가능한 리소스들, DAP-Id(들), 유효성 등을 나타내는 적합한 값들로 채워진다.
도 16의 단계(9)에서, RHF(1604)는 엔티티 A(1602) 리소스를 등록 및 생성하고 S-ACP 및 D-ACP를 엔티티 A(1602) 리소스와 관련시킨다.
도 16의 단계(10)에서, RHF(1604)는 AAR을 포함하는 RRResponse를 전달한다.
도 16에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 16에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 16에 도시된 단계들을 수행한다. 또한, 도 16에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
권한부여된 액세스 프로세스
도 17은 RHF(1604) 상에 호스팅되는 리소스에 액세스하기를 원하는 클라이언트(1702)를 도시한다. RHF(1604)는 SLDA-PE(910), PI, PD 기능들을 구현하며 또한 PA 기능도 호스팅한다. 따라서, 시스템 관리자는 PA에 의해 RHF(1604)의 인터페이스를 이용하여 PE 및 PD 정책들을 구성할 수 있다. 메시지 흐름은 도 16에 도시되고 6.3.2에서 설명된 이전 흐름의 연속으로 볼 수 있다. 메시징 세부사항들은 다음과 같다.
도 17의 단계(1)에서, 클라이언트(1702)는 리소스-id, 리소스의 임의의 이름 및 요청된 동작의 유형을 포함하는 리소스 액세스 요청(RARequest) 메시지를 보낸다. 또한, 이는 명시적으로 임의의 특정한 지속 시간 동안 리소스에 대한 요청일 수 있다.
도 17의 단계(2)에서, S-ACP에 기반한 RHF(1604)는 클라이언트(1702)가 권한부여되는지 여부를 결정한다. 권한부여되면, 메시징은 단계(10)로 건너 뛴다.
도 17의 단계(3)에서, 클라이언트(1702)가 권한부여되지 않으면, RHF(1604)는 동적 권한부여 정책들(D-ACP)을 결정하고 DAR을 생성한다. RARequest 내에 "지속기간" 값이 존재하면, D-ACP는 "지속기간" 값을 충족시키도록 조정될 수 있다. 지속기간 "값"이 임계 값보다 높으면, 더 높은 레벨의 권한부여가 수행되어야 할 수도 있다.
도 17의 단계(4)에서, RHF는 DAR을 포함하는 DARequest를 보낸다.
도 17의 단계(5)에서, 클라이언트(1702)는 DAR을 만족시키기 위해 적합한 DAEF들로 적합한 권한부여 체크들을 수행한다. 클라이언트(1702)는 다양한 체크들을 보증하는 DAP(들)를 획득하거나 생성한다.
도 17의 단계(6)에서, 클라이언트(1702)는 DAP(들)를 포함하는 DAResponse 메시지를 이용하여 RHF(1604)에 DAP(들)를 보낸다.
도 17의 단계(7)에서, RHF(1604)는 DAP들을 검증하고 DAR에 비교한다.
도 17의 단계(8)에서, DAP들이 DAR의 요건들을 충족시키면, RFH는 클라이언트-id, res-id, op, 지속기간, DAP-Id(들)로 SAPD를 업데이트할 수 있다.
도 17의 단계(9)에서, RHF(1604)는 리소스 및 AAR을 포함하는 RAResponse 메시지를 보낸다.
도 17에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 17에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 17에 도시된 단계들을 수행한다. 또한, 도 17에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
분산 정책 엔티티들 및 권한부여 모델들
도 16 및 도 17과 관련하여, PD 및 PE와 같은 정책 기능들은 동일한 엔티티(예를 들어, RHF(1604)) 상에 호스팅되었다. 본 명세서에서는 SLDA-PD(908)/SLDA-PI가 동일한 엔티티 상에 호스팅될 수 있는 반면에, SLDA-PE(910)는 RHF(1604) 상에 호스팅되는 메커니즘들을 제공한다. 또한, 다양한 권한부여 모델들을 지원하는 솔루션들에 대해 살펴본다.
푸시(PUSH) 모델
푸시 모델은 RHF(1604)가 제약된 엔티티이고, 클라이언트(1702)가 제약되지 않거나 제약이 덜한 디바이스인 것으로 가정할 때 적합할 수 있다. 전술한 바와 같이, 고도의 보안을 필요로 하는 모든 통신들은 기밀성, 무결성 및 인증을 위해 보호되는 보안 통신 채널을 통해(예를 들어, TLS/SSL을 이용하여) 전송될 수 있다. 도 18은 푸시 모델을 이용한 리소스 액세스를 도시한다. 메시징 세부사항들은 다음과 같다.
도 18의 단계(0)에서, 클라이언트(1702)는 클라이언트(1702)가 리소스에 액세스할 수 있도록 클라이언트(1702)에게 권한부여할 수 있는 SLDA-PD(908) 및 리소스와 관련 리소스-id를 발견한다고 본 명세서에서 가정한다.
도 18의 단계(1)에서, 클라이언트(1702)는 클라이언트-id 및 리소스-id(Res-id)를 포함하는 DARequest를 보낸다.
도 18의 단계(2)에서, 프로비저닝된 규칙들에 기반한 SLDA-PD(908)는 클라이언트-id에 의해 식별된 클라이언트(1702)가 Res-id에 의해 식별된 리소스에 액세스하게 하는 동적 권한부여 정책들을 획득한다. PD는 몇몇 사례들에서 클라이언트-Id 및 Res-id를 기반으로 동적 권한부여 정책들을 생성해야 할 수 있다.
도 18의 단계(3)에서, PD는 각각의 DAEF(1802)와 관련된 URI의 리스트 및 또한 각각의 권한부여 체크와 관련된 권한부여 레벨(AuthLevel)의 리스트를 포함하는 권한부여 체크 요청(ACRequest)을 보낸다. AuthLevel의 예가 이하에 제공된다.
a. 인증: AuthLevel = 높음/보통/낮음
b. 플랫폼 무결성/유효성: AuthLevel = 높음/보통/낮음
c. 가입: AuthLevel = 플래티넘/골드/실버
d. 평판: AuthLevel = 높음/보통/낮음
도 18의 단계(4)에서, 클라이언트(1702)는 6.3.4.2에서 좀 더 상세히 설명되는 권한부여 체크 프로세스들(ACProcess)을 수행한다. 클라이언트(1702)는 제공되는 DAEF(1802) 리스트 및 각각의 체크와 관련된 AuthLevel에 기반하여 다중 인자 권한부여 서버, 결제 서버, 플랫폼 검증 서버 등을 이용하여 체크들을 수행할 수 있다. 이 프로세스는 대역 내 프로세스일 수 있거나 대역 외에서 수행될 수 있다. 익명의 액세스가 요청될 때에는 특히 인증을 건너 뛰는 시나리오들 및 이용 사례들에 기반할 수 있다.
도 18의 단계(5)에서, ACProcess의 결과로서, 다수의 권한부여 체크 값들(ACV들)이 생성될 수 있으며, 이 값은 권한부여 체크 각각을 확인하는 원시 데이터이다. 또한, 임의적으로 DAP가 각각의 권한부여 체크에 대해 생성될 수 있다. DAP는 권한부여 체크를 보증하며, 이 권한부여 체크는 권한부여에 필요한 관련 정보만을 포함하는 ACV들의 압축된 버전으로 볼 수 있다. 클라이언트(1702)는 ACV들/DAP들을 PD에 보낸다.
도 18의 단계(6)에서, PD가 진위, 무결성 및 정확성에 대해 ACV들/DAP를 검증하면, PD는 모든 DAP들을 디지털 서명된 단일의 C-DAP로 통합하거나 각각의 DAP에 디지털 서명하여 이를 클라이언트(1702)에게 전달할 수 있다.
도 18의 단계(7)에서, 클라이언트(1702)는 Res-id, op 및 DAP(들)를 포함하는 RARequest를 생성하고 RHF(1604)로 보낸다.
도 18의 단계(8)에서, 클라이언트(1702)가 DAP(들)를 보냈기 때문에, PE를 구현하는 RHF(1604)는, 정적 정책들에서 엔트리가 없을 수 있으므로 SAPD-PE를 체크하지 않으며, DAPD-PE에서 D-ACP를 체크함으로써 DAP(들)가 res-id와 관련된 동적 권한부여 정책들의 요건들과 일치하는지를 대신 체크한다.
도 18의 단계(9)에서, DAP(들)가 권한부여 요건들을 충족시키는 경우, PE는 클라이언트-id, res-id, op(들), 지속기간, DAP-Id(들), 임의적인 DAP(들)로 SAPD-PE를 업데이트한다. DAP들은 그 크기가 크고 관리하기 까다로울 수 있기 때문에 DAP-Id에 의해 별도로 식별되어 저장될 수 있다.
도 18의 단계(10)에서, RHF(1604)는 관련 AAR뿐만 아니라 리소스를 클라이언트(1702)에 보낸다.
도 18에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 18에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 18에 도시된 단계들을 수행한다. 또한, 도 18에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
권한부여 체크 프로세스(ACProcess)
도 19는 결제 프로세스를 포함한 프로세스를 포함하는 ACProcess를 도시한다. 클라이언트(1702)가 DAEF-결제 서버를 인식하지 못할 수 있지만, 클라이언트(1702)는 DAEF-결제 서버를 신뢰하는 SLDA-PD(908)를 신뢰한다. 메시징 세부사항들은 다음과 같다.
도 19의 단계(4a)에서, 클라이언트(1702)는 DAEF-결제에 대한 결제 권한부여를 요청한다. 클라이언트(1702)는 SLDA-PD(908)에 의해 리다이렉트될 수 있거나 또는 SLDA-PD(908)에 의해 또는 클라이언트(1702)에 의해 발견되는 DAEF-결제 서버의 URI가 제공된다. 클라이언트(1702)는 PaymentRequest를 수행하고 결제를 위한 통화 및 금액(예를 들어, 가상 통화), 거래들을 SLDA-PD ACRequest와 연결시키는 Request-Id를 제공한다.
도 19의 단계(4b)에서, DAEF(1802)는 PaymentTransaction 프로세스를 개시하며, 그 금액은 클라이언트(1702)에 의해 DAEF(1802)에 보내진다.
도 19의 단계(4c)에서는 거래를 상세화하고 DAP를 임의로 생성할 수 있는 ACV를 생성하여 결제 및 거래의 검증을 제공한다. 결제 DAP는 JSON 데이터, XML, CBOR 데이터, 명시적 메시지, JSON 웹 토큰 등을 이용하여 표현될 수 있다. DAP-결제의 선호되는 콘텐츠들의 리스트가 이하에 제공된다.
● 거래-Id: 542912379542395
● 요청-Id:
● 환매인-Id: SLDA-PD-URI
● 날짜: 2015년 11월 13일
● 시간: 23시 23분
● 발행인: DAEF-결제-URI
● 발행 대상: 클라이언트
● 통화: 비트코인
● 금액: 100.00
● 발행인의 디지털 서명: D28B45BA234C452DB.....
도 19의 단계(4d)에서, DAEF(1802)는 DAP/ACV를 클라이언트(1702)에 전달한다. 임의적으로, DAP-Id만이 DAEF-결제에 의해 클라이언트(1702)에 제공된다.
도 19의 단계(5)에서, 클라이언트(1702)는 DAP 및 임의적인 ACV를 포함하는 ACResponse를 SLDA-PD에 보낸다. 이 메시지는 DAEF(1802)에 의해 SLDA-PD(908)에 리다이렉트될 수 있거나 클라이언트(1702)에 의해 보내진다. SLDA-PD(908)는 거래-id, 결제 정보, 요청-Id 및 다른 관련 정보를 등록하고 적합한 권한부여 확인을 제공한다. SLDA-PD(908)는 결제 DAP가 클라이언트(1702)에 의해 재생되지 않는다는 것을 보장해야 한다. DAP-Id만이 클라이언트(1702)에 의해 제공되었다면, SLDA-PD(908)는 DAEF(1802)로부터 DAP를 가져와야 하고, 일단 검증되면, DAEF(1802)가 결제가 완료되었다고 간주한다는 것을 의미하는 "만족"으로서 거래하게 하며 신용 거래는 재이용될 수 없다.
도 19에 대해 전술한 권한부여 체크 프로세스가 결제 권한부여를 다루지만, 유사한 메커니즘들을 이용하여 다른 권한부여 체크들(예를 들어, 다중 인자 인증, 플랫폼 검증, 가입 등)을 수행할 수 있음에 유의해야 한다. 도 19의 단계(4b)는 다른 권한부여 체크들을 수행하는데 이용되는 클라이언트와 대응하는 DAEF(들) 간의 메시지(들)로 대체될 수 있다. 또한, OpenID, OpenID-Connect, EAP, SAML 등과 같은 프로토콜 프레임워크들을 활용하고 본 명세서에서 설명된 메커니즘들을 기존의 프로토콜 프레임워크들에 피기백함으로써 권한부여 체크들을 수행할 수 있다.
도 19에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 19에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 19에 도시된 단계들을 수행한다. 또한, 도 19에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
풀(PULL) 모델
제약된 클라이언트(1702)는 리소스에 대한 액세스를 요청하고 RHF(1604)에 의해 촉진되는 권한부여를 수행할 수 있다. 메시징 세부사항들은 도 20과 관련하여 이하에 제공된다.
도 20의 단계(1)에서, 클라이언트(1702)는 RRRequest를 이용하여 Res-Id, op="검색"에 의해 식별된 리소스에 대해 RHF(1604)에 요청한다. RHF(1604)는 SLDA-PE(910) 기능을 구현한다.
도 20의 단계(2)에서, RHF(1604)는 클라이언트(1702)가 정적 SAPD-PE를 체크함으로써 권한부여되었는지를 검증하기 위해 S-ACP를 체크한다. 클라이언트(1702)가 리소스에 대한 동작을 수행하도록 권한부여되면, 메시징은 단계(12)로 점프한다.
도 20의 단계(3)에서, SLDA-PE(910)는 동적 권한부여 정책들을 체크하고 DAR을 결정한다.
도 20의 단계(4)에서, SLDA-PE(910)는 DAR, 클라이언트-Id 및 Res-Id를 포함하는 DARequest를 생성하고 이를 SLDA-PD에 보낸다. 대안적으로, PE는 달성될 것으로 예상되는 권한부여 체크들의 명시적 리스트 ACList[] 및 관련된 AuthLevel[]을 제공한다.
도 20의 단계(5)에서, SLDA-PD(908)는 권한부여들이 수행되고 AuthLevel들이 달성되도록 접촉되어야 할 DAEF들을 결정한다.
도 20의 단계(6)에서, SLDA-PD(908)는 클라이언트-Id 및 관련된 AAL을 포함하는 ACRequest를 DAEF들 각각에 보낸다.
도 20의 단계(7)에서, 클라이언트(1702) 및 DAEF들 각각은 권한부여 체크(예를 들어, 결제, 플랫폼 검증, 인증 등) 각각에 대해 6.3.3에 설명된 ACProcess를 수행한다. 클라이언트(1702)와 DAEF들 각각 간의 메시징은 RHF(1604)를 통한 대역 내 또는 대역 외 메시징 또는 직접적인 방식의 다른 수단에 의해 수행될 수 있다.
도 20의 단계(8)에서, ACProcess, DAEF들 각각은 ACV들/DAP들을 SLDA-PD에 보낸다.
도 20의 단계(9)에서, SLDA-PD(908)는 ACV들/DAP들 각각을 검증하고, DAEF(1802) 각각으로부터의 개별적인 DAP 각각에 제공된 정보를 포함하고, SLDA-PD(908)에 의해 디지털 서명되며, DAResponse를 이용하여 RHF(1604)에 보내지는 통합 DAP(C-DAP)를 임의적으로 생성한다. 대안적으로, SLDA-PD(908)는 통합 또는 서명 없이 DAP 각각을 보낸다.
도 20의 단계(10)에서, SLDA-PE(910)는 DAP(들)를 검증하고 DAP가 리소스와 관련된 D-ACP와 일치하는지를 확인한다.
도 20의 단계(11)에서, DAP(들)가 요건들과 일치하면, SLDA-PE(910)는 SAPD-PE(910) 내의 정적 액세스 정책들을 클라이언트-Id, Res-Id, op, 지속기간, DAP-Id(들), DAP(임의적임)로 업데이트한다.
도 20의 단계(12)에서, SLDA-PE(910)/RHF(1604)는 리소스 및 AAR을 클라이언트에 보낸다.
도 20에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 20에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 20에 도시된 단계들을 수행한다. 또한, 도 20에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
푸시 확인 모델
푸시 확인 모델에서는, 푸시 모델과 매우 유사하게 이어진다. 메시징 세부사항들은 예시된 도 21을 반영하여 이하에 제공된다.
도 21의 단계(1)에서, 클라이언트(1702)는 Res-Id, 클라이언트-Id, op를 포함하는 DARequest를 요청한다.
도 21의 단계(2)에서, SLDA-PD(908)는 클라이언트-Id, Res-Id 및 op에 기반하여 D-ACP의 올바른 세트를 결정한다.
도 21의 단계(3)에서, SLDA-PD(908)는 DAEF-URI[]의 리스트 및 관련된 AAL[]을 포함하는 ACRequest를 보낸다.
도 21의 단계(4)에서, 클라이언트(1702)는 DAEF들 각각 및 각각의 권한부여 체크와 관련된 AAL에 기반하여 ACProcess를 수행한다. 클라이언트(1702)는 ACV-Id들 및/또는 DAP-Id들이 프로비저닝되지만 ACV들 또는 DAP들이 프로비저닝되지는 않는다.
도 21의 단계(5)에서, 클라이언트(1702)는 ACResponse를 이용하여 ACV-Id들 및/또는 DAP-Id들을 SLDA-PD(908)에 전달한다.
도 21의 단계(6)에서, SLDA-PD(908)는 ACV-Id 및/또는 DAP-Id를 포함하는 DAEF(1802) 각각으로 ACV-요청을 수행한다.
도 21의 단계(7)에서, DAEF들은 ACV-응답 메시지를 이용하여 대응하는 ACV들 및/또는 DAP들로 응답한다.
도 21의 단계(8)에서, SLDA-PD(908)는 ACV[] 및/또는 DAP[]를 포함하는 DAP 생성 요청(DAPGRequest) 메시지에 의해 C-DAP의 생성을 DAP 생성기 기능(DGF)(2102)에 요청한다.
도 21의 단계(9)에서, DGF(2102)는 ACV[] 및/또는 DAP[]에 기반하여 C-DAP 및 관련된 C-DAP-Id를 생성하고 이를 DAP 데이터베이스(DAP-D) 내에 저장한다.
도 21의 단계(10)에서, DGF(2102)는 C-DAP-Id를 SLDA-PD에 보낸다.
도 21의 단계(11)에서, SLDA(902)는 DAResponse 메시지를 이용하여 C-DAP-Id를 클라이언트(1702)에 보낸다.
도 21의 단계(12)에서, 클라이언트(1702)는 Res-Id, op, 클라이언트-Id, C-DAP-Id를 포함하는 RARequest를 RHF(1604)에 수행한다.
도 21의 단계(13)에서, RHF(1604)는 DAPRequest 메시지를 이용하여 DGF(2102)에 C-DAP-Id를 보낸다.
도 21의 단계(14)에서, DGF(2102)는 RHF(1604)를 C-DAP에 프로비저닝하기 전에 RHF(1604)의 권한부여를 검증할 수 있다.
도 21의 단계(15)에서, RHF(1604)는 D-ACP로 C-DAP를 검증한다.
도 21의 단계(16)에서, C-DAP가 권한부여 요건들을 충족시키면, RHF(1604)는 SAPD-PE를 클라이언트-Id, Res-Id, op, 지속기간, C-DAP-Id 및 C-DAP(임의적임)로 업데이트한다.
도 21의 단계(17)에서, RHF(1604)는 리소스 및 AAR을 클라이언트(1702)에 보낸다.
도 21에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 21에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 21에 도시된 단계들을 수행한다. 또한, 도 21에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
간접 푸시
도 22는 간접 푸시 모델에 기반한 권한부여를 도시한다. 메시징 세부사항들은 다음과 같다.
도 22의 단계들(1-4)은 도 21에서의 단계들과 동일하다.
도 22의 단계(5)에서, 클라이언트(1702)는 수행되는 각각의 권한부여 체크에 대해 ACV[] 및/또는 DAP[]를 획득/생성하고 ACV들 및 DAP들을 포함하는 ACResponse를 SLDA-PD(908)에 보낸다.
도 22의 단계(6)에서, SLDA-PD(908)는 ACV[] 및/또는 DAP[]를 검증하고, 허용가능한 경우 SLDA-PD(908)는 C-DAP를 생성한다.
도 22의 단계(7)에서, SLDA-PD(908)는 C-DAP를 포함하는 DAP 프로비저닝(DAPProvisioning) 메시지를 RHF(1604)에 보낸다. RHF(1604)의 URI는 클라이언트(1702)에 의해 제공된 Res-Id에 기반하여 결정된다.
도 22의 단계(8)에서, RHF(1604)(SLDA-PE)는 C-DAP를 검증하고 C-DAP가 리소스와 관련된 D-ACP의 요건들을 충족시키는지를 확인한다. SDPA-PE는 C-DAP를 DAP-Db에 저장한다.
도 22의 단계(9)에서, SLDA-PE(910)는 권한부여의 "지속기간"이 authorization_duration_threshold를 초과하는 경우에 ACP 데이터베이스(SAPD-PE)에 엔트리를 생성한다. 따라서, 동적 권한부여 체크(들)는 권한부여 지속기간이 매우 길게 제공되는 정적 권한부여 규칙을 생성하게 한다.
도 22의 단계(10)에서, DAP가 허용가능하면, SLDA-PE(910)는 "성공" 메시지를 포함하는 DAPResponse 메시지를 보낸다.
도 22의 단계(11)에서, SLDA-PD(908)는 "성공" 메시지를 포함하는 DAResponse 메시지를 클라이언트(1702)에 보낸다.
도 22의 단계(12)에서, SLDA-PD(908)로부터 "성공" 메시지를 수신하면, 클라이언트(1702)는 Res-Id, op, 클라이언트-Id를 포함하는 RARequest를 개시한다.
도 22의 단계(13)에서, SLDA-PE(910)는 SAPD-PE에서 정적 S-ACP를 체크하고 일치한 것을 찾는다.
도 22의 단계(14)에서, RHF(1604)는 리소스 및 AAR을 클라이언트(1702)에 보낸다.
도 22에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 22에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 22에 도시된 단계들을 수행한다. 또한, 도 22에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
oneM2M 서비스 계층 동적 권한부여 실시예
다음 하위 절들에서는 oneM2M 시스템이 본 개시 내용에서 제안된 SLDA 기능을 지원할 수 있도록 하는 아키텍처, 리소스 및 절차 레벨 향상들을 제안한다.
제안된 oneM2M 향상들에 대한 요약은 다음을 포함한다.
1) SLDA 기능이 호스팅될 수 있는 oneM2M 엔티티들의 유형들(예를 들어, MEF(2304), MAF(2302) 및 CSE들)을 보여주는, oneM2M 시스템 내에서의 SLDA 기능의 아키텍처 레벨 실시예
2) 권한 리스트 내의 개별적인 권한의 부분 주소지정을 가능하게 하는 권한 리스트 내의 개별적인 권한에 대한 식별자, 각각의 개별적인 권한에 대한 만료 시간, 및 결제 기반, 바터 기반, 평판 기반 및 보안 평가 기반의 동적 권한부여를 포함하는 이용 사례들을 지원하는 권한부여 컨텍스트의 새로운 유형들의 정의를 포함하기 위한, 기존의 oneM2M 정의 <accessControlPolicy> 리소스에 대한 몇몇 제안된 향상들
3) 서비스 계층 동적 권한부여 정책들의 구성을 지원하기 위한 oneM2M <dynAuthPolicy> 리소스 및 속성들의 정의
4) 수행될 명시적 요청의 동적 권한부여를 지원하기 위한 oneM2M <dynAuthRequest> 리소스와 대응하는 요청 및 응답 메시지 포맷들의 정의
5) 수행될 명시적 요청의 동적 권한부여를 협의하는 능력을 지원하기 위한 oneM2M <consult> 리소스와 대응하는 요청 및 응답 메시지 포맷들의 정의
6) 상이한 유형들의 동적 권한부여 기능이 oneM2M 시스템 내에서 어떻게 지원될 수 있는지에 대한 메시지 시퀀스 레벨의 설명들을 제공하는 몇 가지 oneM2M 절차들의 정의
oneM2M 서비스 계층 동적 권한부여 아키텍처
본 개시 내용에서 제안된 SLDA 기능(902)은 도 23에 도시된 바와 같이 CSE, MEF(2304) 또는 MAF(2302)를 포함하는 다양한 oneM2M 정의 엔티티들 상에서 임의적으로 호스팅될 수 있다. SLDA 기능(902)은 이들 oneM2M 정의 엔티티들 중 하나에서 그 전체로서 중앙집중화되어 호스팅될 수 있거나, 대안적으로, SLDA 기능(902)은 그 하위 기능들(SLDA-PA, SLDA-PD(908), SLDA-PE(910) 및 SLDA-PI)이 도 24에 도시된 바와 같이 복수의 oneM2M 엔티티들에 걸쳐 분산된 방식으로 호스팅될 수 있다. 예를 들어, SLDA-PI 하위 기능은 MEF(2304) 상에 호스팅되고, SLDA-PD(908) 및 SLDA-PA(904) 하위 기능들은 MAF(2302) 상에 호스팅되며, SLDA-PE(910) 하위 기능은 CSE 상에 호스팅될 수 있다. 분산된 방식으로 호스팅될 때, SLDA(902) 하위 기능들은 동적 권한부여 기능들을 수행하기 위해 서로 조정될 수 있다.
도 23 및 도 24에 도시된 기능은 이하에 설명되는 도 44c 또는 도 44d에 도시된 것들 중 하나와 같은 M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 것으로 이해된다.
oneM2M 서비스 계층 동적 권한부여 리소스들
리소스 구조들을 설명하는 그래픽 표현은 다음과 같다.
● 사각형 상자들은 리소스들 및 자식 리소스들에 이용된다.
● 타원들은 속성들에 이용된다.
● "<" 및 ">"으로 구분된 리소스 이름들은 리소스 생성 중에 할당된 리소스의 이름을 나타낸다.
● 하이라이트된 리소스들 및 속성들은 SLDA 기능을 지원하기 위해 본 개시 내용에 의해 제안된 새로운 리소스들 및 속성들이다.
<dynAuthPolicy> 리소스
도 25에 도시된 제안된 <dynAuthPolicy> 리소스는 동적 권한부여 규칙들로 SLDA 기능(902)을 구성하기 위한 인터페이스로서의 역할을 할 수 있다. 이 리소스는 SLDA(902) 정책들을 생성, 검색, 업데이트 및 삭제하는데 이용될 수 있다. 하나 이상의 <dynAuthPolicy> 리소스로 구성되면, SLDA 기능(902)은 동적 권한부여 결정을 수행하기 위해 정책들 내에 정의된 규칙들을 이용할 수 있다.
협의 기반, 결제 기반, 바터 기반, 보안 평가 기반 및 평판 기반의 정책들을 포함하는 다양한 유형들의 동적 권한부여 규칙들이 지원될 수 있지만, 본 개시 내용에 의해 정의되는 것들에 국한되지는 않는다. oneM2M 시스템에서 규칙들 각각을 표현하는 방법에 대해서는 아래의 하위 절들에서 더 상세히 추가로 설명된다.
동적 권한부여 규칙들에 추가하여, <dynAuthPolicy> 리소스는 selfAccessControlPolicyIDs 속성을 또한 지원할 수 있다. 이 속성은 <dynAuthPolicy> 리소스 자체에 대한 액세스 권한들을 정의하는 액세스 제어 정책들을 참조하는데 이용될 수 있다. 이러한 권한들은 어떤 엔티티들이 <dynAuthPolicy> 리소스 및 그 속성들에 액세스(예를 들어, 검색, 업데이트 또는 삭제)하도록 허용되는지를 제어하는데 이용될 수 있다.
임의적으로, <dynAuthPolicy> 리소스는 이 <dynAuthPolicy> 리소스를 이용하여 SLDA 기능(902)이 동적으로 생성, 업데이트 또는 삭제할 수 있는 정적 권한들이 있는 하나 이상의 <accessControlPolicy> 리소스에 대한 연결들의 리스트로 구성될 수 있는 accessControlPolicyIDs 속성을 또한 지원할 수 있다.
표 1 - <dynAuthPolicy> 리소스의 속성들
<accessControlPolicy> 리소스들을 <dynAuthPolicy> 리소스와 명시적으로 연결하기 위해 accessControlPolicyIDs 속성을 이용하는 제안된 명시적 방법을 이용하는 대신에, 암시적 방법이 여러 이용 사례 실시예들을 통해 이하에서 또한 정의된다.
예를 들어, 도 26에 도시된 바와 같이, dynAuthPolicyIDs 속성은 기존의 oneM2M 리소스들(예를 들어, <container> 리소스)에 추가될 수 있다. 이 속성은 accessControlPolicyIDs 속성을 이용하여 <accessControlPolicy>와 oneM2M 리소스를 연결하기 위한 oneM2M의 현재 지원과 유사한 방식으로 oneM2M 리소스를 <dynAuthPolicy> 리소스와 연결하는데 이용될 수 있다. SLDA 기능(902)은 <accessControlPolicy> 리소스들이 oneM2M 리소스에 의해 지원되는 accessControlPolicyIDs 및 dynAuthPolicyIDs 속성들을 간단히 이용하여 <dynAuthPolicy> 리소스들에 의해 관리될 수 있는지를 차례로 결정할 수 있다. 예를 들어, 도 26에 도시된 <container> 리소스에 액세스하기 위한 요청이 이루어진 경우, 컨테이너의 accessControlPolicyIDs 속성에 의해 참조되는 <accessControlPolicy>가 요청자가 원하는 동작을 수행하도록 허용하는 권한을 가졌는지 여부를 결정하기 위한 체크가 먼저 수행될 수 있다. 권한을 가졌다면, 요청은 진행하도록 허용될 수 있으며, 동적 권한부여는 필요하지 않을 것이다. 그러나, 요청자가 적합한 권한들을 가지지 않았다면, SLDA 기능(902)은 동적 권한부여를 시도하고 수행하도록 트리거링될 수 있다. SLDA 기능(902)는 <container> 리소스가 유효한 <dynAuthPolicy> 리소스에 연결하도록 구성된 dynAuthPolicyIDs 속성을 가졌는지 여부를 먼저 체크할 수 있다. dynAuthPolicyIDs 속성을 가졌다면, SLDA 기능(902)은 dynAuthRules 속성에 액세스하여 이를 이용하여 요청자 권한들을 승인 또는 거부할지 여부를 결정할 수 있다. 또한, privilegeLifetime 속성을 이용하여 이 요청에 대해서만 또는 향후의 요청들에 대해서도 권한들을 승인할지 여부를 결정할 수 있다. 향후의 요청들이 있으면, <container>에 의해 연결된 <accessControlPolicy> 리소스(들) 내의 정적 권한들을 업데이트할 수 있다. SLDA 기능(902)은 <accessControlPolicy> 리소스(들) 연결의 권한들을 컨테이너의 accessControlPolicyIDs 속성에 의해 업데이트함으로써 이를 수행할 수 있다.
대안으로, <dynAuthPolicy> 리소스는 도 27에 도시된 바와 같이 <accessControlPolicy> 리소스의 자식 리소스로서 대신 생성될 수 있다. 요청자가 목표로 한 리소스에 대해 원하는 동작을 수행하기 위한 충분한 권한들을 가지지 않았다고 발견되었다면/되었을 때, SLDA 기능(902)은 대응하는 <accessControlPolicy> 리소스가 <dynAuthPolicy> 자식 리소스를 가졌는지 여부를 체크할 수 있다. 대응하는 <accessControlPolicy> 리소스가 <dynAuthPolicy> 자식 리소스를 가졌다면, SLDA 기능(902)은 <dynAuthPolicy> 자식 리소스에 의해 지정된 규칙들에 기반하여 요청자에게 적합한 권한들을 동적으로 승인할 수 있는지 여부를 체크할 수 있다.
다른 대안으로, dynAuthPolicyIDs 속성은 도 28에 도시된 바와 같이 <accessControlPolicy> 리소스에 대신 추가될 수 있다. 요청자가 목표로 한 리소스에 대해 원하는 동작을 수행하기 위한 충분한 권한들을 가지지 않았다고 발견되었다면/되었을 때, SLDA 기능(902)은 대응하는 <accessControlPolicy> 리소스가 dynAuthPolicyIDs 속성을 구성했는지 여부를 체크할 수 있다. 대응하는 <accessControlPolicy> 리소스가 dynAuthPolicyIDs 속성을 구성했다면, SLDA 기능(902)은 대응하는 <dynAuthPolicy> 리소스들을 참조하여 <dynAuthPolicy> 자식 리소스들에 의해 지정된 규칙들에 기반하여 요청자에게 적합한 권한들을 동적으로 승인할 수 있는지 여부를 체크할 수 있다.
다른 대안으로, 새로운 <dynAuthPolicy> 리소스를 정의하는 대신에, 제안된 속성들은 기존의 <accessControlPolicy> 리소스에 대신 추가될 수 있다.
<dynAuthRequest> 리소스
이 개시 내용은 도 30에 도시된 바와 같이 <dynAuthRequest> 리소스를 또한 정의한다. 이 리소스는 (도시된 바와 같이) 속성들을 갖지 않은 가상 리소스로서 정의될 수 있거나, 속성들(도시되지 않음)을 갖는 보통의 리소스로서 정의될 수 있다. 이것은 SLDA 기능(902)에 명시적 동적 권한부여 요청을 발행하여 하나 이상의 원하는 리소스 또는 서비스와 제휴된 <accessControlPolicy> 권한들에 동적으로 추가되는 특정한 유형들의 액세스 권한들을 요청하는데 이용될 수 있다. 이 리소스는 요청자가 원하는 리소스 또는 서비스에 대한 적합한 액세스 권한들이 없고 자체 승인하기 위해 액세스 제어들을 업데이트하기 위한 권한들이 또한 없는 시나리오들에서 유용할 수 있다. 이 경우, 요청자는 <dynAuthRequest> 리소스를 이용하여 SLDA 기능(902)에 명시적 요청을 보내어 원하는 액세스 권한들을 시도하고 획득할 수 있다. 성공적이면, SLDA 기능(902)은 목표로 한 리소스(들) 또는 서비스(들)에 대한 액세스 제어 정책(들)을 업데이트하여 요청된 권한들을 추가하고 요청자에게 상태를 회신할 수 있다. 성공적이면, 요청자는 이후에 원하는 리소스 또는 서비스에 액세스하기 위한 요청들을 발행할 수 있으며 액세스를 수행하기 위한 적합한 권한들을 가질 것이다.
<dynAuthRequest> 리소스는 oneM2M 리소스 트리 계층의 다양한 레벨들에서 인스턴스화될 수 있다. 도 31에 도시된 일 실시예에서, <dynAuthRequest> 리소스들은 <CSEBase> 리소스 아래에서 인스턴스화될 수 있으며 <CSEBase> 리소스에 액세스하기 위한 액세스 권한들을 갖는 임의의 서비스 계층 등록자에 이용될 수 있다. 이러한 유형의 실시예는 서비스 계층 등록자들이 사전에 구성되지 않았던 임의의 CSEBase 하위 리소스에 대한 권한들을 명시적으로 요청(즉, 사전에 구성된 권한들에 의존하는 대신에 즉석에서 동적으로 권한들을 요청)하도록 허용하는데 이용될 수 있다.
대안적으로, 도 32에 도시된 다른 실시예에서, <dynAuthRequest> 리소스는 <AE>와 같은 다른 oneM2M 리소스 유형들 아래에서 인스턴스화될 수 있다. <container>, <subscription> 또는 <accessControlPolicy>와 같은 기존의 다른 oneM2M 리소스 유형들에 대해서도 동일하게 수행될 수 있다. 그렇게 함으로써, 동적 권한부여 요청들의 범위는 이러한 리소스들에 대한 사전에 존재하는 액세스 권한들을 갖는 서비스 계층 등록자로 제한될 수 있다. 예를 들어, 이 예에서 <CSEBase>/<AE>에 대한 기존의 액세스 권한들을 갖는 서비스 계층 등록자만이 <CSEBase>/<AE> 아래의 하위 리소스들에 대한 액세스 권한들을 시도하고 획득하기 위해 <CSEBase>/<AE>/<dynAuthRequest>에 동적 권한부여 요청을 발행할 수 있다.
이 리소스를 이용하기 위해, 본 개시 내용은 또한 아래의 표 2 및 표 3에 정의된 바와 같이 몇몇 제안된 파라미터를 갖는 동적 권한부여 요청 및 응답 메시지들(즉, oneM2M 프리미티브들)을 정의한다. 명시적 동적 권한부여 요청을 개시하기 위해, 요청자는 획득하고자 하는 액세스 권한들의 유형에 기반하여 정의된 파라미터들을 적합하게 초기화하여 요청을 형성할 수 있다. 그 다음, 요청자는 요청 메시지를 <dynAuthRequest> 리소스에 보낼 수 있다. 이 요청의 수신시, SLDA 기능(902)은 이를 처리할 수 있다(즉, 요청자가 권한들을 획득하기를 원하는 목표로 한 리소스 또는 서비스에 대응하는 그 구성된 <dynAuthPolicy> 리소스 규칙(들)에 대해 요청 메시지 파라미터들을 비교할 수 있다). 그 결과에 기반하여, SLDA 기능(902)은 요청마다 액세스 제어 권한들을 수정할지 여부를 결정할 수 있다. 그 다음, SLDA(902)는 요청된 권한들 중 어느 것이 승인되었는지 및 거부되었는지를 정의하는 파라미터들을 갖는 응답을 형성할 수 있다. 동적 권한부여 기능이 지원되지 않았던 경우(예를 들어, <dynAuthRequest> 리소스가 지원되지 않음) 또는 목표로 한 리소스 또는 서비스가 적합하게 구성된 <dynAuthPolicy> 리소스를 갖지 않았던 경우에, 에러가 회신될 수 있다.
표 2 - 명시적 동적 권한부여 요청 메시지의 파라미터들
표 3 - 명시적 동적 권한부여 응답 메시지의 파라미터들
<consult> 리소스
본 개시 내용은 도 33에 도시된 바와 같이 <consult> 리소스를 또한 정의한다. 이 리소스는 (도시된 바와 같이) 속성들을 갖지 않은 가상 리소스 또는 속성들(도시되지 않음)을 갖는 보통의 리소스로서 정의될 수 있다. 이 리소스의 URI는 네트워크 내의 다른 엔티티와 협의할 것을 요청하는 동적 권한부여를 수행할 때 SLDA 기능(902)이 이용할 수 있는 접촉의 협의 포인트로서 이용될 수 있다. 예를 들어, <dynAuthPolicy>가 consultationContact를 정의하는 협의 기반 규칙으로 구성될 때, <consult> 리소스의 URI가 이용될 수 있다. <consult> 리소스는 CSE들, AE들, MEF들 및 MAF들과 같은 다양한 oneM2M 정의 엔티티들에 의해 호스팅될 수 있다. 또한, 이 리소스는 위치 기능, 평판 검증 기능(예를 들어, 소셜 미디어 서버들), 플랫폼 검증 및 평가 기능, 결제 기능, 보안 기능 및 서비스 가입 검증 기능(4102)과 같이 oneM2M에 의해 아직 정의되지 않은 다른 유형들의 엔티티들에 의해 또한 호스팅될 수 있다.
이 리소스를 이용하기 위해, 본 개시 내용은 아래의 표 4 및 표 5에 정의된 바와 같이 여러 제안된 파라미터를 갖는 동적 권한부여 협의 요청 및 응답 메시지들(즉, oneM2M 프리미티브들)을 또한 정의한다. 협의를 수행하기 위해, SLDA 기능(902)은 협의 요청 메시지를 구성하고 이 메시지를 시스템 내의 엔티티에 의해 호스팅되는 <consult> 리소스쪽으로 향하게 할 수 있다. 이 요청의 수신시, 엔티티는 협의 유형에 따라 이를 처리하고, 협의 결과들을 갖는 대응하는 응답 메시지를 구성하며, 그 응답을 SLDA 기능(902)에 회신할 수 있다.
표 4 - 협의 요청 메시지의 파라미터들
표 5 - 협의 응답 메시지의 파라미터들
<accessControlPolicy> 리소스 향상들
위 도 6과 관련하여 설명된 바와 같이, oneM2M은 ACL에 기반한 정의된 privileges의 세트를 갖는 <accessControlPolicy> 리소스를 현재 지원한다. 이 ACL은 privileges 속성 내에 저장될 수 있는 액세스 제어 규칙 투플들의 세트이며, 각각의 투플은 1) accessControlOriginators, 2) accessControlOperations 및 3) accessControlContext로 구성되는 세 가지 구성요소로 이루어진다.
본 개시 내용은 이하에 설명된 <accessControlPolicy> 리소스의 기존의 privileges 속성에 대한 세 가지 향상들을 제안한다.
1) 네 번째 구성요소가 accessControlPrivilegelD로 지칭되는 privileges 액세스 제어 규칙 투플에 추가되었다. 이 네 번째 구성요소는 개별적인 privileges 액세스 제어 규칙 투플을 식별하고 주소지정하는데 이용될 수 있다. 이 식별자는 개별적인 투플의 업데이트 또는 삭제를 지원할 때 유용할 수 있다. 이와 달리, 개별적인 투플의 업데이트 또는 삭제는 덜 효율적일 수 있는 전체 privileges 액세스 제어 규칙 투플 리스트를 업데이트하는 것을 필요로 한다.
2) 다섯 번째 구성요소가 accessControlExpirationTime으로 지칭되는 privileges 액세스 제어 규칙 투플에 추가되었다. 이 구성요소는 특정한 액세스 제어 규칙 투플과 관련된 수명을 정의하는데 이용될 수 있다. 이를 통해 액세스 제어 규칙 투플들은 서로 다른 수명들을 가질 수 있으므로 권한들 관점에서 보다 융통성을 제공할 수 있다.
3) 본 개시 내용에서는 accessControlContext의 네 가지 추가 유형들이 또한 정의되었다.
● accessControlPaymentTerms - 서비스 계층 등록자가 이 권한부여 정책과 관련된 리소스들에 액세스하도록 허용되기 전에 설정되어야 하는 결제 조건의 리스트
● accessControlReputationLevel - 서비스 계층 등록자가 이 권한부여 정책과 관련된 리소스들에 액세스하도록 허용되기 전에 가져야 하는 필수 평판 레벨
● accessControlBarterTerms - 서비스 계층 등록자가 이 권한부여 정책과 관련된 리소스들에 액세스하도록 허용되기 전에 설정되어야 하는 바터 조건의 리스트
● accessControlSecurityAssessment - 서비스 계층 등록자가 이 권한부여 정책과 관련된 리소스들에 액세스하도록 허용되기 전에 가져야 하는 필수 보안 레벨
oneM2M 서비스 계층 동적 권한부여 절차들
서비스 계층 동적 권한부여 정책들의 구성
동적 권한부여 정책들은 도 34에 도시된 바와 같이 목표로 한 <dynAuthPolicy> 리소스의 dynAuthRules 속성의 생성/업데이트/삭제를 통해 구성될 수 있다. 일단 구성되면, SLDA 기능(902)은 이러한 정책들을 이용하여 동적 권한부여 요청의 처리를 수행할 수 있다.
도 34의 단계(1)에서, oneM2M 엔티티(3402)(예를 들어, AE)는 구성하고자 하는 동적 권한부여 규칙의 유형 및 (협의 기반 규칙들, 결제 기반 규칙들, 바터 기반 규칙들, 보안 평가 기반 규칙들 및 평판 기반 규칙들과 같은) 이 규칙에 대응하는 값들을 결정한다.
도 34의 단계(2)에서, oneM2M 엔티티(3402)(예를 들어, AE)는 SLDA 기능(902)을 호스팅하는 제2 oneM2M 엔티티(3404)(예를 들어, CSE, MEF(2304) 또는 MAF(2302))를 목표로 한 요청을 보낸다. 이 요청은 <dynAuthPolicy> 리소스 표현을 포함하며, <dynAuthPolicy> 리소스의 dynAuthRules 속성은 단계(1)로부터의 동적 권한부여 정책 규칙들로 구성될 수 있다.
도 34의 단계(3)에서, oneM2M 엔티티(3404) 상에 호스팅되는 SLDA 기능(902)은 요청을 수신하고 요청자가 목표로 한 <dynAuthPolicy> 리소스에 대해 지정된 동작을 수행하기 위한 적합한 권한들을 갖는지 여부를 체크한다. 이 체크는 요청자가 목표로 한 <dynAuthPolicy>와 관련된 대응하는 <accessControlPolicy> 리소스 내에서 privileges를 구성했는지 여부를 확인함으로써 수행된다. "예"인 경우, SLDA 기능(902)은 요청 처리를 계속하고, 그렇지 않다면, SLDA 기능(902)은 요청자가 이 동작을 수행할 권한들이 없음을 나타내는 에러를 요청자에게 회신한다.
도 34의 단계(4)에서, SLDA 기능(902)은 요청을 처리하고, 동작에 기반하여, 목표로 한 <dynAuthPolicy> 리소스의 dynAuthRules 속성에/으로부터 지정된 규칙들을 생성, 업데이트 또는 삭제한다.
도 34의 단계(5)에서, 서비스 계층은 목표로 한 <dynAuthPolicy> 리소스의 dynAuthRules 속성에서 지정된 규칙들을 생성, 업데이트 또는 삭제하기 위한 요청이 성공했는지 여부를 나타내는 응답을 요청자에게 회신한다.
도 34에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 34에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 34에 도시된 단계들을 수행한다. 또한, 도 34에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
자율적 서비스 계층 동적 권한부여
서비스 계층 동적 권한부여는 도 35에 도시된 바와 같이 SLDA 기능(902)을 호스팅하는 oneM2M 엔티티(3502)에 의해 자율적으로 트리거링 및 수행될 수 있다. 이 절차를 통해, SLDA 기능(902)은 요청자가 액세스하기 위한 기존의 권한들을 갖지 않은 리소스들에 액세스하기 위해 행한 요청들을 처리하는 동안 즉석에서 자율적으로 권한들을 승인하거나 거부하는 것을 지원할 수 있다. 이 절차를 지원함으로써, 요청자들이 권한들을 설정되지 않은 리소스들에 대한 액세스 권한들을 명시적으로 요청할 필요가 없으므로 요청자들의 부담을 없앨 수 있다. 이 절차를 통해, 서비스 계층 동적 권한부여는 이것이 수행되고 있음을 요청자들이 인식하지 않고도 수행될 수 있다. 이는 특히 리소스 제약된 디바이스들(예를 들어, IoT 디바이스들 상에 호스팅되는 센서 애플리케이션들)을 포함하는 사례에 대해 요청자들의 오버헤드를 감소시킬 수 있다.
이 절차는 네트워크에서 외부 관리 엔티티가 사전에 권한들의 세트로 액세스 제어 정책들을 정적으로 사전에 구성해야 하는 대신에 SLDA(902) 결과들을 활용하여 즉석에서 동적으로 생성되거나 업데이트될 액세스 제어 정책들을 위한 메커니즘을 제공하기 때문에 서비스 계층 자체에 또한 유리할 수 있다. 액세스 제어 정책들을 사전에 구성하는 것은 부담스럽고 융통성이 없으며 확장성이 매우 떨어질 수 있다.
도 35의 단계(1)에서, 요청 oneM2M 엔티티(3402)(예를 들어, AE 또는 CSE)는 요청(즉, 생성/검색/업데이트/삭제/가입/발견)을 다른 oneM2M 엔티티(3502)에 발행할 수 있다.
도 35의 단계(2)에서, 수신 oneM2M 엔티티(3502)(예를 들어, CSE)는 목표로 한 리소스에 대한 액세스를 검출한다. 수신 엔티티는 목표로 한 리소스(있는 경우)에 적용가능한 대응하는 <accessControlPolicy> 리소스(들)를 체크하여 요청자가 원하는 유형의 액세스를 수행하는 것을 허용하도록 구성된 충분한 권한들을 갖는지 여부를 결정한다. 이 예에서, 요청자는 충분한 액세스 권한들이 없다.
도 35의 단계(3)에서, 요청자에게 '액세스 거부' 에러를 즉시 회신하는 대신에, 수신 엔티티(3502)는 시스템에서 수신 엔티티 또는 다른 엔티티 상에 호스팅될 수 있는 SLDA 기능에 의해 수행될 동적 권한부여 처리를 트리거링한다. SLDA 기능은 수신 엔티티 상에 호스팅되는 일부 기능을 갖는 복수의 엔티티들로 분할될 수 있다.
도 35의 단계(4)에서, 수신 엔티티(3502)는 SLDA 기능으로 인에이블링되면 동적 권한부여 처리의 수행을 시작한다. 수신 엔티티가 SLDA 기능 자체를 호스팅하는지 여부에 따라, SLDA 처리가 완전히 로컬로 수행되는지 여부 또는 수신 엔티티가 시스템에서 엔티티들(3504 및 3506)과 같은 다른 oneM2M 엔티티들과 통신하여 SLDA(902)를 수행하는 것을 도울지 여부가 결정될 것이다. 도 23 및 도 24와 관련하여 설명된 바와 같이, 상이한 유형들의 oneM2M 엔티티들(CSE들, MEF(2304), MAF(2302))이 SLDA(902)의 전체 또는 특정한 SLDA(902) 하위 기능을 호스팅할 수 있게 하는 중앙집중화된 또는 분산된 방식으로 SLDA 기능을 호스팅하기 위한 상이한 전개 옵션들이 존재한다. SLDA 기능이 발견되지 않으면, SLDA(902) 처리를 중지할 수 있으며 '액세스 거부' 에러를 요청자에게 회신할 수 있다. SLDA 기능이 시스템에서 수신 엔티티 및/또는 다른 엔티티들 상에서 호스팅되는 것으로 발견되면, 이 기능이 트리거링되어 목표로 한 리소스에 적용가능한 <dynAuthPolicy> 리소스들을 찾는 것을 시도한다. <dynAuthPolicy>를 발견할 수 없는 경우, SLDA(902)는 동적 권한부여 처리를 중단하고 요청자에게 '액세스 거부' 에러를 회신할 수 있다. 하나 이상의 <dynAuthPolicy> 리소스가 발견되면, SLDA 기능은 발견된 각각의 리소스에 대해 dynAuthRules 속성을 이용하여 요청자의 요청에 대해 평가하고 권한들이 동적으로 승인될 수 있는지 여부를 결정할 수 있다.
도 35의 임의적인 단계(5)에서, 적용가능한 <dynAuthPolicy> 리소스들의 dynAuthRules를 평가하는 동안, SLDA 기능(902)은 지정된 dynAuthRules 유형에 따라 시스템에서 엔티티들(3504 및 3506)과 같은 다른 엔티티들과 협의해야 할 수 있다. SLDA 기능(902)이 요청자에게 액세스 권한들을 승인할지 또는 거부할지 여부를 결정하기 위해 필요로 하는 적합한 정보를 수집하기 위한 협의가 필요할 수 있다. SLDA 기능(902)이 수행할 수 있는 몇몇 제안된 유형의 협의는 도 37 내지 도 42와 관련하여 보다 상세히 설명된다. 이러한 협의는, 도 33과 관련하여 보다 상세히 설명되는, 제안된 <consult> 리소스 및 그 대응하는 요청 및 응답 프리미티브들을 이용하여 수행될 수 있다.
도 35의 단계(6)에서, dynAuthRules에 대한 요청을 평가하고 가능하게는 시스템에서 엔티티들(3504 및 3506)과 같은 다른 엔티티들과 협의하여 그 결정에 영향을 미치는 추가 정보를 획득한 결과들에 기반하여, SLDA 기능은 요청자에게 액세스 승인할지를 결정한다. 그 결과, 수신 엔티티(3502)는 목표로 한 리소스에 대한 요청을 수행하고 요청자(3402)에게 성공적인 응답을 회신한다. 요청자(3402)는 자율적 SLDA(902)가 수행되었음을 알지 못한다. 그 요청이 성공적으로 완료되었음을 알고 있는 것이 전부이다.
도 35의 임의적인 단계(7)에서, 동적 권한부여 결과들을 이용하여, SLDA 기능(902)은 목표로 한 리소스와 관련된 <accessControlPolicy> 리소스(들) 내의 privileges 속성을 업데이트하여 요청자에 대한 액세스 제어 권한들을 추가하도록 임의로 선택할 수 있다. 이 결정은 <dynAuthPolicy> 리소스 내에 정의된 dynAuthRule를 통해 제어될 수 있다. 예를 들어, dynAuthRule는 SLDA 기능(902)이 <accessControlPolicy> 리소스들의 정적 권한들을 추가 또는 업데이트하는지 여부 및 그 경우의 이 권한의 만료 시간을 제어하기 위한 규칙(예를 들어, 권한 수명 규칙)을 지원할 수 있다. 그 결과, SLDA 기능(902)은 이 규칙을 이용하여 권한을 업데이트 또는 추가하는지 여부 및 그 경우의 만료 시간을 제어할 수 있다(예를 들어, 이것은 위에서 제안된 바와 같이 권한의 accessControlExpirationTime 구성요소를 이용하여 수행될 수 있다). 이러한 규칙들에 기반하여, SLDA 기능(902)은 권한들 및 그들 각각의 수명들을 추가/업데이트할지 여부를 결정할 수 있다. 권한들을 업데이트하도록 선택함으로써, 요청자는 리소스에 대한 액세스가 승인될 수 있으며 동적 권한부여를 반복하지 않고도 동일한 동작을 수행할 수 있다.
도 35의 단계(8)에서, 요청 oneM2M 엔티티(3402)(예를 들어, AE 또는 CSE)는 요청(즉, 생성/검색/업데이트/삭제/가입/발견)을 동일한 oneM2M 엔티티에 대해 동일한 리소스에 발행한다.
도 35의 단계(9)에서, 수신 oneM2M 엔티티(3502)(예를 들어, CSE)는 목표로 한 리소스에 대한 액세스를 검출한다. 수신 엔티티는 목표로 한 리소스에 적용가능한 대응하는 <accessControlPolicy> 리소스(들)를 체크하고 SLDA 기능(902)이 단계(7)의 일부로서 이러한 권한들을 추가한 결과로 요청자가 이제는 충분한 액세스 권한들을 가지고 있음을 검출한다.
도 35의 단계(10)에서, 수신 엔티티(3502)는 목표로 한 리소스에 대한 요청을 수행하고 요청자에게 성공적인 응답을 회신한다.
도 35에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 35에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 35에 도시된 단계들을 수행한다. 또한, 도 35에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
명시적 서비스 계층 동적 권한부여 요청 처리
이 절에서는 요청자가 동적 권한부여 요청을 명시적으로 발행하여 지정된 리소스(들)에 액세스하기 위한 원하는 권한들을 획득하게 하는 절차를 정의한다.
도 36의 임의적인 단계(1)에서, 요청 oneM2M 엔티티(3402)(예를 들어, AE 또는 CSE)는 요청(즉, 생성/검색/업데이트/삭제/가입/발견)을 다른 oneM2M 엔티티(3602)에 발행할 수 있다.
도 36의 임의적인 단계(2)에서, 수신 oneM2M 엔티티(3602)(예를 들어, CSE)는 목표로 한 리소스에 대한 액세스를 검출한다. 수신 엔티티(3602)는 목표로 한 리소스(있는 경우)에 적용가능한 대응하는 <accessControlPolicy> 리소스(들)를 체크하여 요청자(3402)가 원하는 유형의 액세스를 수행하는 것을 허용하도록 구성된 충분한 권한들을 갖는지 여부를 결정한다. 이 예에서, 요청자는 충분한 액세스 권한들이 없다.
도 36의 임의적인 단계(3)에서, 요청자에게 '액세스 거부' 에러를 즉시 회신하는 대신에, 수신 엔티티(3602)는 서비스 계층 동적 권한부여를 지원하는 시스템 내의 엔티티(3502)에 대한 연결을 회신한다. 이 연결은 SLDA 기능(902)을 지원하는 엔티티에 의해 호스팅되는 <dynAuthRequest> 리소스에 대한 연결일 수 있다.
도 36의 단계(4)에서, 요청 oneM2M 엔티티(3402)는 명시적 서비스 계층 동적 권한부여 요청을 공식화 및 발행하고 이 요청을 네트워크 내의 SLDA 기능(902)쪽으로 향하게 한다. 이 요청은 SLDA 기능(902)을 지원하는 엔티티에 의해 호스팅되는 <dynAuthRequest> 리소스쪽으로 향할 수 있다. 이 요청은 위에서 모두 정의된 requestType, requestdPrivileges, paymentInfo, barterInfo, credentialInfo, platformInfo, subscriptionInfo와 같은 정보를 포함할 수 있다.
도 36의 단계(5)에서, 수신 oneM2M 엔티티(3602)는 이 요청의 수신시 목표로 한 UTI를 검사하고 이것이 <dynAuthRequest> 리소스를 목표로 한다는 것을 검출한다. 이에 기반하여, 엔티티는 SLDA 기능(902)을 트리거링하여 그 요청을 처리한다는 것을 알고 있다.
도 36의 단계(6)에서, SLDA 기능(902)은 <dynAuthPolicy> 리소스(들)가 요청되는 권한들에 존재하는지 여부를 체크한다. 이것은 요청자가 액세스 권한들을 요청한 리소스(들)를 찾음으로써 수행된다. 일단 발견되면, SLDA 기능(902)은 이들 리소스들이 그들과 제휴된 대응하는 <dynAuthPolicy> 리소스들을 갖는지 여부를 체크한다. 이들 리소스들이 그들과 제휴된 대응하는 <dynAuthPolicy> 리소스들을 갖지 않는다면, 에러 응답이 요청자에게 회신될 수 있다. 제휴된 대응하는 <dynAuthPolicy> 리소스들이 발견되면, SLDA 기능(902)은 처리를 진행할 수 있다. 다음으로, SLDA 기능(902)은 목표로 한 리소스과 제휴된 각각의 <dynAuthPolicy> 리소스의 dynAuthRules 속성들을 검사한다. dynAuthRules는 먼저 요청자의 요청에 포함된 정보(예를 들어, requestType, requestdPrivileges, paymentInfo, barterInfo, credentialInfo, platformInfo, subscriptionInfo)를 비교하여 그 요청이 규칙들을 준수하는지 여부를 확인한다. 그 요청이 규칙들을 준수하지 않는다면, 에러가 회신된다. 그렇지 않다면, SLDA(902)는 아래의 단계(7)마다 동적 권한부여 처리를 계속한다.
도 36의 임의적인 단계(7)에서, SLDA 기능(902)은 시스템 내의 다른 기능들과 임의의 협의를 수행할 필요가 있는지 여부를 체크한다. SLDA(902)는 결제, 바터, 보안, 가입 검증, 평판 검증 또는 권한부여 기능과 협상할 필요가 있는지 여부를 지정하는 dynAuthRules를 검사함으로써 이를 결정한다. 이것은 이러한 기능을 호스팅하는 oneM2M 시스템에서 엔티티들(3604 및 3606)과 같은 다른 엔티티들과 조정하는 것을 포함할 수 있다는 점에 유의해야 한다. 이러한 협의는 도 37 내지 도 42와 관련한 절차들을 이용하여 수행될 수 있다.
도 36의 단계(8)에서, SLDA 기능(902)은 명시적 동적 권한부여 요청자에 대한 응답을 회신한다. 이 응답에서, SLDA 기능(902)은 표 2에 정의된 dynAuthStatus, dynAuthCredentialID, dynAuthCredential, grantedPrivileges, deniedPrivileges, paymentTerms, barterTerms 및 subscriptionTerms와 같은 정보를 회신할 수 있다.
도 36의 임의적인 단계(9)에서, 동적 권한부여 결과들을 이용하여, SLDA 기능(902)은 목표로 한 리소스와 관련된 <accessControlPolicy> 리소스(들) 내의 privileges 속성을 업데이트하여 요청자에 대한 액세스 제어 권한들을 추가하도록 임의로 선택할 수 있다. 이 결정은 <dynAuthPolicy> 리소스 내에 정의된 dynAuthRule를 통해 제어될 수 있다. 예를 들어, dynAuthRule는 SLDA 기능(902)이 <accessControlPolicy> 리소스들의 정적 권한들을 추가 또는 업데이트하는지 여부 및 그 경우의 이 권한의 만료 시간을 제어하기 위한 규칙(예를 들어, 권한 수명 규칙)을 지원할 수 있다. 그 결과, SLDA 기능(902)은 이 규칙을 이용하여 권한을 업데이트 또는 추가하는지 여부 및 그 경우의 만료 시간을 제어할 수 있다(예를 들어, 이것은 위에서 제안된 바와 같이 권한의 accessControlExpirationTime 구성요소를 이용하여 수행될 수 있다). 이러한 규칙들에 기반하여, SLDA 기능(902)은 권한들 및 그들 각각의 수명들을 추가/업데이트할지 여부를 결정할 수 있다. 권한들을 업데이트하도록 선택함으로써, 요청자는 리소스에 대한 액세스가 승인될 수 있으며 동적 권한부여를 반복하지 않고도 동일한 동작을 수행할 수 있다.
도 36의 단계(10)에서, 요청 oneM2M 엔티티(3402)(예를 들어, AE 또는 CSE)는 요청(즉, 생성/검색/업데이트/삭제/가입/발견)을 다른 oneM2M 엔티티에 발행할 수 있다. 그 요청 내에, 요청자는 동적 권한부여 자격증명들 및/또는 단계(8)로부터 획득되는 식별자들을 포함할 수 있다.
도 36의 단계(11)에서, 수신 oneM2M 엔티티(3602)(예를 들어, CSE)는 목표로 한 리소스에 대한 액세스를 검출한다. 수신 엔티티는 목표로 한 리소스(있는 경우)에 적용가능한 대응하는 <accessControlPolicy> 리소스(들)를 체크하여 요청자가 원하는 유형의 액세스를 수행하는 것을 허용하도록 구성된 충분한 권한들을 갖는지 여부를 결정한다. 이 예에서, 요청자는 충분한 액세스 권한들이 없다.
도 36의 단계(12)에서, 요청자에게 '액세스 거부' 에러를 즉시 회신하는 대신에, 수신 엔티티(3602)는 그 요청이 동적 권한부여 자격증명(예를 들어, 토큰) 또는 그에 대한 ID를 포함하는지 여부를 체크한다. 포함하지 않았다면, '액세스 거부' 에러가 회신된다.
도 36의 단계(13)에서, 동적 권한부여 자격증명 ID만이 포함되고 실제의 자격증명이 아니라면, 수신 엔티티는 지정된 ID와 관련된 대응하는 동적 권한부여 자격증명의 SLDA 기능(902) 검색(lookup)을 트리거링한다.
도 36의 임의적인 단계(14)에서, 수신 엔티티(3602)는 동적 권한부여 자격증명에 액세스하기 위한 협의 요청을 형성한다. 이 요청은 SLDA 기능(902)의 <consult> 리소스 또는 시스템의 전용 권한부여 기능에 보내진다. 이것은 보안 네트워크 접속을 통해 수행된다. 이 요청에는 표 4에 정의된 consultationInfo와 같은 파라미터들이 포함된다.
도 36의 임의적인 단계(15)에서, 요청의 수신시, SLDA 기능(902)은 그 요청이 <consult> 리소스를 향하기 때문에 협의 요청인지를 검출한다. SLDA 기능(902)은 그 요청을 분석하여 (협의 유형 파라미터를 체크함으로써) 어떤 유형의 협의 요청인지를 검출하고 그 요청이 동적 권한부여 자격증명의 요청 협의인지를 검출한다. SLDA(902)는 그 요청에 포함된 동적 권한부여 자격증명 ID를 이용하여 대응하는 자격증명을 검색한다. 그 다음, 자격증명이 수신 엔티티에 회신된다.
도 36의 단계(16)에서, 수신 엔티티(3602)(또는 SLDA 기능(902))는 그 요청에서 수신되거나 위 협의 단계에서의 협의를 통해 획득된 동적 권한부여 자격증명을 검증한다. 일단 검증되면, SLDA 기능(902)은 요청된 액세스 권한들을 요청자에게 승인하는 것을 선택할 수 있다. 수신 엔티티는 요청을 처리하고 요청자에게 성공적인 응답을 회신한다.
도 36의 단계(17)에서, 수신 엔티티(3602)(또는 SLDA 기능(902))는 그 요청에서 수신되거나 위 협의 단계에서의 협의를 통해 획득된 동적 권한부여 자격증명을 검증한다. 일단 검증되면, SLDA 기능(902)은 요청된 액세스 권한들을 요청자에게 승인하는 것을 선택할 수 있다.
도 36의 임의적인 단계(18)에서, 동적 권한부여 결과들을 이용하여, SLDA 기능(902)은 목표로 한 리소스와 관련된 <accessControlPolicy> 리소스(들) 내의 privileges 속성을 업데이트하여 요청자에 대한 액세스 제어 권한들을 추가하도록 임의로 선택할 수 있다. 이 결정은 <dynAuthPolicy> 리소스 내에 정의된 dynAuthRule를 통해 제어될 수 있다. 예를 들어, dynAuthRule는 SLDA 기능(902)이 <accessControlPolicy> 리소스들의 정적 권한들을 추가 또는 업데이트하는지 여부 및 그 경우의 이 권한의 만료 시간을 제어하기 위한 규칙(예를 들어, 권한 수명 규칙)을 지원할 수 있다. 그 결과, SLDA 기능(902)은 이 규칙을 이용하여 권한을 업데이트 또는 추가하는지 여부 및 그 경우의 만료 시간을 제어할 수 있다(예를 들어, 이것은 위에서 제안된 바와 같이 권한의 accessControlExpirationTime 구성요소를 이용하여 수행될 수 있다). 이러한 규칙들에 기반하여, SLDA 기능(902)은 권한들 및 그들 각각의 수명들을 추가/업데이트할지 여부를 결정할 수 있다. 권한들을 업데이트하도록 선택함으로써, 요청자는 리소스에 대한 액세스가 승인될 수 있으며 동적 권한부여를 반복하지 않고도 동일한 동작을 수행할 수 있다.
도 36에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 36에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 36에 도시된 단계들을 수행한다. 또한, 도 36에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
협의 기반 서비스 계층 동적 권한부여
도 37은 협의 기반 동적 권한부여의 절차를 보여준다.
도 37의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 37의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 '협의 기반 권한부여'가 동적 권한부여 처리의 일부로서 요구된다는 것을 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)이 시스템의 권한부여 기능(3702)과 협의하도록 트리거링하여 요청하거나 요구하는 액세스 권한들을 요청자에게 승인할지 또는 거부할지 여부를 가늠하게 한다.
도 37의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 권한부여 기능(3702)에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 동적 권한부여가 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자가 명시적으로 요청하는 요청된/요구된 권한들 또는 SLDA 기능(902)이 목표로 하는 리소스나 서비스에 액세스하기 위해 요청자에게 필요한 것으로 간주하는 권한들로 구성된다.
도 37의 단계(4)에서, 권한부여 기능(3702)은 요청자가 요청하는 액세스 권한들을 승인할지 또는 거부할지 여부를 평가한다. 이 결정이 어떻게 이루어지는지에 대한 세부사항들은 본 개시 내용의 범위를 벗어나고 또한 권한부여 기능(3702)이 지원하는 체크들의 유형에 특정한 것으로 고려되며, 이는 전개 이용 사례에 따라 변할 수 있다. 그 다음, 이 동작의 결과들은 협의 응답의 형태로 SLDA(902)에 회신된다. 이 응답은 승인 및 거부된 권한들의 리스트들을 포함한다. 또한, 이 응답은 요청자가 관심을 가질 만한 일부 다른 리소스들 또는 서비스들의 권한들도 포함할 수 있다.
도 37의 단계(5)에서, SLDA 기능은 협의 기반 권한부여 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 37에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 37에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 37에 도시된 단계들을 수행한다. 또한, 도 37에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
결제 기반 서비스 계층 동적 권한부여
도 38은 결제 기반 동적 권한부여의 절차를 보여준다.
도 38의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 38의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 '결제 검증 요구'가 동적 권한부여 처리의 일부로서 요구된다는 것을 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)이 시스템의 결제 기능(3802)과 협의하도록 트리거링하여 요청자의 결제 정보를 검증하게 한다.
도 38의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 결제 기능에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 결제 정보 검증이 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자의 결제 정보뿐만 아니라 요청자의 결제 토큰 및 선호들 및 정책의 결제 조건과 같은 정보를 포함할 수 있는 결제 정책으로 구성된다.
도 38의 단계(4)에서, 결제 기능(3802)은 결제 정보가 유효한지를 검증하기 위해 결제 정보를 평가하고 또한 정책에서의 결제 규칙들에 대해 결제 정보를 평가한다. 그 다음, 이 동작의 결과들은 협의 응답의 형태로 SLDA(902)에 회신된다. 이 응답은 결제 정보 검증 상태를 포함한다.
도 38의 단계(5)에서, SLDA 기능은 결제 정보 검증 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 38에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 38에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 38에 도시된 단계들을 수행한다. 또한, 도 38에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
바터 기반 서비스 계층 동적 권한부여
도 39는 바터 기반 동적 권한부여의 절차를 보여준다.
도 39의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 39의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 요청자가 액세스 권한들을 승인받기 위해 충족시켜야 하는 바터 요건들의 리스트인 '바터 조건 요구'를 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)을 트리거링하여 로컬 바터 처리를 수행하게 하거나 시스템의 바터 기능(3902)과 협의하여 SLDA(902) 대신에 바터 기능(3902)이 바터 처리를 수행하게 한다.
도 39의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 바터 기능(3902)에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 바터 처리가 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자의 바터 정보뿐만 아니라 요청자가 액세스 권한들을 승인받기 위해 기꺼이 동의해야 하는 바터 조건의 유형 정보를 포함할 수 있는 바터 정책으로 구성된다. 예를 들어, 요청자의 리소스들 및 서비스들에 대한 액세스의 호혜성은 목표로 한 리소스 소유자에 의해 액세스 권한들을 승인받은 대가이다.
도 39의 단계(4)에서, 바터 기능(3902)은 요청자가 이러한 조건에 기꺼이 동의하는지 여부를 결정하기 위해 요청자뿐만 아니라 정책에 의해 정의된 바터 조건을 평가한다. 그 다음, 바터 기능(3902)은 바터 상태 및 동의된 조건의 리스트를 포함하는 협의 응답을 통해 그 결과를 SLDA(902)에 회신한다.
도 39의 단계(5)에서, SLDA 기능은 바터 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 39에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 39에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 39에 도시된 단계들을 수행한다. 또한, 도 39에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
보안 평가 기반 서비스 계층 동적 권한부여
도 40은 보안 평가 기반 동적 권한부여의 절차를 보여준다.
도 40의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 40의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 '보안 평가 요구'를 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)을 트리거링하여 로컬 보안 평가 처리를 수행하게 하거나 시스템의 보안 기능(4002)과 협의하여 SLDA(902) 대신에 보안 기능(4002)이 보안 평가 처리를 수행하게 한다.
도 40의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 보안 기능(4002)에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 보안 평가 처리가 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자의 보안 정보(ID들, 자격증명들, 인터페이스 보안 지원의 유형, 플랫폼 보안 지원, 콘텐츠 보안 지원 등)로 구성된다. 이 요청은 정책에 의해 정의된 임의의 필수 보안 평가 레벨로 또한 구성될 수 있다.
도 40의 단계(4)에서, 보안 기능(4002)은 요청자가 보안 평가 요건들을 충족시키는지 여부를 결정하기 위해 정책에 정의된 보안 요건들에 대해 요청자의 보안 정보를 평가한다. 그 다음, 보안 기능(4002)은 그 결과를 보안 평가 상태를 포함하는 협의 응답을 통해 SLDA(902)에 회신한다.
도 40의 단계(5)에서, SLDA 기능은 보안 평가 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 40에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 40에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 40에 도시된 단계들을 수행한다. 또한, 도 40에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
서비스 계층 가입 검증 기반 동적 권한부여
도 41은 서비스 계층 가입 기반 동적 권한부여의 절차를 보여준다.
도 41의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 41의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 '서비스 가입 검증 요구'를 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)을 트리거링하여 로컬 서비스 가입 검증 처리를 수행하게 하거나 시스템의 가입 검증 기능(4102)과 협의하여 SLDA(902) 대신에 가입 검증 기능(4102)이 이 검증을 수행하게 한다.
도 41의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 가입 검증 기능(4102)에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 검증이 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자의 이용가능한 임의의 서비스 가입 정보(예를 들어, 서비스 계층 ID들)뿐만 아니라 요청자가 액세스 권한들을 승인받아야 하는 필수 서비스 제공자 및/또는 서비스 계획과 같은 요건들을 정의하는 서비스 가입 정책 규칙으로 구성된다.
도 41의 단계(4)에서, 가입 검증 기능(4102)은 요청자의 서비스 가입에 대해 정책에 의해 정의된 가입 요건들을 평가하여 요청자가 정책에 의해 정의된 요건들을 충족시키는지 여부를 결정한다. 그 다음, 가입 검증 기능(4102)은 검증 상태, 및 충족되지 않은 임의의 요건들뿐만 아니라 충족된 요건들의 리스트를 포함하는 협의 응답을 통해 그 결과를 SLDA(902)에 회신한다.
도 41의 단계(5)에서, SLDA 기능은 가입 검증 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 41에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 41에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 41에 도시된 단계들을 수행한다. 또한, 도 41에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
평판 기반 서비스 계층 동적 권한부여
도 42는 평판 기반 동적 권한부여의 절차를 보여준다.
도 42의 단계(1)에서, SLDA 기능(902)은 명시적 요청(즉, <dynAuthRequest> 리소스에 대한 액세스)에 의하거나 SLDA 기능(902) 자체를 통해(예를 들어, 기존의 <accessControlPolicy> 정적 권한들에 대한 체크들이 실패한 요청의 검출을 통해) 자율적으로 트리거링된다.
도 42의 단계(2)에서, SLDA(902)는 적용가능한 <dynAuthPolicy> 리소스들(있는 경우)을 찾고 dynAuthPolicy 속성을 평가하여 어떤 규칙들이 구성되었는지를 결정한다. 이 예에서, dynAuthPolicy 속성은 요청자의 평판이 액세스 권한들을 동적으로 승인받기 위해 충족시켜야 하는 순위 또는 레벨을 정의하는 '평판 레벨 요구'를 지정하는 규칙으로 구성되었다. 이 규칙은 SLDA 기능(902)을 트리거링하여 로컬 평판 검증 처리를 수행하게 하거나 시스템의 평판 검증 기능(4202)과 협의하여 SLDA(902) 대신에 평판 검증 기능(4202)이 이 검증을 수행하게 한다.
도 42의 단계(3)에서, SLDA 기능(902)은 협의 요청 메시지를 형성한다. 이 메시지는 평판 검증 기능에 의해 호스팅되는 <consult> 리소스를 향한다. consultSubject는 검증이 수행되는 요청자의 AE-ID 또는 CSE-ID로 구성된다. 요청의 페이로드는 요청자의 이용가능한 임의의 평판 관련 정보(예를 들어, 서비스 계층 ID들)뿐만 아니라 요청자가 액세스 권한들을 승인받아야 하는데 필요한 최소 평판 레벨 또는 순위를 정의하는 평판 정책 규칙으로 구성된다.
도 42의 단계(4)에서, 평판 검증 기능(4202)은 요청자의 평판에 대해 정책에 의해 정의된 평판 요건들을 평가하여 요청자가 정책에 의해 정의된 요건들을 충족시키는지 여부를 결정한다. 이는 흔히 이러한 정보를 추적하는 소셜 미디어 아웃렛들에 인터페이싱하는 것과 같은 방법들을 이용하여 수행될 수 있다. 그 다음, 평판 검증 기능(4202)은 검증 상태 및 평판 레벨 또는 순위를 포함하는 협의 응답을 통해 SLDA(902)에 그 결과를 회신한다.
도 42의 단계(5)에서, SLDA 기능은 평판 결과들을 체크하고 이 결과를 그 동적 권한부여 결정에 반영하여 요청자의 액세스 권한들을 승인할지 또는 거부할지 여부를 결정한다.
도 42에 도시된 단계들을 수행하는 엔티티들은 도 44c 또는 도 44d에 도시된 것과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 42에 도시된 방법(들)은 도 44c 또는 도 44d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 42에 도시된 단계들을 수행한다. 또한, 도 42에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.
GUI(Graphical User Interface)들과 같은 인터페이스들은 이용자를 도와 서비스 계층 동적 권한부여에 관련된 기능들을 제어 및/또는 구성하는데 이용될 수 있다. 도 43은 이용자가 서비스 계층 동적 권한부여를 인에이블링하게 하고, 동적 권한부여가 정적 권한부여로서 저장되는 서비스 계층 동적 권한부여 기간을 선택하게 하며, 협의 서버들 또는 애플리케이션들을 구성하게 하는 인터페이스(4302)를 도시하는 도면이다.
인터페이스(4302)는 본 개시 내용의 표 1에 있는 것과 같은 특정한 동적 권한부여 규칙들을 정의하는데 이용될 수 있다(dynAuthRules 참조). 인터페이스(4302)는 이용자가 이용가능한 규칙들의 리스트로부터 체크하게 하거나 수동으로 규칙들을 입력하게 할 수 있다.
인터페이스(4302)는 이하에 설명되는 도 44c 및 도 44d에 도시된 것들과 같은 디스플레이들을 이용하여 생성될 수 있음을 이해해야 한다.
예시적인 M2M/IoT/WoT 통신 시스템
본 명세서에 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어 또는, 적합한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 상주할 수 있다. 이러한 장치들은 본 명세서에 설명되는 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 이용되는 용어들 "장치", "네트워크 장치", "노드", "디바이스" 및 "네트워크 노드"는 교체가능하게 이용될 수 있다.
서비스 계층이라는 용어는 네트워크 서비스 아키텍처 내의 기능 계층을 지칭한다. 서비스 계층들은 통상적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 있으며 클라이언트 애플리케이션들에 부가가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 전송/액세스 계층과 같은 더 하위의 리소스 계층에서 코어 네트워크들에 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 런타임 인에이블먼트, 정책 관리, 액세스 제어 및 서비스 클러스터링을 포함하는 다수 카테고리들의 (서비스) 능력들 또는 기능들을 지원한다. 최근에, 수 개의 산업 표준 기관들, 예를 들어 oneM2M은 M2M 유형들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업 및 홈 네트워크들과 같은 전개들에 통합하는 것과 관련된 도전들을 해결하기 위해 M2M 서비스 계층들을 개발해 왔다. M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에게, CSE 또는 SCL이라고 지칭될 수 있는, 서비스 계층에 의해 지원되는, 앞서 언급된 능력들 또는 기능들의 모음 또는 세트에 대한 액세스를 제공할 수 있다. 몇몇 예들은, 이에 제한되는 것은 아니지만, 다양한 애플리케이션들에 의해 흔히 이용될 수 있는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속 관리를 포함한다. 이러한 능력들 또는 기능들은 M2M 서비스 계층에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 이러한 다양한 애플리케이션들에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 및/또는 소프트웨어로 구현될 수 있으며 다양한 애플리케이션들 및/또는 디바이스들에 노출되어 이들이 이러한 능력들 또는 기능들을 이용하게 하는 (서비스) 능력들 또는 기능들(즉, 이러한 기능 엔티티들 간의 기능 인터페이스들)을 제공하는 기능 엔티티이다.
도 44a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M, 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT는 물론 IoT/WoT 서비스 계층 등의 구성요소 또는 노드일 수 있다. 통신 시스템(10)은, 개시된 실시예들의 기능을 구현하는데 이용될 수 있으며 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들 및 기능을 포함할 수 있다.
도 44a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, 이더넷, 파이버, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등)일 수 있거나 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 복수의 이용자들에게 제공하는 복수의 액세스 네트워크들로 이루어져 있을 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합형 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 44a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 종단간 M2M 전개의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인 둘 다는 각종의 상이한 네트워크 노드들(예컨대, 서버들, 게이트웨이들, 디바이스 등)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은, 통신 회로를 이용하여, 통신 네트워크(12) 또는 직접 무선 연결을 통해 신호들을 전송 및 수신하도록 구성되어 있다. M2M 게이트웨이(14)는 무선 M2M 디바이스들(예컨대, 셀룰러 및 비셀룰러)은 물론 고정 네트워크 M2M 디바이스들(예컨대, PLC)이 통신 네트워크(12)와 같은 오퍼레이터 네트워크들 또는 직접 무선 연결 중 어느 하나를 통해 통신할 수 있게 한다. 예를 들어, M2M 단말 디바이스들(18)은 데이터를 수집할 수 있고, 데이터를 통신 네트워크(12) 또는 직접 무선 연결을 통해 M2M 애플리케이션(20) 또는 다른 M2M 디바이스들(18)에 보낼 수 있다. M2M 단말 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 단말 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 보내질 수 있고 그로부터 수신될 수 있다. M2M 단말 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예컨대, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 연결, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.
예시적인 M2M 단말 디바이스들(18)은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카(connected car)들, 스마트 미터(smart meter)들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 전등들, 서모스탯들, 가전기기들, 차고문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 아웃렛들을 포함하지만, 이들로 제한되지는 않는다.
도 44b를 참조하면, 필드 도메인에서의 예시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 서비스들을 제공한다. 통신 네트워크(12)는, 개시된 실시예들의 기능을 구현하는데 이용될 수 있으며 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들 및 기능을 포함할 수 있다. M2M 서비스 계층(22)은 예를 들어, 이하 설명되는 도 44c 및 도 44d에 도시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드/스토리지 팜 등) 등에 의해 구현될 수 있다. M2M 서비스 계층(22)이 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들(14), M2M 단말 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 것을 잘 알 것이다. M2M 서비스 계층(22)은 서버들, 컴퓨터들, 디바이스들 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말 디바이스들(18), M2M 게이트웨이들(14), 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은 다양한 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등으로 구현될 수 있다.
도시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인에서 M2M 애플리케이션(20') 및 하위 통신 네트워크(12)에 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인 내의 M2M 게이트웨이들(14) 및 M2M 단말 디바이스들(18)에 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들 및 M2M 디바이스들과 통신할 수 있다는 점을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의한 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/스토리지 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.
또한 도 44b를 참조하면, M2M 서비스 계층들(22 및 22')은 다양한 애플리케이션들 및 버티클들이 활용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용할 수 있게 하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능들을 구현하는 애플리케이션들의 부담을 없애고, 따라서 애플리케이션 개발을 단순화하고 마케팅 비용 및 시간을 감소시킨다. 서비스 계층들(22 및 22')은 또한 M2M 애플리케이션들(20 및 20')이 서비스 계층들(22 및 22')이 제공하는 서비스들과 관련하여 네트워크들(12)을 통해 통신할 수 있게 한다.
본 출원의 방법들은 서비스 계층(22 및 22')의 일부로서 구현될 수 있다. 서비스 계층(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(APIs) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M과 oneM2M 둘 다는 본 출원의 접속 방법들을 포함할 수 있는 서비스 계층을 이용한다. ETSI M2M의 서비스 계층은 SCL이라고 지칭된다. 이러한 SCL은 M2M 디바이스(DSCL(device SCL)이라고 지칭됨), 게이트웨이(GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는, 상이한 유형들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 CSE라고 지칭된다. 게다가, 본 출원의 접속 방법들은 본 출원의 접속 방법들과 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(Service Oriented Architecture: SOA) 및/또는 리소스 지향 아키텍처(resource-oriented architecture: ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.
일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들과 함께 이용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 또한 다른 개시된 시스템들 및 방법들과 관련하여 이용될 수 있다.
일 실시예에서, 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 도 44b에 도시된 바와 같이 M2M 서버, M2M 게이트웨이 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 계층 인스턴스 내에 호스팅될 수 있다. 예를 들어, 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 M2M 서비스 계층 인스턴스 내에서 또는 기존의 서비스 능력 내의 하위 기능으로서 개별적인 서비스 능력을 포함할 수 있다.
M2M 애플리케이션들(20 및 20')은 운송, 건강 및 웰빙(health and wellness), 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 보안 및 감시(이들로 제한되지 않음)와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 앞서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에게 제공한다.
일반적으로, 서비스 계층들(22 및 22')은 API들 및 하위 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 아키텍처와 oneM2M 아키텍처 둘 다는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 각종의 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(DSCL이라고 지칭됨), 게이트웨이(GSCL이라고 지칭됨), 및/또는 네트워크 노드(NSCL이라고 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는, 상이한 유형들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 CSE라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처도 정의하였다. 그 아키텍처에서, 서비스 계층과, 서비스 계층이 제공하는 서비스 능력들이 서비스 능력 서버(Service Capability Server: SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 구성요소의 인스턴스는 이하에 설명되는 도 44c 또는 도 44d에 도시된 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.
또한, 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 본 출원의 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.
도 44c는, M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등과 같은, M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는, 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들을 실행하거나 포함할 수 있다. 디바이스(30)는 도 44a 및 도 44b에 도시된 바와 같은 M2M 네트워크의 일부 또는 비M2M 네트워크의 일부일 수 있다. 도 44c에 도시된 바와 같이, M2M 노드(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시자들(42), 전원(48), 글로벌 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. M2M 노드(30)가 일 실시예와 부합한 채로 있으면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있다는 것을 잘 알 것이다. 이 노드는 본 명세서에 설명되는 SMSF 기능을 구현하는 노드일 수 있다.
프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 통상의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit), 상태 머신과 관련되는 하나 이상의 마이크로프로세서 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 필수 기능들을 수행하기 위해 노드의 메모리(예컨대, 메모리(44) 및/또는 메모리(46))에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입출력 처리, 및/또는 M2M 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예컨대, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한, 예를 들어, 액세스 계층 및/또는 애플리케이션 계층 등에서 인증, 보안 키 일치(security key agreement), 및/또는 암호 동작들과 같은 보안 동작들을 수행할 수 있다.
도 44c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 송수신기(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)로 하여금 그에 접속되어 있는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 상세하게는, 프로세서(32)는 본 명세서 및 청구항들에 설명된 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 44c가 프로세서(32)와 송수신기(34)를 별도의 구성요소들로서 묘사하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.
전송/수신 요소(36)는 M2M 서버들, 게이트웨이들, 디바이스 등을 포함하는, 다른 M2M 노드들에게 신호들을 전송하거나 그들로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 전송/수신 요소(36)는 RF 신호들을 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일 실시예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV 또는 가시 광 신호들을 전송 및/또는 수신하도록 구성된 이미터/검출기일 수 있다. 또 다른 실시예에서, 전송/수신 요소(36)는 RF 및 광 신호들 둘 다를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.
또한, 전송/수신 요소(36)가 단일 요소로서 도 44c에 묘사되지만, M2M 노드(30)는 임의의 수의 전송/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로는, M2M 노드(30)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, M2M 노드(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 요소들(36)(예컨대, 복수의 안테나들)을 포함할 수 있다.
송수신기(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, M2M 노드(30)는 다중 모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 M2M 노드(30)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 복수의 RAT들을 통해 통신할 수 있게 하기 위한 복수의 송수신기들을 포함할 수 있다.
프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적합한 메모리로부터의 정보에 액세스하거나 그 메모리에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는, 전술한 바와 같이, 세션 컨텍스트(session context)를 그 메모리에 저장할 수 있다. 비이동식 메모리(44)는 RAM, ROM, 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터와 같은, M2M 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하기 위해 또는 이용자로부터 입력을 획득하거나 노드의 세션 마이그레이션 또는 공유 능력들 또는 설정들에 관한 정보를 이용자에게 표시하기 위해 디스플레이 또는 표시자들(42) 상에서의 조명 패턴들, 이미지들, 또는 색상들을 제어하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 보여줄 수 있다. 본 개시 내용은 oneM2M 실시예에서 RESTful 이용자/애플리케이션 API를 정의한다. 디스플레이 상에 보여질 수 있는 그래픽 이용자 인터페이스는 이용자가, 본 명세서에서 설명되는 하위 서비스 계층 세션 기능을 통해, E2E 세션 또는 그 마이그레이션 또는 공유를 상호작용적으로 설정 및 관리할 수 있게 하기 위해 API 위에 계층화될 수 있다.
프로세서(32)는 전원(48)으로부터 전력을 받을 수 있고, M2M 노드(30) 내의 다른 구성요소들에게 전력을 분배 및/또는 제어하도록 구성될 수 있다. 전원(48)은 M2M 노드(30)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양광 전지, 연료 전지 등을 포함할 수 있다.
프로세서(32)는 또한 M2M 노드(30)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성되어 있는 GPS 칩셋(50)에 결합될 수 있다. M2M 노드(30)가 일 실시예와 부합한 채로 있으면서 임의의 적합한 위치 결정 방법을 통해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.
프로세서(32)는 추가적인 특징들, 기능, 및/또는 유선 또는 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변기기들(52)에 또한 결합될 수 있다. 예를 들어, 주변기기들(52)은 가속도계, 생체측정(예컨대, 지문) 센서들, 전자 나침반(e-compass)과 같은 다양한 센서들, 위성 송수신기, (사진 또는 비디오용의) 디지털 카메라, USB 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 운송 수단과 같은 다른 장치들 또는 디바이스들에서 구현될 수 있다. 노드(30)는, 주변기기들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은, 하나 이상의 상호접속 인터페이스를 통해 이러한 장치들 또는 디바이스들의 다른 구성요소들, 모듈들, 또는 시스템들에 접속할 수 있다. 대안적으로, 노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 운송 수단과 같은 장치들 또는 디바이스들을 포함할 수 있다.
도 44d는, M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드와 같은, M2M 네트워크의 하나 이상의 노드를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 소프트웨어의 형태일 수 있는 컴퓨터 판독가능한 명령어들에 의하거나 그 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해서도 주로 제어될 수 있다. 컴퓨팅 시스템(90)은, 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어, M2M 디바이스, 이용자 장비, 게이트웨이, UE/GW 또는 모바일 코어 네트워크의 노드들을 포함하는 임의의 다른 노드들, 서비스 계층 네트워크 애플리케이션 제공자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하기 위해, 중앙 처리 유닛(CPU)(91)과 같은 프로세서 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는, 추가적 기능들을 수행하거나 CPU(91)를 보조하는, 주 CPU(91)와는 별개인, 임의의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것 또는 세션 자격증명들에 기반하여 인증하는 것과 같은, E2E M2M 서비스 계층 세션들에 대한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.
동작에 있어서, CPU(91)는 명령어들을 페치, 디코딩 및 실행하고, 컴퓨터의 주 데이터 전송 경로인 시스템 버스(80)를 통해 다른 리소스들에 정보를 전송하고 다른 리소스들로부터의 정보를 전송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90)에 있는 구성요소들을 접속시키고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 데이터를 보내기 위한 데이터 라인들, 주소들을 보내기 위한 주소 라인들, 및 인터럽트들을 보내고 시스템 버스를 동작시키기 위한 제어 라인들을 통상적으로 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.
시스템 버스(80)에 결합된 메모리들은 RAM(82) 및 ROM(93)을 포함한다. 이러한 메모리들은 정보가 저장되고 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독되거나 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 주소들을 물리 주소들로 변환하는 주소 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 이용자 프로세스들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 주소 공간에 의해 매핑되는 메모리에만 액세스할 수 있으며, 프로세스들 사이의 메모리 공유가 설정되지 않는다면 다른 프로세스의 가상 주소 공간 내의 메모리에 액세스할 수 없다.
또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변기기들로 명령어들을 통신하는 것을 담당하는 주변기기 제어기(83)를 포함할 수 있다.
디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 표시하는데 이용된다. 이러한 시각적 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 보내지는 비디오 신호를 생성하는데 필요한 전자 구성요소들을 포함한다.
또한, 컴퓨팅 시스템(90)은 도 44a 및 도 44b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속시켜, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.
이용자 장비(UE)는 통신하기 위해 최종 이용자에 의해 이용되는 임의의 디바이스일 수 있다. 이용자 장비(UE)는 핸드헬드 전화기, 모바일 광대역 어댑터가 장착된 랩톱 컴퓨터, 또는 임의의 다른 디바이스일 수 있다. 예를 들어, UE는 도 44a 및 도 44b의 M2M 단말 디바이스(18) 또는 도 44c의 디바이스(30)로서 구현될 수 있다.
본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들 중 일부 또는 전부가 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있고, 이 명령어들이, 예를 들어, M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 것을 알 것이다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크의 노드들, 서비스 계층 또는 네트워크 애플리케이션 제공자 중 임의의 것의 동작들을 포함하는, 전술한 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 서비스 계층(102), Apps(204 및 202), SLDA(902), SLDA-PA(904), SLDA-PI(906), SLDA-PD(908), SLDA-PE(910), SLSA(1402), SLSA-PA(1404), SLSA-PD(1406), SLSA-PI(1412), SLSA-PE(1410), SL-PCF(1408), 엔티티들(1502, 1602, 3402, 3404, 3502, 3504, 3506, 3602, 3604, 3606), 정책 서버(1504), RHF(1604), 클라이언트(1702), DAEF(1802) 및 DAEF-결제, DGF(2102), MAF(2302), MEF(2304), 권한부여 기능(3702), 결제 기능(3802), 바터 기능(3902), 보안 기능(4002), 서비스 계층 가입 검증 기능(4102), 평판 검증 기능(4202)뿐만 아니라 개시된 리소스들을 저장하고 동작시키기 위한 논리 엔티티들, 및 인터페이스(4302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위해 임의의 비일시적(즉, 유형적 또는 물리적) 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘 다를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체가 신호들은 포함하지 않는다. 컴퓨터 판독가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 디스크 저장소, 자기 카세트, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형적 또는 물리적 매체를 포함하지만, 이들로 제한되지 않는다.
본 개시 내용의 주제의 바람직한 실시예들을 설명함에 있어서, 도면들에 예시된 바와 같이, 명확함을 위해 특정한 용어들이 이용되었다. 그러나, 청구되는 주제는 그렇게 선택된 특정한 용어들로 제한되는 것으로 의도되는 것이 아니며, 각각의 특정한 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 점이 이해되어야 한다.
이 기재된 설명은 최상의 모드를 포함하는 본 발명을 개시하기 위해, 또한 관련 기술분야에서의 임의의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작하고 이용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 하기 위해 예들을 이용한다. 본 발명의 특허가능한 범주는 청구항들에 의해 한정되고, 관련 기술분야에서의 통상의 기술자에게 안출되는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 본 청구항들의 문언적 표현과 상이하지 않은 요소들을 가지는 경우, 또는 청구항들의 문언적 표현과 그다지 차이를 갖지 않는 등가의 요소들을 포함하는 경우, 본 청구항들의 범주 내에 속하는 것으로 의도된다.
Claims (20)
- 프로세서 및 메모리를 포함하는 장치로서,
상기 장치는 상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며,
상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
상기 장치에서의 서비스 계층에서 요청을 수신하게 하고,
상기 서비스 계층에서, 상기 요청의 발신자가 목표로 한 리소스에 액세스하기 위한 적합한 정적 권한들을 갖는지 여부를 결정하게 하며,
상기 요청의 발신자가 상기 목표로 한 리소스에 액세스하기 위한 적합한 정적 권한들을 갖지 않은 경우, 동적 권한부여를 이용하여 상기 요청을 평가하고 상기 동적 권한부여에 기반하여 상기 요청을 허용 또는 거부하게 하는 장치. - 제1항에 있어서,
상기 장치는 동적 권한부여를 이용하여 상기 요청을 평가하기 위해 협의 엔티티와 협의하는 장치. - 제2항에 있어서,
상기 서비스 계층은 상기 협의 엔티티에 대한 접촉 정보를 포함하는 정책으로 구성되는 장치. - 제2항에 있어서,
상기 협의 엔티티는 상기 서비스 계층에 대한 응답으로 승인된 권한들의 리스트, 및 상기 승인된 권한들과 관련된 수명을 보내는 장치. - 제4항에 있어서,
상기 장치는 상기 승인된 권한들의 리스트에 지정된 대로 요청자를 추가함으로써 정적 정책들을 업데이트하는 장치. - 제5항에 있어서,
상기 요청자는 상기 정적 정책들에 일시적으로 추가되는 장치. - 제1항에 있어서,
상기 장치는 동적 권한부여 정책들을 수신하는 장치. - 제1항에 있어서,
상기 장치는 상기 요청자가 결제했다는 표시를 수신한 후에 상기 동적 권한부여를 수행하는 장치. - 제1항에 있어서,
상기 장치는 상기 요청자가 바터(barter) 조건들을 이행했다는 표시를 수신한 후에 상기 동적 권한부여를 수행하는 장치. - 제1항에 있어서,
상기 장치는 상기 동적 권한부여에서 평판 정보를 이용하여 인증된 요청자에 관한 평판 정보를 이용하는 장치. - 장치에 의해 이용하기 위한 방법으로서,
상기 장치는 프로세서 및 메모리를 포함하며,
상기 장치는 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며,
상기 컴퓨터 실행가능한 명령어들은, 상기 프로세서에 의해 실행될 때,
상기 장치에서의 서비스 계층에서 요청을 수신하는 단계;
상기 서비스 계층에서, 상기 요청의 발신자가 목표로 한 리소스에 액세스하기 위한 적합한 정적 권한들을 갖는지 여부를 결정하는 단계; 및
상기 요청의 발신자가 상기 목표로 한 리소스에 액세스하기 위한 적합한 정적 권한들을 갖지 않은 경우, 동적 권한부여를 이용하여 상기 요청을 평가하고 상기 동적 권한부여에 기반하여 상기 요청을 허용 또는 거부하는 단계
를 포함하는 방법의 기능들을 수행하는 방법. - 제11항에 있어서,
상기 장치는 동적 권한부여를 이용하여 상기 요청을 평가하기 위해 협의 엔티티와 협의하는 방법. - 제12항에 있어서,
상기 서비스 계층은 상기 협의 엔티티에 대한 접촉 정보를 포함하는 정책으로 구성되는 방법. - 제12항에 있어서,
상기 협의 엔티티는 상기 서비스 계층에 대한 응답으로 승인된 권한들의 리스트, 및 상기 승인된 권한들과 관련된 수명을 보내는 방법. - 제14항에 있어서,
상기 장치는 상기 승인된 권한들의 리스트에 지정된 대로 요청자를 추가함으로써 정적 정책들을 업데이트하는 방법. - 제15항에 있어서,
상기 요청자는 상기 정적 정책들에 일시적으로 추가되는 방법. - 제11항에 있어서,
상기 장치는 동적 권한부여 정책들을 수신하는 방법. - 제11항에 있어서,
상기 장치는 상기 요청자가 결제했다는 표시를 수신한 후에 상기 동적 권한부여를 수행하는 방법. - 제11항에 있어서,
상기 장치는 상기 요청자가 바터 조건들을 이행했다는 표시를 수신한 후에 상기 동적 권한부여를 수행하는 방법. - 제11항에 있어서,
상기 장치는 상기 동적 권한부여에서 평판 정보를 이용하여 인증된 요청자에 관한 평판 정보를 이용하는 방법.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201562211471P | 2015-08-28 | 2015-08-28 | |
| US62/211,471 | 2015-08-28 | ||
| PCT/US2016/048938 WO2017040263A1 (en) | 2015-08-28 | 2016-08-26 | Service layer dynamic authorization |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20180048766A true KR20180048766A (ko) | 2018-05-10 |
| KR102112106B1 KR102112106B1 (ko) | 2020-05-18 |
Family
ID=56894280
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020187008346A KR102112106B1 (ko) | 2015-08-28 | 2016-08-26 | 서비스 계층 동적 권한부여 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20170063931A1 (ko) |
| EP (2) | EP3342125B1 (ko) |
| JP (1) | JP6560442B2 (ko) |
| KR (1) | KR102112106B1 (ko) |
| CN (2) | CN113766507B (ko) |
| WO (1) | WO2017040263A1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021251713A1 (ko) * | 2020-06-11 | 2021-12-16 | 박정훈 | 사물 인터넷 기기를 활용한 스트리밍 방송 후원 시스템 |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20150131902A (ko) * | 2014-05-16 | 2015-11-25 | 삼성전자주식회사 | 음성 호 서비스 품질을 높이는 방법 및 장치 |
| CN113596165A (zh) | 2015-09-01 | 2021-11-02 | 康维达无线有限责任公司 | 服务层注册 |
| CN108476236B (zh) * | 2015-12-30 | 2021-08-03 | 康维达无线有限责任公司 | 物联网数据的基于语义的内容规范 |
| US20180139090A1 (en) * | 2016-11-15 | 2018-05-17 | John Geiger | Method for secure enrollment of devices in the industrial internet of things |
| FR3061400A1 (fr) * | 2016-12-28 | 2018-06-29 | Overkiz | Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique |
| FR3061399B1 (fr) | 2016-12-28 | 2023-04-21 | Overkiz | Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique |
| FR3061390B1 (fr) | 2016-12-28 | 2022-12-16 | Overkiz | Procede de configuration, de controle ou de supervision d’une installation domotique |
| KR101768545B1 (ko) * | 2017-03-28 | 2017-08-17 | 주식회사 한미이앤씨 | 배전선로의 전원 분산을 제어하는 장치 |
| EP3432534B1 (en) * | 2017-07-17 | 2021-02-24 | Atos IT Solutions and Services GmbH | Local authorization decision method |
| US10956551B2 (en) * | 2017-08-07 | 2021-03-23 | Clarius Mobile Health Corp. | Systems and methods for securing operation of an ultrasound scanner |
| US11057362B2 (en) * | 2017-10-05 | 2021-07-06 | Ca, Inc. | Adaptive selection of authentication schemes in MFA |
| KR102627115B1 (ko) * | 2017-12-18 | 2024-01-23 | 콘비다 와이어리스, 엘엘씨 | Iot/m2m 서비스 계층에서의 데이터 또는 서비스들에 대한 컨텍스트 인식 허가 |
| US11100246B2 (en) | 2018-04-13 | 2021-08-24 | Mastercard International Incorporated | Computer-implemented methods, systems comprising computer-readable media, and electronic devices for completing queries propagated across a plurality of datasources |
| US11847241B1 (en) * | 2018-04-20 | 2023-12-19 | Amazon Technologies, Inc. | Management of service permissions |
| US11025425B2 (en) | 2018-06-25 | 2021-06-01 | Elasticsearch B.V. | User security token invalidation |
| US11223626B2 (en) * | 2018-06-28 | 2022-01-11 | Elasticsearch B.V. | Service-to-service role mapping systems and methods |
| US11196554B2 (en) | 2018-07-27 | 2021-12-07 | Elasticsearch B.V. | Default password removal |
| US11023598B2 (en) | 2018-12-06 | 2021-06-01 | Elasticsearch B.V. | Document-level attribute-based access control |
| US11297108B2 (en) * | 2018-12-28 | 2022-04-05 | Comcast Cable Communications, Llc | Methods and systems for stateful network security |
| GB2582738B (en) * | 2019-02-01 | 2021-07-07 | Arm Ip Ltd | Electronic device registration mechanism |
| CN116325829A (zh) * | 2020-10-09 | 2023-06-23 | 上海诺基亚贝尔股份有限公司 | 用于动态授权的机制 |
| CN112540788A (zh) * | 2020-12-03 | 2021-03-23 | 南方电网数字电网研究院有限公司 | 一种兼容多厂商无人机飞控应用app的方法 |
| CN114826629A (zh) * | 2021-01-22 | 2022-07-29 | 北京京东方技术开发有限公司 | 数据共享方法、装置、系统、服务器和计算机存储介质 |
| CN112511569B (zh) * | 2021-02-07 | 2021-05-11 | 杭州筋斗腾云科技有限公司 | 网络资源访问请求的处理方法、系统及计算机设备 |
| CN113472778B (zh) * | 2021-06-30 | 2023-04-07 | 中国人民解放军国防科技大学 | 一种信息网络安全防护信任系统及方法 |
| US20230015789A1 (en) * | 2021-07-08 | 2023-01-19 | Vmware, Inc. | Aggregation of user authorizations from different providers in a hybrid cloud environment |
| US11310235B1 (en) * | 2021-08-04 | 2022-04-19 | Netfay Inc. | Internet of things system based on security orientation and group sharing |
| WO2023180364A1 (en) | 2022-03-23 | 2023-09-28 | Curity Ab | Graphql access authorization |
| CN115277145B (zh) * | 2022-07-20 | 2023-05-02 | 北京志凌海纳科技有限公司 | 分布式存储访问授权管理方法、系统、设备和可读介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030191719A1 (en) * | 1995-02-13 | 2003-10-09 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US20080184353A1 (en) * | 2001-09-05 | 2008-07-31 | Patrick Colum Carroll | Dynamic control of authorization to access internet services |
| US20120084831A1 (en) * | 2011-12-13 | 2012-04-05 | At&T Intellectual Property I, L.P. | Method and apparatus for providing privacy management in machine-to-machine communications |
| KR20130133988A (ko) * | 2012-05-30 | 2013-12-10 | 모다정보통신 주식회사 | Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법 |
| KR20150014345A (ko) * | 2013-07-29 | 2015-02-06 | 주식회사 케이티 | 요청 메시지의 신뢰성을 확보하는 방법 및 장치 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7746799B2 (en) * | 2003-06-20 | 2010-06-29 | Juniper Networks, Inc. | Controlling data link layer elements with network layer elements |
| CN101453339B (zh) * | 2006-11-20 | 2011-11-30 | 华为技术有限公司 | 一种网络融合策略计费控制架构的系统及处理方法 |
| US7991902B2 (en) * | 2006-12-08 | 2011-08-02 | Microsoft Corporation | Reputation-based authorization decisions |
| US20080147530A1 (en) * | 2006-12-19 | 2008-06-19 | Kwan Shu-Leung | Programmatically transferring applications between handsets based on license information |
| US9043861B2 (en) * | 2007-09-17 | 2015-05-26 | Ulrich Lang | Method and system for managing security policies |
| CN101453354A (zh) * | 2007-11-29 | 2009-06-10 | 上海未来宽带技术及应用工程研究中心有限公司 | 一种基于atca架构的高可用性系统 |
| KR20130132050A (ko) * | 2012-05-25 | 2013-12-04 | 한국전자통신연구원 | 농업용 환경제어 시스템을 위한 플랫폼 장치 |
| CN103927316A (zh) * | 2013-01-14 | 2014-07-16 | 崔晶渊 | 基于位置的检索系统 |
| CN111726234B (zh) * | 2013-07-24 | 2023-03-24 | 康维达无线有限责任公司 | 服务域收费系统和方法 |
| US9536065B2 (en) * | 2013-08-23 | 2017-01-03 | Morphotrust Usa, Llc | System and method for identity management |
| US10021103B2 (en) * | 2014-02-21 | 2018-07-10 | Samsung Electronics Co., Ltd. | Service authorization methods and apparatuses |
| US20190318348A1 (en) * | 2018-04-13 | 2019-10-17 | Dubset Media Holdings, Inc. | Media licensing method and system using blockchain |
-
2016
- 2016-08-26 KR KR1020187008346A patent/KR102112106B1/ko active IP Right Grant
- 2016-08-26 EP EP16763397.3A patent/EP3342125B1/en active Active
- 2016-08-26 US US15/248,952 patent/US20170063931A1/en active Pending
- 2016-08-26 WO PCT/US2016/048938 patent/WO2017040263A1/en active Application Filing
- 2016-08-26 JP JP2018510739A patent/JP6560442B2/ja active Active
- 2016-08-26 EP EP22163577.4A patent/EP4037360A1/en active Pending
- 2016-08-26 CN CN202111097746.5A patent/CN113766507B/zh active Active
- 2016-08-26 CN CN201680057447.XA patent/CN108141446B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030191719A1 (en) * | 1995-02-13 | 2003-10-09 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US20080184353A1 (en) * | 2001-09-05 | 2008-07-31 | Patrick Colum Carroll | Dynamic control of authorization to access internet services |
| US20120084831A1 (en) * | 2011-12-13 | 2012-04-05 | At&T Intellectual Property I, L.P. | Method and apparatus for providing privacy management in machine-to-machine communications |
| KR20130133988A (ko) * | 2012-05-30 | 2013-12-10 | 모다정보통신 주식회사 | Ｍ2ｍ 통신에서 리소스 접근 권한 설정 방법 |
| KR20150014345A (ko) * | 2013-07-29 | 2015-02-06 | 주식회사 케이티 | 요청 메시지의 신뢰성을 확보하는 방법 및 장치 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021251713A1 (ko) * | 2020-06-11 | 2021-12-16 | 박정훈 | 사물 인터넷 기기를 활용한 스트리밍 방송 후원 시스템 |
| US11863833B2 (en) | 2020-06-11 | 2024-01-02 | Jung Hun PARK | Streaming broadcast sponsorship system using internet of things device |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3342125A1 (en) | 2018-07-04 |
| CN108141446A (zh) | 2018-06-08 |
| CN113766507B (zh) | 2024-02-23 |
| US20170063931A1 (en) | 2017-03-02 |
| CN108141446B (zh) | 2021-10-15 |
| JP6560442B2 (ja) | 2019-08-14 |
| WO2017040263A1 (en) | 2017-03-09 |
| JP2018533857A (ja) | 2018-11-15 |
| EP3342125B1 (en) | 2022-04-27 |
| KR102112106B1 (ko) | 2020-05-18 |
| CN113766507A (zh) | 2021-12-07 |
| EP4037360A1 (en) | 2022-08-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102112106B1 (ko) | 서비스 계층 동적 권한부여 | |
| US20210084044A1 (en) | Resource-driven dynamic authorization framework | |
| US11387978B2 (en) | Systems and methods for securing access rights to resources using cryptography and the blockchain | |
| US11522865B2 (en) | Automated IoT device configuration using user profile | |
| US9319413B2 (en) | Method for establishing resource access authorization in M2M communication | |
| US11683353B2 (en) | Automated service enrollment in a machine-to-machine communications network | |
| CN107113182B (zh) | 用于在服务层处支持协商服务的方法、装置和联网的系统 | |
| US9319412B2 (en) | Method for establishing resource access authorization in M2M communication | |
| US20140127994A1 (en) | Policy-based resource access via nfc | |
| JP7194736B2 (ja) | ＩｏＴ／Ｍ２Ｍサービス層のデータまたはサービスに対するコンテキストアウェア認証 | |
| CN116405266B (zh) | 基于零信任联盟系统的信任评估方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant |