KR102488798B1 - 서비스 ａｐｉ 호출 방법 및 관련 장치 - Google Patents

서비스 ａｐｉ 호출 방법 및 관련 장치 Download PDF

Info

Publication number
KR102488798B1
KR102488798B1 KR1020207032274A KR20207032274A KR102488798B1 KR 102488798 B1 KR102488798 B1 KR 102488798B1 KR 1020207032274 A KR1020207032274 A KR 1020207032274A KR 20207032274 A KR20207032274 A KR 20207032274A KR 102488798 B1 KR102488798 B1 KR 102488798B1
Authority
KR
South Korea
Prior art keywords
api
security method
function entity
caller
delete delete
Prior art date
Application number
KR1020207032274A
Other languages
English (en)
Other versions
KR20200141483A (ko
Inventor
융 왕
카이 판
추이리 거
징 천
Original Assignee
후아웨이 테크놀러지 컴퍼니 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 후아웨이 테크놀러지 컴퍼니 리미티드 filed Critical 후아웨이 테크놀러지 컴퍼니 리미티드
Publication of KR20200141483A publication Critical patent/KR20200141483A/ko
Application granted granted Critical
Publication of KR102488798B1 publication Critical patent/KR102488798B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • 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/133—Protocols for remote procedure calls [RPC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 출원의 실시예는 통신 기술 분야에 관한 것이며, 서비스 애플리케이션 프로그래밍 인터페이스((plication programming interface, API) 호출 방법을 제공한다. API 공개 기능 엔티티에 적용되는 보안 방법은 원래의 보안 방법으로부터 새로운 보안 방법으로 업데이트된다. API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자(invoker) 사이의 통신에 사용된다. 방법은: 호출자가 API 공개 기능 엔티티의 새로운 보안 방법을 획득하는 단계; 및 호출자가 새로운 보안 방법을 사용하여 API 공개 기능 엔티티에 제1 호출 요청을 전송하는 단계를 포함하며, 제1 호출 요청은 서비스 API의 이름을 포함하고, 제1 호출 요청은 서비스 API를 호출하는 데 사용된다. 본 출원의 실시예에서의 솔루션을 사용하면, 서비스 API가 보안 방법의 불일치로 인해 호출되지 않는 문제가 회피될 수 있다.

Description

서비스 ＡＰＩ 호출 방법 및 관련 장치
본 출원은 2018년 4월 9일 중국 국가 지적 재산 관리국에 출원되고 발명의 명칭이 "서비스 API 호출 방법 및 관련 장치"인 중국특허출원 No. 201810312734.1에 대한 우선권을 주장하며, 상기 문헌은 본 명세서에 그 전문이 참조로서 포함된다.
본 출원은 통신 기술 분야에 관한 것이며, 특히 서비스 API 호출 방법 및 관련 장치에 관한 것이다.
3세대 파트너쉽 프로젝트(3rd Generation Partnership Project, 3GPP)는 노스바운드(Northbound) 애플리케이션 프로그래밍 인터페이스(application programming interface, API)와 관련된 여러 사양을 정의한다. 서로 다른 API 사양 간의 반복 및 불일치를 피하기 위해 3GPP는 모든 Northbound API에 적용할 수 있는 공통 기능이 있는 공통 API 프레임워크(common API framework, CAPIF)를 개발하는 것을 고려한다. 일반적으로 CAPIF는 캐리어 네트워크에 배포된다.
도 1은 CAPIF 기반 아키텍처의 개략도이다. 도 1에 도시된 아키텍처는 주로 다음의 네트워크 요소를 포함한다.
API 호출자(API invoker): API 호출자는 일반적으로 캐리어 네트워크와 서비스 계약을 맺은 서드-파티 애플리케이션 제공자에 의해 제공된다.
서비스 API(service API): 서비스 API는 API 호출자에게 서비스를 제공하는 인터페이스이다.
CAPIF 코어 기능(CAPIF core function) 엔티티: CAPIF 코어 기능 엔티티는 서비스 API의 모든 정책의 중앙 저장소이며 인증 및 권한 부여를 위한 API 호출자 및 서비스 API의 중심이다.
CAPIF API: CAPIF API는 API 호출자에 대해 CAPIF 코어 기능 엔티티 엔트리가 제공되는 인터페이스이다.
API 공개 기능(API exposing function, AEF) 엔티티: API 공개 기능 엔티티는 서비스 제공자가 외부 시스템에 서비스를 개방하기 위한 엔트리이다. API 호출자는 AEF 엔티티를 사용하여 서비스 공급자가 제공하는 서비스를 사용할 수 있다.
API 게시 기능(API publishing function) 엔티티: API 게시 기능 엔티티는 서비스 API에 대한 정보를 CAPIF 코어 기능 엔티티에 게시하여 API 호출자가 CAPIF 코어 기능 엔티티에서 서비스 API에 대한 정보를 찾을 수 있도록 한다.
API 관리 기능(API management function) 엔티티: API 관리 기능 엔티티는 서비스 API를 관리하는데, 예를 들어, 서비스 API의 상태를 모니터링하고 호출 정보를 기록한다.
도 1에서 공중 지상 이동망 신뢰 도메인(public land mobile network trust domain, PLMN trust domain)은 공중 지상 이동망이 신뢰하는 영역을 나타낸다. API 공급자 도메인(API provider domain)은 API 공급자가 있는 영역을 나타낸다.
전술한 네트워크 요소들 간의 연결 관계는 다음과 같다:
PLMN 신뢰 도메인 외부의 API 호출자와 CAPIF 코어 기능 엔티티 간의 인터페이스는 CAPIF-1e 인터페이스이고, PLMN 신뢰 도메인 외부의 API 호출자와 AEF 엔티티 간의 인터페이스는 CAPIF-2e 인터페이스이다. PLMN 신뢰 도메인의 API 호출자와 CAPIF 코어 기능 엔티티 간의 인터페이스는 CAPIF-1 인터페이스이고, API 호출자와 AEF 엔티티 간의 인터페이스는 CAPIF-2 인터페이스이다. CAPIF 코어 기능 엔티티와 AEF 엔티티 간의 인터페이스는 CAPIF-3 인터페이스이고, CAPIF 코어 기능 엔티티와 API 게시 기능 엔티티 간의 인터페이스는 CAPIF-4 인터페이스이며, CAPIF 코어 기능 엔티티와 API 관리 기능은 CAPIF-5 인터페이스이다.
현재, API 호출자가 서비스 API를 호출하기 전에 API 호출자와 CAPIF 코어 기능 엔티티는 API 호출자와 AEF 엔티티간에 사용되는 보안 방법을 협상한다. 그런 다음 서비스 API를 호출할 때 API 호출자는 보안 방법을 사용하여 AEF 엔티티로부터 서비스 API를 호출한다. 그렇지만, 보안 방법이 업데이트된 경우는 기존 방법에서 고려되지 않으며, 보안 방법이 업데이트되지만 API 호출자가 여전히 원래의 보안 방법을 사용하여 서비스 API를 호출하면 서비스 API를 성공적으로 호출할 수 없다.
본 출원의 실시예들은 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 피하기 위해 서비스 API 호출 방법 및 관련 장치를 제공한다.
제1 관점에 따르면, 본 출원의 실시예는 서비스 API 호출 방법을 제공한다. API 공개 기능 엔티티에 적용된 보안 방법은 원래의 보안 방법으로부터 새로운 보안 방법으로 업데이트되고, API 공개 기능 엔티티와 호출자 간의 통신에는 API 공개 기능 엔티티의 보안 방법이 사용된다. 방법은: 호출자(invoker)가 API 공개 기능 엔티티(exposing function entity)의 새로운 보안 방법을 획득하는 단계; 및 상기 호출자가 상기 새로운 보안 방법을 사용하여 API 공개 기능 엔티티에 제1 호출 요청을 전송하는 단계 - 상기 제1 호출 요청은 서비스 API의 이름을 포함하고, 상기 제1 호출 요청은 상기 서비스 API를 호출하는 데 사용됨 - 를 포함한다.
API 공개 기능 엔티티의 보안 방법이 API 공개 기능 엔티티와 호출자 간의 통신에 사용된다는 것은 다음을 포함할 수 있다: API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 인증, 권한 부여 및 보호에 사용된다.
본 출원의 이 실시예의 솔루션에 따르면, API 공개 기능 엔티티의 보안 방법이 업데이트되면, 호출자는 API 공개 기능 엔티티의 새로운 보안 방법을 적시에 획득하고 새로운 보안 방법을 사용하여 API공개 기능 엔티티로부터 서비스 API를 호출하여 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 회피한다.
가능한 설계에서, 호출자는 다음과 같은 방식으로 API 공개 기능 엔티티의 새로운 보안 방법을 획득할 수 있다: 제1 방식에서, 호출자는 공통 API 프레임워크 (common API framework, CAPIF) 코어 기능 엔티티로부터 새로운 보안 방법을 수신하고; 제2 방식에서, 호출자는 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신한다.
일 예에서, 제1 방식이 사용될 때, 호출자가 공통 API 프레임워크 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 수신하기 전에, 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 추가로 요청할 수 있다. 예를 들어, 호출자는 획득 요청을 CAPIF 코어 기능 엔티티에 전송할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
다른 예에서, 제2 방식이 사용될 때, 호출자가 API 공개 기능 엔티티의 새로운 보안 방법을 획득하기 전에, 호출자는 API 공개 기능 엔티티에 보안 방법 협상 요청을 더 전송할 수 있으며, 보안 방법 협상 요청에는 호출자에 의해 지원되는 보안 방법 목록과 보안 방법 목록에는 새로운 보안 방법이 포함된다. 이에 따라 호출자는 API 공개 기능 엔티티로부터 보안 방법 협상 응답을 수신할 수 있으며, 여기서 보안 방법 협상 응답에는 새로운 보안 방법이 포함된다.
이 설계 및 이 설계의 앞의 두 가지 예에서, 호출자가 API 공개 기능 엔티티의 새로운 보안 방법을 획득하기 전에, 호출자는 원래의 보안을 사용하여 API 공개 기능 엔티티에 제2 호출 요청을 추가로 전송할 수 있으며, 제2 호출 요청은 서비스 API를 호출하는 데 사용되며; 그리고 API 공개 기능 엔티티로부터 제2 호출 요청의 응답 메시지를 수신하며, 여기서 제2 호출 요청의 응답 메시지는 원인 값을 포함하고, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
또 다른 예에서, 제2 방식이 사용될 때, 호출자가 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신하기 전에, 호출자는 원래의 보안을 사용하여 API 공개 기능 엔티티에 제3 호출 요청을 더 전송할 수 있으며, 제3 호출 요청은 서비스 API를 호출하는 데 사용된다. 이에 상응해서, 호출자는 API 공개 기능 엔티티로부터 제3 호출 요청의 응답 메시지를 수신할 수 있으며, 여기서 제3 호출 요청의 응답 메시지에는 새로운 보안 방법과 원인 값이 포함되어 있으며, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
가능한 설계에서, 호출자는 API 공개 기능 엔티티로부터 제1 호출 요청의 응답 메시지를 추가로 수신할 수 있으며, 여기서 제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출었음을 나타내는 데 사용된다.
제2 관점에 따르면, 본 출원의 실시예는 다른 서비스 애플리케이션 프로그래밍 인터페이스 (application programming interface, API) 호출 방법을 제공한다. API 공개 기능 엔티티에 적용된 보안 방법은 원래의 보안 방법에서 새로운 보안 방법으로 업데이트되고, API 공개 기능 엔티티와 호출자 간의 통신에는 API 공개 기능 엔티티의 보안 방법이 사용된다. 방법은: 공통 API 프레임워크(common API framework, CAPIF) 코어 기능 엔티티가 API 게시 기능 엔티티로부터 API 공개 기능에 대한 업데이트 요청을 수신하는 단계 - 상기 업데이트 요청은 상기 API 게시 기능의 새로운 보안 방법을 포함함 - ; 및 상기 CAPIF 코어 기능 엔티티가 상기 새로운 보안 방법을 저장하는 단계를 포함한다.
API 공개 기능 엔티티의 보안 방법이 API 공개 기능 엔티티와 호출자 간의 통신에 사용되는 것은 다음을 포함할 수 있다: API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 인증, 권한 부여 및 보호에 사용된다.
가능한 설계에서, CAPIF 코어 기능 엔티티는 새로운 보안 방법을 호출자에게 더 전송할 수 있다.
가능한 설계에서, 업데이트 요청은 지시 정보를 더 포함할 수 있으며, 여기서 지시 정보는 CAPIF 코어 기능 엔티티에게 새로운 보안 방법을 호출자에게 전송하도록 명령하는 데 사용된다.
다른 가능한 설계에서, CAPIF 코어 기능 엔티티가 호출자에게 새로운 보안 방법을 전송하기 전에, CAPIF 코어 기능 엔티티는 호출자로부터 획득 요청을 추가로 수신할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
가능한 설계에서, CAPIF 코어 기능 엔티티는 호출자, 새로운 보안 방법 및 API 공개 기능 엔티티 간의 대응관계를 저장할 수 있다.
제3 관점에 따르면, 본 출원의 실시예는 또 다른 서비스 애플리케이션 프로그래밍 인터페이스 API 호출 방법을 제공한다. API 공개 기능 엔티티에 적용된 보안 방법은 원래의 보안 방법에서 새로운 보안 방법으로 업데이트되고, API 공개 기능 엔티티와 호출자 간의 통신에는 API 공개 기능 엔티티의 보안 방법이 사용된다. 방법은: API 공개 기능 엔티티가 새로운 보안 방법을 사용하여 호출자에 의해 전송된 제1 호출 요청을 수신하는 단계 - 상기 제1 호출 요청은 서비스 API의 이름을 포함하고, 상기 제1 호출 요청은 서비스 API를 호출하는 데 사용됨 - ; 및 상기 API 공개 기능 엔티티가 상기 새로운 보안 방법을 사용하여 상기 호출자를 입증하는 단계를 포함한다.
API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 통신에 사용되는 것은 다음을 포함할 수 있다: API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 인증, 권한 부여 및 보호에 사용된다.
가능한 설계에서, API 공개 기능 엔티티가 새로운 보안 방법을 사용하여 호출자에 의해 전송된 제1 호출 요청을 수신하기 전에, API 공개 기능 엔티티는 새로운 보안 방법을 호출자에게 더 전송할 수 있다.
일 예에서, API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에, API 공개 기능 엔티티는 호출자로부터 보안 방법 협상 요청을 추가로 수신할 수 있으며, 여기서 보안 방법 협상 요청은 호출자에 의해 지원되는 보안 목록을 포함하고, 보안 방법 목록에는 새로운 보안 방법이 포함되고; 그리고 보안 방법 협상 응답을 호출자에게 전송하며, 여기서 보안 방법 협상 응답은 새로운 보안 방법을 포함한다.
가능한 설계에서, API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에, API 공개 기능 엔티티는 원래의 보안 방법을 사용하여 호출자에 의해 전송된 제2 호출 요청을 추가로 수신할 수 있으며, 제2 호출 요청은 서비스 API를 호출하는 데 사용되고; 그리고 호출자에게 제2 호출 요청의 응답 메시지를 전송하고, 여기서 제2 호출 요청의 응답 메시지는 서비스 API가 호출되지 않았음을 나타내는 데 사용된다.
예를 들어, 제2 호출 요청의 응답 메시지에는 원인 값이 포함되어 있으며, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
가능한 설계에서, API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에, API 공개 기능 엔티티는 원래의 보안 방법을 사용하여 호출자에 의해 전송된 제3 호출 요청을 추가로 수신할 수 있으며, 여기서 제3 호출은 요청은 서비스 API를 호출하는 데 사용된다. 이에 상응해서, API 공개 기능 엔티티는 제3 호출 요청의 응답 메시지를 호출자에게 전송할 수 있으며, 여기서 제3 호출 요청의 응답 메시지에는 API 공개 기능 엔티티의 새로운 보안 방법과 원인 값을 포함하며, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
가능한 설계에서, API 공개 기능 엔티티는 호출자에게 제1 호출 요청의 응답 메시지를 추가로 전송할 수 있으며, 여기서 제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출었음을 나타내는 데 사용된다.
제4 관점에 따르면, 본 출원의 실시예는 서비스 API 호출 방법을 제공한다. 서비스 애플리케이션 프로그래밍 인터페이스 API에 적용된 보안 방법이 기존 보안 방법에서 새로운 보안 방법으로 업데이트된다. 이 방법은: 호출자가 서비스 API의 새로운 보안 방법을 획득하는 단계; 및 호출자가 새로운 보안 방법을 사용하여 API 공개 기능 엔티티에 제1 호출 요청을 전송하는 단계를 포함하며, 여기서 제1 호출 요청은 서비스 API의 이름을 포함하고, 제1 호출 요청은 서비스 API를 호출하는 데 사용된다.
본 출원의 이 실시예의 솔루션에 따르면, 서비스 API의 보안 방법이 업데이트되면, 호출자는 서비스 API의 새로운 보안 방법을 적시에 획득할 수 있으며, 새로운 보안 방법을 사용하여 API 공개 기능 엔티티로부터 서비스 API를 호출하여 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 회피한다.
가능한 설계에서, 호출자는 다음과 같은 방식으로 서비스 API의 새로운 보안 방법을 획득할 수 있다: 제1 방식에서, 호출자는 공통 API 프레임워크 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 수신한다. 제2 방식에서: 호출자는 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신한다.
일 예에서, 제1 방식이 사용될 때, 호출자가 공통 API 프레임워크 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 수신하기 전에, 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 추가로 요청할 수 있다. 예를 들어, 호출자는 획득 요청을 CAPIF 코어 기능 엔티티에 전송할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
다른 예에서, 제2 방식이 사용될 때, 호출자가 서비스 API의 새로운 보안 방법을 획득하기 전에, 호출자는 API 공개 기능 엔티티에 보안 방법 협상 요청을 더 전송할 수 있으며, 여기서 보안 방법 협상 요청은 호출자에 의해 지원되는 보안 방법 목록을 포함하고 보안 방법 목록에는 새로운 보안 방법이 포함된다. 이에 상응해서, 호출자는 API 공개 기능 엔티티로부터 보안 방법 협상 응답을 수신할 수 있으며, 여기서 보안 방법 협상 응답에는 새로운 보안 방법이 포함된다.
이 설계 및 이 설계의 앞의 두 가지 예에서, 호출자가 서비스 API의 새로운 보안 방법을 획득하기 전에, 호출자는 원래의 보안 방법을 사용하여 API 공개 기능 엔티티에 제2 호출 요청을 더 전송할 수 있으며, 제2 호출 요청은 서비스 API를 호출하는 데 사용되며; 그리고 API 공개 기능 엔티티로부터 제2 호출 요청의 응답 메시지를 수신하고, 여기서 제2 호출 요청의 응답 메시지는 원인 값을 포함하고, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
또 다른 예에서, 제2 방식이 사용될 때, 호출자가 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신하기 전에, 호출자는 원래의 보안 방법을 사용하여 API 공개 기능 엔티티에 제3 호출 요청을 더 전송할 수 있다. 제3 호출 요청은 서비스 API를 호출하는 데 사용된다. 이에 따라 호출자는 API 공개 기능 엔티티로부터 제3 호출 요청의 응답 메시지를 수신할 수 있으며, 여기서 제3 호출 요청의 응답 메시지에는 새로운 보안 방법과 원인 값이 포함되어 있으며, 원인 값은 보안 방법이 일치하지 않아 서비스 API를 호출하지 못했습니다.
가능한 설계에서, 호출자는 API 공개 기능 엔티티로부터 제1 호출 요청의 응답 메시지를 추가로 수신할 수 있으며, 여기서 제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출었음을 나타내는 데 사용된다.
제5 관점에 따르면, 본 출원의 실시예는 다른 서비스 애플리케이션 프로그래밍 인터페이스 API 호출 방법을 제공한다. 서비스 애플리케이션 프로그래밍 인터페이스 (application programming interface, API)에 적용된 보안 방법이 기존 보안 방법에서 새로운 보안 방법으로 업데이트된다. 이 방법은: 공통 API 프레임워크 (common API framework, CAPIF) 코어 기능 엔티티가 API 게시 기능 엔티티로부터 API 공개 기능에 대한 업데이트 요청을 수신는 단계 - 업데이트 요청은 서비스 API의 새로운 보안 방법을 포함함 - ; 및 CAPIF 코어 기능 엔티티가 새로운 보안 방법을 저장하는 단계를 포함한다.
가능한 설계에서 CAPIF 코어 기능 엔티티는 새로운 보안 방법을 호출자에게 더 전송할 수 있다.
가능한 설계에서, 업데이트 요청은 지시 정보를 더 포함할 수 있으며, 여기서 지시 정보는 CAPIF 코어 기능 엔티티에게 새로운 보안 방법을 호출자에게 전송하도록 명령하는 데 사용된다.
다른 가능한 설계에서, CAPIF 코어 기능 엔티티가 호출자에게 새로운 보안 방법을 전송하기 전에, CAPIF 코어 기능 엔티티는 호출자로부터 획득 요청을 추가로 수신할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
가능한 설계에서, CAPIF 코어 기능 엔티티는 호출자의 식별자, 새로운 보안 방법 및 서비스 API의 이름 간의 대응관계를 저장할 수 있다. 예를 들어, CAPIF 코어 기능 엔티티는 호출자의 식별자, 새로운 보안 방법, 서비스 API의 이름, API 공개 기능 엔티티 간의 대응관계를 저장할 수 있다.
제6 관점에 따르면, 본 출원의 실시예는 또 다른 서비스 애플리케이션 프로그래밍 인터페이스 (application programming interface, API) 호출 방법을 제공한다. 서비스 애플리케이션 프로그래밍 인터페이스(API)에 적용된 보안 방법이 기존 보안 방법에서 새로운 보안 방법으로 업데이트된다. 이 방법은: API 공개 기능 엔티티가 새로운 보안 방법을 사용하여 호출자에 의해 전송된 제1 호출 요청을 수신하는 단계 - 제1 호출 요청음 서비스 API의 이름을 포함하고, 제1 호출 요청은 서비스 API를 호출하는 데 사용됨 - ; 및 API 공개 기능 엔티티가 새로운 보안 방법을 사용하여 호출자를 입증하는 단계를 포함한다.
가능한 설계에서, API 공개 기능 엔티티가 새로운 보안 방법을 사용하여 호출자에 의해 전송된 제1 호출 요청을 수신하기 전에, API 공개 기능 엔티티는 새로운 보안 방법을 호출자에게 더 전송할 수 있다.
예를 들어, API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에 API 공개 기능 엔티티는 호출자로부터 보안 방법 협상 요청을 추가로 수신하고, 여기서 보안 방법 협상 요청은 호출자에 의해 지원되는 보안 방법 목록을 포함하고, 보안 방법 목록은 새로운 보안 방법이 포함하며; 그리고 보안 방법 협상 응답을 호출자에게 전송하며, 여기서 보안 방법 협상 응답은 새로운 보안 방법을 포함한다.
가능한 설계에서, API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에, API 공개 기능 엔티티는 원래의 보안 방법을 사용하여 호출자가 전송한 제2 호출 요청을 추가로 수신할 수 있으며, 여기서 제2 호출은 요청은 서비스 API를 호출하는 데 사용되며; 그리고 호출자에게 제2 호출 요청의 응답 메시지를 전송하고, 여기서 제2 호출 요청의 응답 메시지는 서비스 API가 호출되지 않았음을 나타내는 데 사용된다.
일 예에서, 제2 호출 요청의 응답 메시지는 원인 값을 포함하고, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
가능한 설계에서 API 공개 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하기 전에 API 공개 기능 엔티티는 원래의 보안 방법을 사용하여 호출자가 전송한 제3 호출 요청을 추가로 수신할 수 있으며, 여기서 제3 호출 요청은 서비스 API를 호출하는 데 사용된다. 이에 상응해서, API 공개 기능 엔티티는 제3 호출 요청의 응답 메시지를 호출자에게 전송할 수 있으며, 여기서 제3 호출 요청의 응답 메시지은 API 공개 기능 엔티티의 새로운 보안 방법과 원인 값을 포함하며, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
가능한 설계에서, API 공개 기능 엔티티는 호출자에게 제1 호출 요청의 응답 메시지를 더 전송할 수 있으며, 여기서 제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출었음을 나타내는 데 사용된다.
제7 관점에 따르면, 본 출원의 실시예는 장치를 제공한다. 장치는 전술한 방법 설계에서 호출자의 동작을 구현하는 기능을 갖는다. 기능은 하드웨어로 구현되거나 해당 소프트웨어를 실행하는 하드웨어로 구현될 수 있다. 하드웨어 또는 소프트웨어는 전술한 기능에 대응하는 하나 이상의 모듈을 포함한다. 예를 들어, 장치는 호출자이거나 호출자의 칩일 수 있다.
가능한 설계에서, 장치는 호출자이고, 호출자는 프로세서를 포함하고, 프로세서는 전술한 방법에서 대응하는 기능을 수행할 때 호출자를 지원하도록 구성된다. 또한, 호출자는 통신 인터페이스를 더 포함할 수 있으며, 여기서 통신 인터페이스는 호출자와 중앙 유닛의 사용자 평면 엔티티 간의 통신 또는 호출자와 다른 네트워크 요소 간의 통신을 지원하도록 구성된다. 또한, 호출자는 메모리를 더 포함할 수 있으며, 여기서 메모리는 프로세서에 연결되도록 구성되고, 메모리는 호출자에게 필요한 프로그램 명령 및 데이터를 저장한다.
제8 관점에 따르면, 본 출원의 실시예는 장치를 제공한다. 장치는 전술한 방법 설계에서 CAPIF 코어 기능 엔티티의 동작을 구현하는 기능을 갖는다. 기능은 하드웨어로 구현되거나 해당 소프트웨어를 실행하는 하드웨어로 구현될 수 있다. 하드웨어 또는 소프트웨어는 전술한 기능에 대응하는 하나 이상의 모듈을 포함한다. 예를 들어, 장치는 CAPIF 코어 기능 엔티티일 수 있거나 CAPIF 코어 기능 엔티티 내의 칩일 수 있다.
가능한 설계에서, 장치는 CAPIF 코어 기능 엔티티이고, CAPIF 코어 기능 엔티티는 프로세서를 포함하고, 프로세서는 전술한 방법에서 대응하는 기능을 수행할 때 CAPIF 코어 기능 엔티티를 지원하도록 구성된다. 또한, CAPIF 코어 기능 엔티티는 통신 인터페이스를 더 포함할 수 있으며, 여기서 통신 인터페이스는 CAPIF 코어 기능 엔티티와 중앙 유닛의 사용자 평면 엔티티 사이의 통신 또는 CAPIF 코어 기능 엔티티와 다른 네트워크 요소 사이의 통신을 지원하도록 구성된다. 또한, CAPIF 코어 기능 엔티티는 메모리를 더 포함할 수 있으며, 여기서 메모리는 프로세서에 연결되도록 구성되고, 메모리는 CAPIF 코어 기능 엔티티에 필요한 프로그램 명령 및 데이터를 저장한다.
제9 관점에 따르면, 본 출원의 실시예는 장치를 제공한다. 장치는 전술한 방법 설계에서 API 공개 기능 엔티티의 동작을 구현하는 기능을 갖는다. 기능은 하드웨어로 구현되거나 해당 소프트웨어를 실행하는 하드웨어로 구현될 수 있다. 하드웨어 또는 소프트웨어는 전술한 기능에 대응하는 하나 이상의 모듈을 포함한다. 예를 들어, 장치는 API 공개 기능 엔티티가거나 API 공개 기능 엔티티 내의 칩일 수 있다.
가능한 설계에서, 장치는 API 공개 기능 엔티티이고, API 공개 기능 엔티티는 프로세서를 포함하고, 프로세서는 전술한 방법에서 해당 기능을 수행할 때 API 공개 기능 엔티티를 지원하도록 구성된다. 또한, API 공개 기능 엔티티는 통신 인터페이스를 더 포함할 수 있으며, 여기서 통신 인터페이스는 API 공개 기능 엔티티와 중앙 유닛의 사용자 평면 엔티티 간의 통신 또는 API 공개 기능 엔티티와 다른 네트워크 요소 간의 통신을 지원하도록 구성된다. 또한, API 공개 기능 엔티티는 메모리를 더 포함할 수 있으며, 여기서 메모리는 프로세서와 연결되도록 구성되고, 메모리는 API 공개 기능 엔티티에 필요한 프로그램 명령 및 데이터를 저장한다.
제10 관점에 따르면, 본 출원의 실시예는 통신 시스템을 제공한다. 시스템은 전술한 관점에 따라 호출자 및 API 공개 기능 엔티티를 포함한다. 대안으로, 시스템은 전술한 관점에 따라 호출자, API 공개 기능 엔티티 및 CAPIF 코어 기능 엔티티를 포함한다.
제11 관점에 따르면, 본 출원의 실시예는 호출자에 의해 사용되는 컴퓨터 소프트웨어 명령을 저장하도록 구성된 컴퓨터 저장 매체를 제공한다. 컴퓨터 소프트웨어 명령은 제1 관점 또는 제4 관점에서 호출자의 동작을 구현하도록 설계된 프로그램을 포함한다.
제12 관점에 따르면, 본 출원의 실시예는 API 공개 기능 엔티티에 의해 사용되는 컴퓨터 소프트웨어 명령어를 저장하도록 구성된 컴퓨터 저장 매체를 제공한다. 컴퓨터 소프트웨어 명령어는 제3 관점 또는 제6 관점에서 API 공개 기능 엔티티의 동작을 구현하도록 설계된 프로그램을 포함한다.
제13 관점에 따르면, 본 출원의 실시예는 전술한 CAPIF 코어 기능 엔티티에 의해 사용되는 컴퓨터 소프트웨어 명령을 저장하도록 구성된 컴퓨터 저장 매체를 제공한다. 컴퓨터 소프트웨어 명령은 제2 관점 또는 제4 관점에서 전술한 CAPIF 코어 기능 엔티티의 동작을 구현하도록 설계된 프로그램을 포함한다.
제14 관점에 따르면, 본 출원의 실시예는 호출자에게 적용되는 칩 시스템을 제공한다. 칩 시스템은 적어도 하나의 프로세서, 메모리 및 인터페이스 회로를 포함한다. 메모리, 송수신기 및 적어도 하나의 프로세서는 라인을 사용하여 상호 연결되고 메모리는 명령을 저장한다. 명령은 전술한 방법에서 호출자의 동작을 수행하기 위해 적어도 하나의 프로세서에 의해 실행된다.
제15 관점에 따르면, 본 출원의 실시예는 API 공개 기능 엔티티에 적용되는 칩 시스템을 제공한다. 칩 시스템은 적어도 하나의 프로세서, 메모리 및 인터페이스 회로를 포함한다. 메모리, 송수신기 및 적어도 하나의 프로세서는 라인을 사용하여 상호 연결되고, 적어도 하나의 메모리는 명령어를 저장한다. 이 명령은 프로세서에 의해 실행되어 전술한 방법에서 API 공개 기능 엔티티의 작동을 수행한다.
제16 관점에 따르면, 본 출원의 실시예는 CAPIF 코어 기능 엔티티에 적용되는 칩 시스템을 제공한다. 칩 시스템은 적어도 하나의 프로세서, 메모리 및 인터페이스 회로를 포함한다. 메모리, 송수신기 및 적어도 하나의 프로세서는 라인을 사용하여 상호 연결되고, 적어도 하나의 메모리는 명령어를 저장한다. 명령은 프로세서에 의해 실행되어 전술한 방법에서 CAPIF 코어 기능 엔티티의 작동을 수행한다.
종래 기술과 비교하여, 본 출원의 실시예의 솔루션에서, API 공개 기능 엔티티의 보안 방법이 업데이트된 후, 호출자는 API 공개 기능 엔티티의 새로운 보안 방법을 적시에 획득하고 서비스를 호출할 수 있다. 새로운 보안 방법을 사용하여 API를 사용하여 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 방지한다.
도 1은 본 출원의 실시예에 따른 CAPIF 기반 아키텍처의 개략도이다.
도 2는 API를 호출하는 개략적인 통신 다이어그램이다.
도 3a는 본 출원의 실시예에 따른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 3b는 본 출원의 실시예에 따른 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 4는 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 5는 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 6은 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 7은 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다.
도 8은 본 출원의 실시예에 따른 장치의 개략적인 블록도이다.
도 9는 본 출원의 실시예에 따른 장치의 개략적인 구조도이다.
다음은 본 출원의 실시예에서 첨부된 도면을 참조하여 본 출원의 실시예에서의 기술적 솔루션을 설명한다.
본 출원의 실시예에서 설명된 네트워크 아키텍처 및 애플리케이션 시나리오는 본 출원의 실시예에서 기술적 솔루션을 보다 명확하게 설명하기 위한 것이지만, 본 출원의 실시예에서 제공되는 기술적 솔루션을 제한하려는 것은 아니다. 당업자는 네트워크 아키텍처가 진화하고 새로운 애플리케이션 시나리오가 등장함에 따라 본 출원의 실시예에서 제공되는 기술적 솔루션이 유사한 기술 문제에도 적용될 수 있음을 알 수 있을 것이다.
본 출원의 실시예에서의 솔루션은 도 1에 도시된 네트워크 아키텍처에 적용될 수 있다. 네트워크 아키텍처는 백그라운드에서 자세히 설명되며 여기서 다시 설명하지 않는다. 현재, 도 1에 도시된 네트워크 아키텍처에서, API는 일반적으로 도 2에 도시된 절차를 사용하여 호출된다. 도 2에 도시된 바와 같이, 호출 프로세스는 다음과 같다.
단계 201: API 게시 기능이 CAPIF 코어 기능에 서비스 API 게시 요청을 전송하며, 여기서 요청은 API 정보를 전달한다. API 정보는 API 이름, API 유형, 인터페이스 정보, 보안 방법 등을 포함할 수 있다.
단계 202: CAPIF 코어 기능은 API 정보를 저장한다.
단계 203: CAPIF 코어 기능은 서비스 API 게시 응답을 API 게시 기능에 전송한다.
CAPIF 코어 기능이 API 정보를 성공적으로 수신하여 저장하면, CAPIF 코어 기능은 게시 응답을 사용하여 API 게시 기능에 API 정보가 성공적으로 게시되었음을 알린다. CAPIF 코어 기능이 API 정보 수신에 실패하거나 API 정보 저장에 실패하면 CAPIF 코어 기능은 게시 응답을 사용하여 API 게시 기능에 API 정보 공개 실패를 알린다.
단계 204: API 호출자가 CAPIF 코어 기능에 서비스 API 발견 요청을 전송하며, 여기서 요청은 API 유형 및 인터페이스 정보를 전달한다.
서비스 API 발견 요청은 API 정보를 질의하는 데 사용된다.
단계 205: CAPIF 코어 기능은 서비스 API 발견 응답을 API 호출자에게 전송하며, 여기서 응답은 API 정보를 전달한다.
또한, CAPIF 코어 기능은 하나의 보안 방법을 선택하여 API 호출자에게 보안 방법을 전송한다. 예를 들어 보안 방법은 특정 서비스 API에 대한 보안 방법이며 API 호출자와 AEF 사이에서 사용된다. 또는 보안 방법은 AEF의 보안 방법일 수 있으며 API 호출자와 AEF 간에 사용된다.
단계 206: API 호출자는 서비스 API 호출 요청을 AEF에 전송한다. 서비스 API 호출 요청은 API 정보를 전달한다.
서비스 제공자가 AEF 상의 서비스 API를 사용하여 API 호출자에게 서비스를 개방하기 때문에, API 호출자는 일반적으로 AEF에 요청을 전송함으로써 서비스 API를 호출한다는 것을 이해할 수 있다.
단계 207: AEF는 API 정보에 포함된 API 이름 및 인터페이스 정보에 대응하는 보안 방법을 획득한다.
구체적으로, AEF는 CAPIF 코어 기능으로부터 API 정보에 포함된 API 이름 및 인터페이스 정보에 대응하는 보안 방법을 획득한다.
단계 208: AEF는 서비스 API 호출 응답을 API 호출자에게 전송한다.
구체적으로, 서비스 API가 호출되면 획득된 보안 방법은 API 호출자와 AEF 간의 인증, 권한 부여 및 보호에 사용된다. 인증 및 권한 부여가 성공하면 API 호출자가 서비스 API에 호출 응답을 전송한다.
앞의 절차는 API 호출자가 처음으로 서비스 API를 호출하는 절차이다. API 호출자는 먼저 CAPIF 코어 기능으로부터 서비스 API에 대한 정보를 찾고 보안 방법을 찾아야 한다. 그 후 API 호출자는 더 이상 CAPIF 코어 기능을 사용하여 보안 방법을 얻을 필요없이 서비스 API를 직접 호출할 수 있다.
그렇지만, 전술한 호출 절차에서 API 공개 기능 엔티티 또는 서비스 API의 보안 방법이 업데이트되는 경우는 고려하지 않았다. API 공개 기능 엔티티 또는 서비스 API의 보안 방법이 업데이트 되었으나 API 호출자가 206 단계에서 업데이트 이전에 보안 방법을 사용하여 여전히 서비스 API를 호출하면 서비스 API를 성공적으로 호출할 수 없다. 현재 이 문제에 대한 해결책은 업계에서 제공되지 않고 있다.
이를 고려하여, API 공개 기능 엔티티 또는 서비스 API의 보안 방법이 업데이트될 때, 본 출원의 다음 실시예는 각각 대응하는 호출 방법을 제공한다.
API 공개 기능 엔티티의 보안 방법이 업데이트되면, 본 출원의 실시예는 서비스 API 호출 방법과 이를 기반으로 하는 호출자, CAPIF 코어 기능 엔티티 및 API 공개 기능 엔티티를 제공한다. 다음은 도 3a를 참조하여 서비스 API 호출 방법을 설명한다.
도 3a는 본 출원의 실시예에 따른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 3a에 도시된 방법을 구현하기 위한 전제 조건은 API 공개 기능 엔티티의 보안 방법을 원래의 보안 방법에서 새로운 보안 방법으로 업데이트하는 것이다. API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 통신에 사용된다. 예를 들어, API 공개 기능 엔티티의 보안 방법은 API 공개 기능 엔티티와 호출자 간의 인증, 권한 부여 및 보호에 사용될 수 있다. 도 3a에 도시된 방법은 다음 단계를 포함한다.
단계 301: CAPIF 코어 기능 엔티티는 API 게시 기능 엔티티로부터 API 공개 기능에 대한 업데이트 요청을 수신하며, 여기서 업데이트 요청은 API 공개 기능의 새로운 보안 방법을 포함한다.
일 예에서, 업데이트 요청은 지시 정보를 더 포함하고, 지시 정보는 CAPIF 코어 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하도록 명령하는 데 사용된다.
단계 302: CAPIF 코어 기능 엔티티는 새로운 보안 방법을 저장한다.
일 예에서, CAPIF 코어 기능 엔티티는 호출자, 새로운 보안 방법 및 API 공개 기능 엔티티 간의 대응관계를 저장한다.
단계 303: 호출자는 API 공개 기능 엔티티의 새로운 보안 방법을 획득한다.
제1 예에서, 단계 303은 단계 303a일 수 있다. 호출자는 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신한다.
가능한 구현에서, 단계 303a를 수행하기 전에, 호출자는 API 공개 기능 엔티티에 보안 방법 협상 요청을 추가로 전송할 수 있으며, 여기서 보안 방법 협상 요청은 호출자에 의해 지원되는 보안 방법의 목록과 목록을 포함한다. 보안 방법에는 새로운 보안 방법이 포함된다. 이에 대응하여, 단계 303a는 다음을 포함할 수 있다: 호출자는 API 공개 기능 엔티티로부터 보안 방법 협상 응답을 수신하고, 여기서 보안 방법 협상 응답은 새로운 보안 방법을 포함한다.
다른 가능한 구현에서, 단계 303a를 수행하기 전에, 호출자는 원래의 보안 방법을 사용하여 API 공개 기능 엔티티에 제3 호출 요청을 더 전송할 수 있으며, 여기서 제3 호출 요청은 서비스 API를 호출하는 데 사용된다. 이에 대응하여, 단계 303a는 다음을 포함할 수 있다: 호출자는 API 공개 기능 엔티티로부터 제3 호출 요청의 응답 메시지를 수신하고, 여기서 제3 호출 요청의 응답 메시지는 새로운 보안 방법 및 원인 값을 포함하고, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
제2 예에서, 단계 303은 단계 303b 일 수 있다. 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 수신한다.
가능한 구현에서, CAPIF 코어 기능 엔티티는 업데이트 요청의 지시 정보에 기초하여 호출자에게 새로운 보안 방법을 전송할 수 있다.
다른 가능한 구현에서, 단계 303b를 수행하기 전에, 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 추가로 요청할 수 있다. 예를 들어, 호출자는 획득 요청을 CAPIF 코어 기능 엔티티에 전송할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
이 단계에서 제1 예의 앞의 가능한 구현 및 제2 예의 두 가지 구현에서, 호출자는 API 공개 기능 엔티티의 새로운 보안 방법을 획득하기 전에 원래의 보안 방법을 사용하여 API 공개 기능 엔티티에 제2 호출 요청을 추가로 전송할 수 있으며, 제2 호출 요청은 서비스 API를 호출하는 데 사용된다. 호출자는 API 공개 기능 엔티티로부터 제2 호출 요청의 응답 메시지를 더 수신할 수 있으며, 여기서 제2 호출 요청의 응답 메시지에는 원인 값이 포함되고 원인 값은 보안 방법의 불일치로 인한 서비스 API 호출 실패를 나타내는 데 사용된다.
단계 304: 호출자는 새로운 보안 방법을 사용하여 API 공개 기능 엔티티에 제1 호출 요청을 전송한다.
제1 호출 요청은 서비스 API의 이름과 서비스 API를 호출하는 데 사용되는 제1 호출 요청을 포함한다.
선택적으로, 도 3a에 도시된 방법은 다음 단계를 더 포함할 수 있다.
단계 305: API 공개 기능 엔티티는 호출자에게 제1 호출 요청의 응답 메시지를 전송한다.
제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출되었음을 나타내는 데 사용된다.
도 3a에 도시된 바와 같이 API 공개 기능 엔티티의 보안 방법이 업데이트되면 호출자는 API 공개 기능 엔티티의 새로운 보안 방법을 적시에 획득하고 새로운 보안 방법을 사용하여 API 공개 기능 엔티티로부터 서비스 API를 호출함으로써 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 방지한다.
서비스 API의 보안 방법이 업데이트되면, 본 출원의 실시예는 또 다른 서비스 API 호출 방법과이 방법에 기반한 호출자, CAPIF 코어 기능 엔티티 및 API 공개 기능 엔티티를 제공한다. 다음은 도 3b를 참조하여 서비스 API 호출 방법을 설명한다.
도 3b는 본 출원의 실시예에 따른 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 3b에 도시된 방법을 구현하기 위한 전제 조건은 서비스 API의 보안 방식을 기존 보안 방식에서 새로운 보안 방식으로 업데이트하는 것이다. 도 3b에 도시된 방법은 다음 단계를 포함한다.
단계 311: CAPIF 코어 기능 엔티티는 API 게시 기능 엔티티로부터 API 공개 기능에 대한 업데이트 요청을 수신하며, 여기서 업데이트 요청은 서비스 API의 새로운 보안 방법을 포함한다.
일 예에서, 업데이트 요청은 지시 정보를 더 포함하고, 지시 정보는 CAPIF 코어 기능 엔티티가 새로운 보안 방법을 호출자에게 전송하도록 명령하는 데 사용된다.
단계 312: CAPIF 코어 기능 엔티티는 새로운 보안 방법을 저장한다.
일 예에서, CAPIF 코어 기능 엔티티는 호출자, 새로운 보안 방법 및 서비스 API 간의 대응관계를 저장한다. 특정 예에서 CAPIF 코어 기능 엔티티는 호출자, 새로운 보안 방법, 서비스 API 및 API 공개 기능 엔티티 간의 대응관계를 저장한다.
단계 313: 호출자는 서비스 API의 새로운 보안 방법을 획득한다.
제1 예에서, 단계 313은 단계 313a일 수 있다. 호출자는 API 공개 기능 엔티티로부터 새로운 보안 방법을 수신한다.
가능한 구현에서, 단계 313a를 수행하기 전에, 호출자는 API 공개 기능 엔티티에 보안 방법 협상 요청을 추가로 전송할 수 있으며, 여기서 보안 방법 협상 요청은 호출자에 의해 지원되는 보안 방법의 목록을 포함하며, 보안 방법의 목록에는 새로운 보안 방법이 포함된다. 이에 대응하여, 단계 313a는 다음을 포함할 수 있다: 호출자는 API 공개 기능 엔티티로부터 보안 방법 협상 응답을 수신하고, 여기서 보안 방법 협상 응답은 새로운 보안 방법을 포함한다.
다른 가능한 구현에서, 단계 313a를 수행하기 전에, 호출자는 원래의 보안 방법을 사용하여 API 공개 기능 엔티티에 제3 호출 요청을 더 전송할 수 있으며, 여기서 제3 호출 요청은 서비스 API를 호출하는 데 사용된다. 이에 대응하여, 단계 313a는 다음을 포함할 수 있다: 호출자는 API 공개 기능 엔티티로부터 제3 호출 요청의 응답 메시지를 수신하고, 여기서 제3 호출 요청의 응답 메시지는 새로운 보안 방법 및 원인 값을 포함하고, 원인 값은 보안 방법의 불일치로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
제2 예에서, 단계 313은 단계 313b 일 수 있다. 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 수신한다.
가능한 구현에서, CAPIF 코어 기능 엔티티는 업데이트 요청의 지시 정보에 기초하여 호출자에게 새로운 보안 방법을 전송할 수 있다.
다른 가능한 구현에서, 단계 313b를 수행하기 전에, 호출자는 CAPIF 코어 기능 엔티티로부터 새로운 보안 방법을 추가로 요청할 수 있다. 예를 들어, 호출자는 획득 요청을 CAPIF 코어 기능 엔티티에 전송할 수 있으며, 여기서 획득 요청은 새로운 보안 방법을 요청하는 데 사용된다.
이 단계에서 제1 예의 앞의 가능한 구현 및 제2 예의 두 가지 구현에서, 호출자는 서비스 API의 새로운 보안 방법을 획득하기 전에 원래의 보안 방법을 사용하여 제2 호출 요청을 API 공개 기능 엔티티에 추가로 전송할 수 있고, 제2 호출 요청은 서비스 API를 호출하는 데 사용된다. 호출자는 API 공개 기능 엔티티로부터 제2 호출 요청의 응답 메시지를 더 수신할 수 있으며, 여기서 제2 호출 요청의 응답 메시지에는 원인 값이 포함되고, 원인 값은 보안 방법이 불일치로 인한 서비스 API 호출 실패를 나타내는 데 사용된다.
단계 314: 호출자는 새로운 보안 방법을 사용하여 API 공개 기능 엔티티에 제1 호출 요청을 전송한다.
제1 호출 요청은 서비스 API의 이름과 서비스 API를 호출하는 데 사용되는 제1 호출 요청을 포함한다.
선택적으로, 도 3b에 도시된 방법은 다음 단계를 더 포함할 수 있다.
단계 315: API 공개 기능 엔티티는 호출자에게 제1 호출 요청의 응답 메시지를 전송한다.
제1 호출 요청의 응답 메시지는 서비스 API가 성공적으로 호출되었음을 나타내는 데 사용된다.
도 3b에 도시된 바와 같이, 서비스 API의 보안 방법이 업데이트되면 호출자는 서비스 API의 새로운 보안 방법을 적시에 획득하고 새로운 보안 방법을 사용하여 API 공개 기능 엔티티로부터 서비스 API를 호출함으로써 보안 방법의 불일치로 인해 서비스 API가 호출되지 않는 문제를 회피한다.
도 3a 및 도 3b에 도시된 방법은 개별적으로 수행될 수 있거나 조합으로 수행될 수 있다. 예를 들어, API 공개 기능 엔티티의 보안 방법이 업데이트되면, 도 3a에 도시된 방법이 수행될 수 있다. 서비스 API의 보안 방법이 업데이트되면 도 3b에 도시된 방법이 수행될 수 있다. API 공개 기능 엔티티와 서비스 API 모두의 보안 방식이 업데이트되면 도 3a 및 도 3b가 조합하여 수행될 수 있다. 예를 들어, 단계 301은 단계 311과 조합하여 수행될 수 있고, 단계 302는 단계 312와 조합하여 수행될 수 있으며, 단계 303은 단계 313과 조합하여 수행될 수 있고, 단계 304는 단계 314와 조합하여 수행될 수 있고, 단계 305는 단계 315와 조합하여 수행될 수 있다. 도 3a 및 도 3b에 도시된 방법이 조합하여 수행될 때, 다른 구현이 있을 수 있으며, 이것은 본 출원의 이 실시예에 제한되지 않는다.
다음은 도 4 내지 도 7을 참조하여 본 출원의 실시예의 솔루션을 추가로 설명한다. 도 4 내지 7에 도시된 방법에서, 도 3에 도시된 방법과 동일하거나 유사한 내용에 대해서는 도 3a 및 도 3b에 도시된 상세한 설명을 참조한다. 자세한 내용은 이후에 설명하지 않는다. 도 4 내지 도 7에 도시된 방법은 서비스 API의 보안 방법을 업데이트하는 예를 사용하여 설명한다. 실제 작동에서, 도 4 내지 도 7에 도시된 방법은 API 공개 기능 엔티티의 보안 방법이 업데이트된 경우에도 적용될 수 있다. 이 경우, 도 4 내지 도 7에 도시된 방법 중 서비스 API의 보안 방법은 API 공개 기능 엔티티의 보안 방법으로 대체된다. 또한, 전술한 바에서 "원래의 보안 방법"은 "업데이트 전의 보안 방법"으로도 설명될 수 있으며, 이 둘은 상호 사용될 수 있다. "새로운 보안 방법"은 "업데이트된 보안 방법"이라고도 할 수 있으며, 이 둘은 상호 사용될 수 있다.
도 4는 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 4에 도시된 방법의 주요 아이디어는 다음과 같다: 서비스 API의 보안 방법이 업데이트된 후 API 호출자가 서비스 API를 호출하지 못하면 API 호출자는 CAPIF 코어 기능에 서비스 API의 업데이트된 보안 방법을 요청하고, 그런 다음 업데이트된 보안 방법을 사용하여 AEF로부터 서비스 API를 호출한다. 도 4에 도시된 방법은 단계 401 내지 단계 406을 포함할 수 있다.
도 4에 도시된 방법이 수행되기 전에, CAPIF 코어 기능은 API 호출자의 식별자, 업데이트 전의 보안 방법, 서비스 API의 식별자 간의 대응관계를 저장한다는 것에 유의해야 한다.
단계 401: 서비스 API의 보안 방법을 업데이트한다.
설명을 위해 서비스 API 1의 보안 방법이 업데이트되는 예를 사용한다. 구체적으로, 서비스 API 1의 보안 방법이 업데이트된 후, 서비스 API 1은 CAPIF 코어 기능에 서비스 API 1의 업데이트된 보안 방법을 알린다. 서비스 API 1은 서비스 API 1의 업데이트된 보안 방법을 API 게시 기능을 사용하여 CAPIF 코어 기능에 전송할 수 있다. 이에 상응해서, CAPIF 코어 기능은 서비스 API 1의 업데이트된 보안 방법을 수신한 후 업데이트된 보안 방법을 저장한다.
서비스 API 1의 업데이트된 보안 방법을 저장할 때, CAPIF 코어 기능은 API 호출자의 식별자, 서비스 API 1의 업데이트된 보안 방법 및 서비스 API 1의 이름 간의 대응관계를 저장할 수 있다. 예를 들어, CAPIF 코어 기능은 API 호출자의 식별자, 서비스 API 1 업데이트 전의 보안 방법, 및 서비스 API 이름 간의 미리 저장된 대응관계에서 서비스 API 1 업데이트 전의 보안 방법을 서비스 API 1의 업데이트된 보안 방법으로 대체할 수 있다.
예를 들어, API 게시 기능은 서비스 API 게시 요청을 CAPIF 코어 기능에 전송할 수 있으며, 여기서 요청은 서비스 API 1의 이름 및 업데이트된 보안 방법을 전달한다. 요청을 수신한 후, CAPIF 코어 기능은 서비스 API 1의 이름에 대응하는 로컬에 저장된 보안 방법을 수신된 업데이트된 보안 방법으로 대체한다. 또한, 업데이트된 보안 방법을 성공적으로 저장한 후, CAPIF 코어 기능은 API 게시 기능에 서비스 API 게시 응답을 더 전송할 수 있다.
단계 402: API 호출자는 서비스 API 호출 요청을 AEF에 전송한다.
여기서 API 호출자는 서비스 API 1의 업데이트 이전에 보안 방법을 사용하여 AEF와 통신한다. 예를 들어, API 호출자는 서비스 API를 업데이트하기 전에 보안 방법을 사용하여 AEF로 인증, 권한 부여 및 보호를 수행할 수 있다.
구체적으로, 서비스 API 호출 요청은 업데이트 전의 보안 방법에 해당하는 요청 메시지를 사용하며, 요청 메시지에는 API 호출자의 식별자가 포함될 수 있다. 또한, 요청 메시지에는 서비스 API 1의 이름이 더 포함될 수 있다.
예를 들어, 업데이트 전의 보안 방법은 TLS-PSK이다. 이 방법을 사용하면 API 호출자가 서비스 API로 전송한 호출 요청은 클라이언트 헬로 메시지(client Hello message)이고 클라이언트 헬로 메시지는 미리 공유된 키를 전달한다. API 호출자는 인증을 수행하고 사전 공유 키를 사용하여 AEF에 대한 보안 연결을 설정하여 서비스 API 1을 호출한다.
단계 403: AEF는 서비스 API 호출 실패 응답을 API 호출자에 전송한다.
서비스 API 호출 실패 응답은 원인 값을 전달하고, 원인 값은 보안 방법 오류로 인해 서비스 API 1이 호출되지 않았음을 나타내는 데 사용된다.
또한, 서비스 API 호출 실패 응답은 지시 정보를 더 전달할 수 있으며, 여기서 지시 정보는 API 호출자에게 CAPIF 코어 기능으로부터 서비스 API 1의 업데이트된 보안 방법을 획득하도록 명령하는 데 사용된다.
단계 404: API 호출자는 보안 방법 획득 요청을 CAPIF 코어 기능에 전송한다.
보안 방법 획득 요청은 API 호출자의 식별자를 전달한다. 선택적으로, 보안 방법 획득 요청은 서비스 API 1의 이름을 더 포함할 수 있다.
단계 405: CAPIF 코어 기능은 API 호출자에게 보안 방법 획득 응답을 전송한다.
보안 방법 획득 응답은 업데이트된 보안 방법을 전달한다.
일 예에서, CAPIF 코어 기능은 API 호출자에 기초하여 API 호출자에 대응하는 모든 서비스 API의 보안 방법을 검색하고 보안 방법을 API 호출자에게 전송할 수 있다. 구체적으로, CAPIF 코어 기능은 하나 이상의 서비스 API 이름과 해당 보안 방법 그룹을 API 호출자에게 전송한다. 예를 들어, 해당 그룹은 (서비스 API 1, 보안 방법 1), (서비스 API 2, 보안 방법 2) 등으로 표현될 수 있다.
이에 대응하여 API 호출자가 보안 방법 획득 응답을 수신한 후, API 호출자는 보안 방법 획득 응답에 따라 서비스 API 1의 업데이트된 보안 방법이 보안 방법 1임을 알 수 있다.
다른 예에서, CAPIF 코어 기능은 API 호출자의 식별자와 서비스 API 1의 이름에 기초해서 API 호출자의 식별자와 서비스 API 1의 이름에 고유하게 대응하는 보안 방법을 검색할 수 있고, 보안 방법 획득 응답에 보안 방법을 추가하고, API 호출자에게 보안 방법 획득 응답을 전송한다.
단계 406: API 호출자는 서비스 API 호출 요청을 AEF에 전송한다.
여기서 API 호출자는 서비스 API 1의 업데이트된 보안 방법을 사용하여 AEF와 통신한다.
구체적으로, API 호출자는 서비스 API 1의 업데이트된 보안 방법을 사용하여 AEF로 인증, 권한 부여 및 보호를 수행한다. 예를 들어, 서비스 API 호출 요청은 서비스 API 1의 업데이트된 보안 방법에 대응 인증 정보 및 API 호출자의 식별자를 전달하한다. 또한, 호출 요청은 서비스 API 1의 이름을 더 포함할 수 있다.
예를 들어, 서비스 API 1의 업데이트된 보안 방법은 전송 레이어 보안 사전 공유 키 암호 스위트(transport layer security pre-shared key ciphersuites, TLS-PKI) 보안 방법이고, 서비스 API 1의 업데이트된 보안 방법에 대응하는 인증 정보는 클라이언트 헬로 메시지에 전달되어야 하는 인증서이며, API 호출자는 인증서를 전달하는 클라이언트 헬로 메시지를 AEF로 전송하여 서비스 API 1을 호출한다.
단계 407: AEF는 API 호출자에게 서비스 API 호출 성공 응답을 전송한다.
일 예에서, AEF는 CAPIF 코어 기능으로부터 서비스 API 1의 업데이트된 보안 방법을 획득하고, 업데이트된 보안 방법에 기초하여 API 호출자에 의해 전송된 호출 요청에 대한 인증 및 권한 검증을 수행할 수 있다. 입증이 성공되면 AEF는 API 호출자에게 서비스 API 호출 성공 응답을 전송한다.
예를 들어, 업데이트된 보안 방법에 해당하는 인증 정보는 클라이언트 헬로 메시지에서 전달해야 하는 인증서이다. AEF가 인증서에 해당하는 TLS-PKI 보안 방법을 기반으로 API 호출자에 대한 인증 및 권한 부여 입증을 성공적으로 수행하면 서비스 API가 성공적으로 호출되고 AEF는 서비스 API 호출 성공 응답을 API 호출자에게 전송한다.
다른 예에서, 서비스 API 1의 업데이트된 보안 방법은 AEF와 API 호출자 간의 인증, 권한 부여 및 보호를 위해 사용된다. 인증 및 권한 부여가 성공하면 AEF는 API 호출자에게 성공 응답을 전송한다.
이 실시예의 다른 가능한 구현에서, 단계 404에서의 보안 방법 획득 요청은 보안 방법 발견 요청으로 대체될 수 있고, 단계 405에서의 보안 방법 획득 응답은 보안 방법 발견 응답으로 대체될 수 있다. 전술한 보안 방법 획득 요청 및 보안 방법 획득 응답은 새로 정의된 메시지로 대체될 수 있음을 이해할 수 있다. 본 출원의 이 실시예에서 메시지 이름은 제한되지 않는다. 대안으로, 전술한 단계 404 및 단계 405는 API 호출자와 CAPIF 코어 기능 간의 보안 협상 프로세스로 대체될 수 있다.
구체적으로, 보안 협상 과정에서 API 호출자는 API 호출자에 의해 지원되는 모든 보안 방법을 CAPIF 코어 기능으로 전송하고, CAPIF 코어 기능은 수신된 보안 방법과 API 공개 기능이 지원하는 보안 방법을 비교하며, 정책에 따라 보안 방법을 선택하고, API 호출자와 API 공개 기능 엔티티 간에 사용하기 위해 보안 방법을 API 호출자에게 전송한다.
도 5는 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 5에 도시된 방법의 주요 아이디어는 다음과 같다: 서비스 API의 보안 방법이 업데이트된 후, API 게시 기능은 CAPIF 코어 기능에 서비스 API의 업데이트된 보안 방법을 API 호출자에게 능동적으로 전송하도록 명령하고, 그런 다음 API 호출자는 업데이트된 보안 방법을 사용하여 AEF에서 서비스 API를 호출한다. 도 5에 도시된 방법은 단계 501 내지 단계 507을 포함할 수 있다.
단계 501: API 게시 기능은 서비스 API 업데이트 요청을 CAPIF 코어 기능에 전송한다.
요청은 서비스 API의 이름, 업데이트된 보안 방법 및 지시 정보를 전달한다. 지시 정보는 서비스 API의 업데이트된 보안 방법을 API 호출자에게 전송하도록 CAPIF 코어 기능에 명령하는 데 사용된다.
단계 502: CAPIF 코어 기능이 서비스 API에 대한 정보를 업데이트한다.
구체적으로, CAPIF 코어 기능은 CAPIF 코어 기능에 저장된 서비스 API에 대한 정보의 보안 방법을 업데이트된 보안 방법으로 대체한다.
예를 들어, CAPIF 코어 기능은 원래 API 호출자의 식별자, 서비스 API 업데이트 전의 보안 방법, 서비스 API 이름 간의 대응관계를 저장한다. 여기서 CAPIF 코어 기능은 서비스 API의 업데이트된 보안 방법에 대응하여 서비스 API 업데이트 전의 보안 방법을 대체한다.
단계 503: CAPIF 코어 기능이 서비스 API 업데이트 응답을 API 게시 기능에 전송한다.
단계 504: CAPIF 코어 기능은 서비스 API에 대한 업데이트된 정보를 API 호출자에게 전송한다.
업데이트된 서비스 API 정보는 서비스 API의 이름 및 업데이트된 서비스 API의 보안 방법을 포함한다.
단계 505: API 호출자는 보안 방법 업데이트 확인을 CAPIF 코어 기능에 전송한다.
단계 506 및 단계 507은 각각 도 4의 단계 406 및 단계 407과 동일하거나 유사하다. 자세한 사항은 도 4의 상세 설명을 참조한다. 자세한 내용은 여기서 다시 설명하지 않는다.
도 6은 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 6에 도시된 방법의 주요 아이디어는 다음과 같다: 서비스 API의 보안 방법이 업데이트된 후, API 호출자가 서비스 API를 호출하지 못하면 AEF가 업데이트된 보안 방법을 API 호출자에게 전송하고, 그런 다음 API 호출자는 업데이트된 보안 방법을 사용하여 AEF에서 서비스 API를 호출한다. 도 6에 도시된 방법은 단계 601 내지 단계 605를 포함할 수 있다.
단계 601 및 단계 602는 각각 도 4의 단계 401 및 단계 402와 동일하다. 자세한 사항은 도 4의 상세 설명을 참조한다. 자세한 내용은 여기서 다시 설명하지 않는다.
단계 603: AEF는 API 호출자에게 서비스 API 호출 실패 응답을 전송한다.
응답은 원인 값 및 업데이트된 보안 방법을 전달한다. 이 원인 값은 보안 방법 오류로 인해 서비스 API 호출되지 않았음을 나타내는 데 사용된다.
단계 604 및 단계 605는 각각 도 5의 단계 406 및 단계 407과 동일하다. 자세한 사항은 도 4의 상세 설명을 참조한다. 자세한 내용은 여기서 다시 설명하지 않는다.
도 7은 본 출원의 실시예에 따른 또 다른 서비스 API 호출 방법의 개략적인 통신 다이어그램이다. 도 7에 도시된 방법의 주요 아이디어는 다음과 같다: 서비스 API의 보안 방법이 업데이트된 후, API 호출자가 서비스 API를 호출하지 못하면 API 호출자가 AEF와 보안 방법을 협상하고, 그런 다음 API 호출자는 협상된 보안 방법을 사용하여 AEF에서 서비스 API를 호출한다. 도 7에 도시된 방법은 단계 701 내지 단계 706을 포함할 수 있다.
단계 701 내지 단계 703은 각각 도 4의 단계 401 내지 단계 403과 동일하거나 유사하다. 자세한 사항은 도 4의 상세 설명을 참조한다. 자세한 내용은 여기서 다시 설명하지 않는다.
단계 704: API 호출자는 AEF에 보안 방법 협상 요청을 전송한다.
요청은 예를 들어 보안 방법 A, 보안 방법 B 및 보안 방법 C를 포함하여 API 호출자에 의해 지원되는 보안 방법을 전달한다.
본 출원의 이 실시예에서, 서비스 API에 의해 사용될 수 있는 보안 방법은 보안 방법 A, 보안 방법 B 및 보안 방법 C만을 포함한다고 가정한다.
단계 705: AEF는 API 호출자에게 보안 방법 협상 응답을 전송한다.
응답은 보안 방법 C를 전달한다. 구체적으로, 보안 방법 협상 요청을 수신한 후, AEF는 서비스 API의 업데이트된 보안 방법이 보안 방법 C라고 판단하고 보안 방법 C를 보안 방법 협상 응답에 추가하며, API 호출자에게 보안 방법 협상 응답을 전송한다.
단계 706: API 호출자는 서비스 API 호출 요청을 AEF에 전송한다.
여기서, API 호출자는 서비스 API의 업데이트된 보안 방법(즉, 보안 방법 C)을 사용하여 AEF와 통신한다.
단계 707: AEF는 API 호출자에게 서비스 API 호출 성공 응답을 전송한다.
단계 706 및 단계 707의 특정 구현 프로세스는 도 4의 단계 406 및 단계 407의 것들과 유사하다. 자세한 사항은 도 4의 상세 설명을 참조한다. 자세한 내용은 여기서 다시 설명하지 않는다.
본 출원의 실시예에서 제공되는 솔루션은 주로 서로 다른 네트워크 요소 간의 상호 작용의 관점에서 설명되었다. 전술한 기능을 구현하기 위해, 호출자, API 공개 기능 엔티티 및 CAPIF 코어 기능 엔티티는 각각의 기능에 대응하는 하드웨어 구조 및/또는 소프트웨어 모듈을 포함함을 이해할 수 있다. 본 출원에 개시된 실시예에서 설명된 유닛 및 알고리즘 단계를 참조하면, 본 출원의 실시예는 하드웨어의 형태 또는 하드웨어와 컴퓨터 소프트웨어의 조합으로 구현될 수 있다. 기능이 하드웨어에 의해 수행되는지 또는 컴퓨터 소프트웨어에 의해 구동되는 하드웨어에 의해 수행되는지는 기술적 솔루션의 특정 응용 프로그램 및 설계 제약에 따라 다르다. 당업자는 각각의 특정 애플리케이션에 대해 설명된 기능을 구현하기 위해 상이한 방법을 사용할 수 있지만, 구현이 본 출원의 실시예에서 기술적 솔루션의 범위를 벗어나는 것으로 간주되어서는 안 된다.
본 출원의 실시예에서, 호출자, API 공개 기능 엔티티 및 CAPIF 코어 기능 엔티티의 기능 유닛은 전술한 방법 예에 따라 분할될 수 있다. 예를 들어, 각각의 기능 유닛은 각각의 기능에 대응하여 분할되거나 둘 이상의 기능이 하나의 프로세싱 유닛에 통합될 수 있다. 통합 유닛은 하드웨어의 형태로 구현될 수 있거나 소프트웨어 기능 유닛의 형태로 구현될 수 있다. 본 출원의 이 실시예에서, 유닛 분할은 하나의 예이며 단지 논리 기능 분할이라는 점에 유의해야 한다. 실제 구현 중에 다른 분할 방식이 사용될 수 있다.
통합 유닛을 사용하는 경우, 도 8은 본 출원의 실시예에 따른 장치의 가능한 예시적인 블록도이다. 장치(800)는 소프트웨어, 하드웨어 또는 소프트웨어와 하드웨어의 조합의 형태로 존재할 수 있다. 도 8은 본 출원의 실시예에 따른 장치의 가능한 개략적 블록도이다. 장치(800)는 프로세싱 유닛(802) 및 통신 유닛(803)을 포함한다. 프로세싱 유닛(802)은 장치의 동작을 제어하고 관리하도록 구성된다. 통신 유닛(803)은 장치와 다른 장치 사이의 통신을 지원하도록 구성된다. 장치는 장치의 프로그램 코드 및 데이터를 저장하도록 구성된 저장 유닛(801)을 더 포함할 수 있다.
도 8에 도시된 장치(800)는 본 출원의 실시예에서 호출자, API 공개 기능 엔티티 또는 CAPIF 코어 기능 엔티티일 수 있다.
도 8에 도시된 장치(800)가 호출자일 때, 프로세싱 유닛(802)은 전술한 방법 예에서 호출자에 의해 완료된 동작을 수행하는 장치(800)를 지원할 수 있다. 통신 ㅇ유닛(803)은 장치(800)와 CAPIF 코어 기능 엔티티 간의 통신, 장치(800)와 API 공개 기능 엔티티 간의 통신 등을 지원할 수 있다. 예를 들어, 통신 유닛(803)은 도 3a에서의 단계 303 내지 단계 305, 도 4에서의 단계 402 내지 단계 407, 도 5에서의 단계 504 내지 단계 507. 도 6에서의 단계 602 내지 단계 605. 도 7에서의 단계 702 내지 단계 707, 및/또는 다른 관련 커뮤니케이션 프로세스를 수행할 때 장치(800)를 지원한다.
도 8에 도시된 장치(800)가 API 공개 기능 엔티티일 때, 프로세싱 유닛(802)은 전술한 방법 예에서 API 공개 기능 엔티티에 의해 완료된 동작을 수행하는 장치(800)를 지원할 수 있다. 예를 들어, 프로세싱 유닛(802)은 도 4에서의 단계 401, 도 6에서의 단계 601, 도 7에서의 단계 701, 및/또는 본 명세서에 서술된 기술의 다른 프로세스를 수행할 때 장치(800)를 지원한다. 통신 유닛(803)은 장치(800)와 호출자 간의 통신, 장치(800)와 CAPIF 코어 기능 엔티티 간의 통신 등을 지원할 수 있다. 예를 들어, 통신 유닛(803)은 도 3a에서의 단계 303a, 단계 304 및 단계 305, 도 도 3b에서의 단계 313a, 단계 314 및 단계 315 도 4에서의 단계 402, 단계 403, 단계 406 및 단계 407, 도 5에서의 단계 506 및 단계 507, 도 6에서의 단계 602 내지 단계 605, 도 7에서의 단계 702 내지 단계 707, 및/또는 다른 관련 커뮤니케이션 프로세스를 수행할 때 장치(800)를 지원한다.
도 8에 도시된 장치(800)가 CAPIF 코어 기능 엔티티일 때, 프로세싱 유닛(802)은 전술한 방법 예에서 CAPIF 코어 기능 엔티티에 의해 완료된 동작을 수행하는 장치(800)를 지원할 수 있다. 예를 들어, 프로세싱 유닛(802)은 도 3a에서의 단계 302, 도 3b에서의 단계 312, 도 4에서의 단계 401, 도 5에서의 단계 502, 도 6에서의 단계 601, 도 7에서의 단계 701, 및/또는 본 명세서에 기술된 기술의 다른 프로세스를 수행할 때 장치(800)를 지원한다. 통신 유닛(803)은 장치(800)와 호출자, API 공개 기능 엔티티, API 게시 기능 엔티티 등 사이의 통신을 지원할 수 있다. 예를 들어, 통신 유닛(803)은 도 3a에서의 단계 301 및 단계 303b, 도 3b에서의 단계 311 및 단계 313b, 도 4에서의 단계 404 및 단계 405, 도 5에서의 단계 501 및 단계 503 내지 단계 505, 및/또는 다른 관련 커뮤니케이션 프로세스를 수행할 때 장치(800)를 지원한다.
예를 들어, 처리 장치(802)는 프로세서 또는 제어기일 수 있으며, 예를 들어 중앙 처리 장치(Central Processing Unit, CPU), 범용 프로세서, 디지털 신호 프로세서(Digital Signal Processor, DSP), 애플리케이션 특정 집적 회로(Application-Specific Integrated Circuit, ASIC), 필드 프로그래머블 게이트 어레이(Field Programmable Gate Array, FPGA) 또는 다른 프로그래밍 가능 논리 장치, 트랜지스터 논리 장치, 하드웨어 구성 요소 또는 이들의 조합일 수 있다. 프로세서는 본 출원에 개시된 내용을 참조하여 설명된 다양한 예시적인 논리 블록, 유닛 및 회로를 구현하거나 실행할 수 있다. 대안으로, 프로세서는 컴퓨팅 기능을 구현하기 위한 조합, 예를 들어 하나 이상의 마이크로프로세서의 조합, 또는 DSP와 마이크로 프로세서의 조합일 수 있다. 통신 유닛(803)은 통신 인터페이스일 수 있고, 통신 인터페이스는 일반적인 용어이다. 특정 구현 동안, 통신 인터페이스는 하나 이상의 인터페이스를 포함할 수 있다. 저장 유닛(801)은 메모리일 수 있다.
프로세싱 유닛(802)이 프로세서이고, 통신 유닛(803)이 통신 인터페이스이고, 저장 유닛(801)이 메모리인 경우, 본 출원의 이 실시예에서의 장치는 도 9에 도시된 장치(900)일 수 있다.
도 9를 참조하면, 장치(900)는 프로세서(902) 및 통신 인터페이스(903)를 포함한다. 또한, 장치(900)는 메모리(901)를 더 포함할 수 있다. 선택적으로, 장치(900)는 버스(904)를 더 포함할 수 있다. 통신 인터페이스(903), 프로세서(902) 및 메모리(901)는 버스(904)를 사용하여 서로 연결될 수 있다. 버스(904)는 주변 부품 상호 연결(Peripheral Component Interconnect, PCI로 약칭) 버스, 확장된 산업 표준 아키텍처(Extended Industry Standard Architecture, EISA로 약칭) 버스 등이 될 수 있다. 버스(904)는 어드레스 버스, 데이터 버스, 제어 버스 등으로 분류될 수 있다. 표현의 용이성을 위해, 도 9에서 버스를 표현하기 위해 단지 하나의 굵은 선이 사용되지만 이것은 버스가 하나만 있거나 버스 유형이 하나만 있음을 의미하지는 않는다.
프로세서(902)는 메모리(901)에 저장된 프로그램을 실행하거나 수행함으로써 장치(900)의 다양한 기능을 수행할 수 있다.
예를 들어, 도 9에 도시된 장치(900)는 본 출원의 실시예에서 호출자, CAPIF 코어 기능 엔티티 또는 API 공개 기능 엔티티일 수 있다.
장치(900)가 호출자인 경우, 프로세서(902)는 메모리(901)에 저장된 프로그램을 실행하거나 수행함으로써 전술한 방법 예에서 호출자에 의해 완료된 동작을 수행할 수 있다. 장치(900)가 CAPIF 코어 기능 엔티티인 경우, 프로세서(902)는 메모리(901)에 저장된 프로그램을 실행하거나 수행함으로써 전술한 방법 예에서 CAPIF 코어 기능 엔티티에 의해 완료된 동작을 수행할 수 있다.
장치(900)가 API 공개 기능 엔티티인 경우, 프로세서(902)는 메모리(901)에 저장된 프로그램을 실행 또는 수행하여 전술한 방법 예에서 API 공개 기능 엔티티의 동작을 수행할 수 있다.
본 출원의 실시예에 개시된 내용과 결합하여 설명된 방법 또는 알고리즘 단계는 하드웨어에 의해 구현될 수 있거나, 소프트웨어 명령을 실행하여 프로세서에 의해 구현될 수 있다. 소프트웨어 명령은 해당 소프트웨어 모듈을 포함할 수 있다. 소프트웨어 모듈은 랜덤 액세스 메모리(Random Access Memory, RAM), 플래시 메모리, 읽기 전용 메모리(Read Only Memory, ROM), 소거 가능한 프로그래머블 읽기 전용 메모리(Erasable Programmable ROM, EPROM), 전기적으로 소거 가능한 프로그래머블 가능한 읽기 전용 메모리(Electrically EPROM, EEPROM), 레지스터, 하드 디스크, 이동식 하드 디스크, 컴팩트 디스크 읽기 전용 메모리(compact disc read-only memory, CD-ROM) 또는 당업계에 잘 알려진 다른 형태의 저장 매체에 저장될 수 있다.
예를 들어, 저장 매체는 프로세서에 연결되므로 프로세서는 저장 매체로부터 정보를 읽거나 저장 매체에 정보를 기록할 수 있다. 확실히, 저장 매체는 대안으로 프로세서의 구성 요소일 수 있다. 프로세서 및 저장 매체는 ASIC에 위치할 수 있다. 또한 ASIC는 호출자, CAPIF 코어 기능 엔티티 또는 API 공개 기능 엔티티에 위치할 수 있다. 확실히, 프로세서 및 저장 매체는 대안으로 호출자, CAPIF 코어 기능 엔티티 또는 API 공개 기능 엔티티에 개별 구성 요소로서 존재할 수 있다.
당업자는 전술한 하나 이상의 예들에서, 본 출원의 실시예들에서 설명된 기능들이 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합에 의해 구현될 수 있다는 것을 알아야 한다. 기능이 소프트웨어에 의해 구현될 때, 이들 기능은 컴퓨터 판독 가능 매체에 저장되거나 컴퓨터 판독 가능 매체에 하나 이상의 명령 또는 코드로서 전송될 수 있다. 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하며, 여기서 통신 매체는 컴퓨터 프로그램이 한 장소에서 다른 장소로 전송될 수 있게 하는 임의의 매체를 포함한다. 저장 매체는 범용 또는 전용 컴퓨터에 액세스할 수 있는 임의의 사용 가능한 매체일 수 있다.
전술한 특정 구현에서, 본 출원의 실시예의 목적, 기술적 솔루션 및 유익한 효과가 더 상세히 설명된다. 전술한 설명은 본 출원의 실시예의 특정 구현일 뿐이며, 본 출원의 실시예의 보호 범위를 제한하려는 의도가 아님을 이해해야 한다. 본 출원의 실시예의 기술적 솔루션에 기초하여 이루어진 모든 수정, 동등한 대체 또는 개선은 본 출원의 실시예의 보호 범위에 속한다.

Claims (49)

  1. 서비스 애플리케이션 프로그래밍 인터페이스(application programming interface, API) 호출 방법으로서,
    API 공개 기능 엔티티(exposing function entity)의 보안 방법은 원래의 보안 방법에서 새로운 보안 방법으로 업데이트되며, 상기 API 공개 기능 엔티티의 보안 방법은 상기 API 공개 기능 엔티티와 호출자(invoker) 사이의 통신에 사용되며,
    상기 API 호출 방법은:
    상기 호출자가 상기 원래의 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제2 호출 요청을 전송하는 단계(402) - 상기 제2 호출 요청은 서비스 API를 호출하는 데 사용됨 - ;
    상기 호출자가 상기 API 공개 기능 엔티티로부터 상기 제2 호출 요청의 응답 메시지를 수신하는 단계(403) - 상기 제2 호출 요청의 응답 메시지는 원인 값(cause value)을 포함하고, 상기 원인 값은 상기 서비스 API가 보안 방법의 불일치로 인해 호출되지 않았음을 나타내는 데 사용됨 - ;
    상기 호출자가 상기 원인 값에 따라서, 상기 API 공개 기능 엔티티의 상기 새로운 보안 방법을 획득하는 단계; 및
    상기 호출자가 상기 새로운 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제1 호출 요청을 전송하는 단계(406) - 상기 제1 호출 요청은 상기 서비스 API의 이름을 포함하고, 상기 제1 호출 요청은 상기 서비스 API를 호출하는 데 사용됨 -
    를 포함하고,
    상기 API 공개 기능 엔티티의 상기 새로운 보안 방법을 획득하는 단계는:
    상기 호출자가 공통 API 프레임워크(common API framework, CAPIF) 코어 기능 엔티티에 상기 새로운 보안 방법을 요청하는 단계(404); 및
    상기 호출자가 상기 새로운 보안 방법을 상기 CAPIF 코어 기능 엔티티로부터 수신하는 단계(405)
    를 포함하는, 서비스 API 호출 방법.
  2. 제1항에 있어서,
    상기 서비스 API 호출 방법은:
    상기 호출자가 상기 API 공개 기능 엔티티로부터 제1 호출 요청의 응답 메시지를 수신하는 단계(407)
    를 더 포함하고,
    상기 제1 호출 요청의 응답 메시지는 상기 서비스 API가 성공적으로 호출되었음을 나타내는 데 사용되는, 서비스 API 호출 방법.
  3. 서비스 애플리케이션 프로그래밍 인터페이스(application programming interface, API) 호출 방법으로서,
    API 공개 기능 엔티티(exposing function entity)의 보안 방법은 원래의 보안 방법에서 새로운 보안 방법으로 업데이트되며, 상기 API 공개 기능 엔티티의 보안 방법은 상기 API 공개 기능 엔티티와 호출자(invoker) 사이의 통신에 사용되며,
    상기 API 호출 방법은:
    공통 API 프레임워크(common API framework, CAPIF) 코어 기능 엔티티가 API 게시 기능 엔티티로부터 상기 API 공개 기능 엔티티에 대한 업데이트 요청을 수신하는 단계(401) - 상기 업데이트 요청은 상기 새로운 보안 방법을 포함함 - ;
    상기 CAPIF 코어 기능 엔티티가 상기 새로운 보안 방법을 저장하는 단계;
    상기 호출자가 상기 원래의 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제2 호출 요청을 전송하는 단계(402) - 상기 제2 호출 요청은 서비스 API를 호출하는 데 사용됨 - ;
    상기 호출자가 상기 API 공개 기능 엔티티로부터 상기 제2 호출 요청의 응답 메시지를 수신하는 단계(403) - 상기 제2 호출 요청의 응답 메시지는 원인 값(cause value)을 포함하고, 상기 원인 값은 상기 서비스 API가 보안 방법의 불일치로 인해 호출되지 않았음을 나타내는 데 사용됨 - ;
    상기 호출자가 상기 원인 값에 따라서, 상기 CAPIF 코어 기능 엔티티에 상기 새로운 보안 방법을 요청하는 단계(404);
    상기 호출자가 상기 새로운 보안 방법을 상기 CAPIF 코어 기능 엔티티로부터 수신하는 단계(405); 및
    상기 호출자가 상기 새로운 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제1 호출 요청을 전송하는 단계(406) - 상기 제1 호출 요청은 상기 서비스 API의 이름을 포함하고, 상기 제1 호출 요청은 상기 서비스 API를 호출하는 데 사용됨 -
    를 포함하는 서비스 API 호출 방법.
  4. 제3항에 있어서,
    상기 CAPIF 코어 기능 엔티티가 상기 새로운 보안 방법을 저장하는 단계는:
    상기 CAPIF 코어 기능 엔티티가 상기 호출자, 상기 새로운 보안 방법 및 상기 API 공개 기능 엔티티 간의 대응관계를 저장하는 단계
    를 포함하는 서비스 API 호출 방법.
  5. 호출자(invoker)로서,
    프로세싱 유닛 및 통신 유닛을 포함하며,
    API 공개 기능 엔티티(exposing function entity)의 보안 방법은 원래의 보안 방법에서 새로운 보안 방법으로 업데이트되며, 상기 API 공개 기능 엔티티의 보안 방법은 상기 API 공개 기능 엔티티와 호출자(invoker) 사이의 통신에 사용되며,
    상기 통신 유닛은 상기 원래의 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제2 호출 요청을 전송하고 - 상기 제2 호출 요청은 서비스 API를 호출하는 데 사용됨 - ; 그리고 상기 API 공개 기능 엔티티로부터 상기 제2 호출 요청의 응답 메시지를 수신하도록 구성되어 있으며, 상기 제2 호출 요청의 응답 메시지는 원인 값(cause value)을 포함하고, 상기 원인 값은 상기 서비스 API가 보안 방법의 불일치로 인해 호출되지 않았음을 나타내는 데 사용됨 - ;
    상기 프로세싱 유닛은 상기 원인 값에 따라서, 상기 통신 유닛을 사용하여 공통 API 프레임워크(common API framework, CAPIF) 코어 기능 엔티티에 상기 새로운 보안 방법을 요청하고, 그리고 상기 통신 유닛을 사용하여 상기 새로운 보안 방법을 상기 CAPIF) 코어 기능 엔티티로부터 수신하도록 구성되어 있으며; 그리고
    상기 통신 유닛은 상기 새로운 보안 방법을 사용하여 상기 API 공개 기능 엔티티에 제1 호출 요청을 전송하도록 추가로 구성되어 있으며, 상기 제1 호출 요청은 상기 서비스 API의 이름을 포함하고, 상기 제1 호출 요청은 상기 서비스 API를 호출하는 데 사용되는, 호출자.
  6. 제5항에 있어서,
    상기 통신 유닛은 상기 API 공개 기능 엔티티로부터 제1 호출 요청의 응답 메시지를 수신하도록 구성되어 있으며, 상기 제1 호출 요청의 응답 메시지는 상기 서비스 API가 성공적으로 호출되었음을 나타내는, 호출자.
  7. 컴퓨터 판독 가능형 저장 매체로서,
    상기 컴퓨터 판독 가능형 저장 매체는 명령을 저장하며, 상기 명령이 컴퓨터 상에서 실행될 때, 상기 컴퓨터는 제1항 내지 제4항 중 어느 한 항에 따른 방법을 수행할 수 있는, 컴퓨터 판독 가능형 저장 매체.
  8. 장치로서,
    적어도 하나의 프로세서; 및
    상기 적어도 하나의 프로세서에 결합되고 프로그램 명령이 저장되어 있는 메모리를 포함하며,
    상기 프로그램 명령은 상기 적어도 하나의 프로세서에 의해 실행될 때, 상기 장치로 하여금 제1항 내지 제4항 중 어느 한 항에 따른 방법을 수행하게 하는, 장치.
  9. 삭제
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
  34. 삭제
  35. 삭제
  36. 삭제
  37. 삭제
  38. 삭제
  39. 삭제
  40. 삭제
  41. 삭제
  42. 삭제
  43. 삭제
  44. 삭제
  45. 삭제
  46. 삭제
  47. 삭제
  48. 삭제
  49. 삭제
KR1020207032274A 2018-04-09 2019-04-09 서비스 ａｐｉ 호출 방법 및 관련 장치 KR102488798B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201810312734.1A CN110362412A (zh) 2018-04-09 2018-04-09 一种服务api调用方法和相关装置
CN201810312734.1 2018-04-09
PCT/CN2019/081861 WO2019196819A1 (zh) 2018-04-09 2019-04-09 一种服务api调用方法和相关装置

Publications (2)

Publication Number Publication Date
KR20200141483A KR20200141483A (ko) 2020-12-18
KR102488798B1 true KR102488798B1 (ko) 2023-01-13

Family

ID=68162818

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020207032274A KR102488798B1 (ko) 2018-04-09 2019-04-09 서비스 ａｐｉ 호출 방법 및 관련 장치

Country Status (8)

Country Link
US (1) US11989284B2 (ko)
EP (1) EP3779696A4 (ko)
JP (1) JP7100153B2 (ko)
KR (1) KR102488798B1 (ko)
CN (1) CN110362412A (ko)
AU (1) AU2019251158B2 (ko)
BR (1) BR112020019925A2 (ko)
WO (1) WO2019196819A1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4239982A3 (en) * 2020-02-14 2023-10-25 Telefonaktiebolaget LM Ericsson (publ) Method and network entity for service api publishing
WO2022067736A1 (zh) * 2020-09-30 2022-04-07 华为技术有限公司 一种通信方法及装置
WO2024021137A1 (zh) * 2022-07-29 2024-02-01 北京小米移动软件有限公司 Api调用者认证方法以及装置、通信设备及存储介质
WO2024021142A1 (zh) * 2022-07-29 2024-02-01 北京小米移动软件有限公司 应用程序接口api认证方法、装置、通信设备及存储介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050091576A1 (en) * 2003-10-24 2005-04-28 Microsoft Corporation Programming interface for a computer platform
NO318842B1 (no) 2002-03-18 2005-05-09 Telenor Asa Autentisering og tilgangskontroll
US8195940B2 (en) 2002-04-05 2012-06-05 Qualcomm Incorporated Key updates in a mobile wireless system
US7493592B2 (en) * 2003-10-24 2009-02-17 Microsoft Corporation Programming interface for a computer platform
AU2003293986A1 (en) * 2003-12-23 2005-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for taking an access control policy decision
US8621598B2 (en) 2008-03-12 2013-12-31 Intuit Inc. Method and apparatus for securely invoking a rest API
CN103188344A (zh) 2013-02-22 2013-07-03 浪潮电子信息产业股份有限公司 一种安全调用rest api的方法
US9825956B2 (en) * 2015-10-06 2017-11-21 Netflix, Inc. Systems and methods for access permission revocation and reinstatement
RU2618946C1 (ru) 2015-12-18 2017-05-11 Акционерное общество "Лаборатория Касперского" Способ блокировки доступа к данным на мобильных устройствах с использованием API для пользователей с ограниченными возможностями
CN105634743B (zh) * 2015-12-30 2019-10-25 中国银联股份有限公司 用于开放接口调用的认证方法
CN106067886B (zh) * 2016-08-03 2019-06-14 广州品唯软件有限公司 安全策略更新方法及系统
CN107026853B (zh) * 2017-03-24 2019-10-22 中国联合网络通信集团有限公司 安全认证方法、系统和服务器
WO2018203663A1 (en) * 2017-05-02 2018-11-08 Samsung Electronics Co., Ltd. Method and apparatus for providing network-based northbound application programming interface in a wireless communication system
US20210144550A1 (en) * 2018-04-06 2021-05-13 Nec Corporation Security procedures for common api framework in next generation networks
MX2021000570A (es) * 2018-11-15 2021-07-02 Ericsson Telefon Ab L M Metodo y aparato para revocar la autorizacion de un invocador de api.
KR102510403B1 (ko) * 2019-02-16 2023-03-15 삼성전자주식회사 Capif 코어 기능 엔티티에 api 제공자 도메인 기능 엔티티들을 등록하기 위한 방법 및 장치

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP, TS33.122 Rel.15, "Security Aspects of Common API Framework for 3GPP Northbound APIs"(2018.01.)
Benjamin Dowling et al, "Modelling ciphersuite and version negotiation in the TLS protocol"(2015.04.)

Also Published As

Publication number Publication date
AU2019251158B2 (en) 2022-02-03
US20210081527A1 (en) 2021-03-18
KR20200141483A (ko) 2020-12-18
WO2019196819A1 (zh) 2019-10-17
US11989284B2 (en) 2024-05-21
JP2021518016A (ja) 2021-07-29
BR112020019925A2 (pt) 2021-01-05
EP3779696A4 (en) 2021-05-12
JP7100153B2 (ja) 2022-07-12
CN110362412A (zh) 2019-10-22
EP3779696A1 (en) 2021-02-17
AU2019251158A1 (en) 2020-11-26

Similar Documents

Publication Publication Date Title
KR102488798B1 (ko) 서비스 ａｐｉ 호출 방법 및 관련 장치
CN111865598B (zh) 网络功能服务的身份校验方法及相关装置
KR102478442B1 (ko) Ｐｄｕ 유형 설정 방법, ｕｅ 정책 설정 방법 및 관련 엔티티
US11974132B2 (en) Routing method, apparatus, and system
EP4000296B1 (en) Technique for certificate handling in a core network domain
US9853960B2 (en) Peer applications trust center
US11683218B2 (en) Compromised network node detection system
WO2018202284A1 (en) Authorizing access to user data
US11665532B2 (en) Securing private wireless gateways
WO2021196913A1 (zh) 一种终端参数更新的保护方法和通信装置
US20240086562A1 (en) User data management method and related device
WO2022237693A1 (zh) Nswo业务的认证方法、设备和存储介质
RU2792657C2 (ru) Способ вызова сервисного api и соответствующее устройство
US9077700B2 (en) Authentication server, authentication method and computer program
CN114024693A (zh) 一种认证方法、装置、会话管理功能实体、服务器及终端
US20230401307A1 (en) Trusted root recovery
WO2021226805A1 (zh) 切换方法与装置、云平台和设备
US12003364B2 (en) Compromised network node detection system
WO2023244345A1 (en) Trusted root recovery
CN117201046A (zh) 认证方法及通信装置
CN115842813A (zh) 通信方法以及相关装置

Legal Events

Date Code Title Description
A201 Request for examination
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
X091 Application refused [patent]
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant