인터넷 엔지니어링 태스크 포스 (IETF) M. Thomson
의견 요청: 8292 Mozilla
범주: 표준 트랙 P. Beverloo
ISSN: 2070-1721 Google
2017년 11월
Web Push를 위한 자발적 애플리케이션 서버 식별 (VAPID)
초록
애플리케이션 서버는 이 문서에서 설명하는 자발적 애플리케이션
서버 식별(Voluntary Application Server Identification, VAPID)
방식을 사용하여 푸시 서비스에 자발적으로 자신을 식별할 수 있다.
"vapid" 인증 스킴은 클라이언트가 자신이 수행하는 요청에 서명된
토큰 안에 자신의 신원을 포함할 수 있게 한다. 서명은 동일한
애플리케이션 서버가 수행한 요청을 푸시 서비스가 하나의 단일
엔터티에 귀속시키는 데 사용할 수 있다. 식별 정보는 푸시 서비스의
운영자가 애플리케이션 서버의 운영자에게 연락할 수 있게 한다.
서명은 푸시 메시지 구독의 사용을 단일 애플리케이션 서버로
제한하는 데 사용할 수 있다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물이다. 이
문서는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며
인터넷 엔지니어링 운영 그룹(IESG)에 의해 출판 승인을 받았다.
인터넷 표준에 관한 추가 정보는 RFC 7841의 Section 2에서
확인할 수 있다.
이 문서의 현재 상태, 정오표, 그리고 이에 대한 피드백 제공
방법에 관한 정보는 다음에서 얻을 수 있다.
https://www.rfc-editor.org/info/rfc8292.
Thomson & Beverloo 표준 트랙 [1페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
목차
1. 소개 ........................................................3
1.1. 자발적 식별 .............................................3
1.2. 표기 규약 ...............................................4
2. 애플리케이션 서버 자체 식별 .................................4
2.1. 애플리케이션 서버 연락처 정보 ...........................5
2.2. 추가 클레임 .............................................5
2.3. 암호학적 민첩성 .........................................5
2.4. 예제 ....................................................5
3. VAPID 인증 스킴 .............................................6
3.1. 토큰 파라미터("t") ......................................7
3.2. 공개 키 파라미터("k") ...................................7
4. 구독 제한 ...................................................7
4.1. 제한된 푸시 메시지 구독 생성 ............................8
4.2. 제한된 구독 사용 .........................................9
5. 보안 고려사항 ...............................................9
6. IANA 고려사항 ..............................................10
6.1. VAPID 인증 스킴 등록 ..................................10
6.2. VAPID 인증 스킴 파라미터 ..............................10
6.3. application/webpush-options+json 미디어 타입 등록 ......11
7. 참고문헌 ...................................................12
7.1. 규범적 참고문헌 ........................................12
7.2. 정보성 참고문헌 ........................................14
감사의 말 .....................................................14
저자 주소 .....................................................14
Thomson & Beverloo 표준 트랙 [2페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
1. 소개
Web Push 프로토콜 [RFC8030]은 애플리케이션 서버가 푸시 서비스에
사용자 에이전트로 푸시 메시지를 전달해 달라고 요청할 수 있는
방법을 설명한다.
예상되는 배포 아키텍처의 결과로, 애플리케이션 서버가 푸시
메시지 전달을 요청하기 전에 푸시 서비스에 알려져 있을 근거가
없다. 푸시 서비스가 애플리케이션 서버를 인증할 수 있어야 한다고
요구하면 푸시 서비스의 궁극적 사용자인 사용자 에이전트와
애플리케이션 서버 사이의 상호작용에 원치 않는 제약이 생긴다.
또한 그 제약은 프로토콜이 제공하는 개인정보 보호 속성을
저하시킬 것이다. 이러한 이유로 [RFC8030]은 애플리케이션 서버
인증을 위한 필수 시스템을 정의하지 않는다.
[RFC8030] 설계의 불행한 결과 중 하나는 푸시 서비스가 서비스
거부 공격의 더 큰 위험에 노출된다는 것이다. 애플리케이션 서버의
요청은 사용자 에이전트에 간접적으로 귀속시킬 수 있지만, 이것이
항상 효율적이거나 충분한 것은 아니다. 애플리케이션 서버에 관한
더 많은 정보를 푸시 서비스에 직접 제공하면 푸시 서비스가 합법적
요청과 허위 요청을 더 잘 구별할 수 있다.
또한 [RFC8030]의 설계는 푸시 메시지 구독 URI의 비밀성 유지에
의존한다. 푸시 메시지 구독 URI를 보유한 어떤 애플리케이션 서버도
사용자 에이전트에 메시지를 보낼 수 있다. 구독의 사용을 단일
애플리케이션 서버로 제한할 수 있다면, 권한 없는 당사자가 푸시
메시지 구독 URI를 알게 되는 영향이 줄어들 것이다.
1.1. 자발적 식별
이 문서는 애플리케이션 서버가 푸시 서비스에 자신에 관한 정보를
자발적으로 제공할 수 있는 시스템을 설명한다. 최소한 이것은
애플리케이션 서버에 안정적인 신원을 제공하지만, 이메일 주소와
같은 연락처 정보를 포함할 수도 있다.
일관된 신원은 푸시 서비스가 애플리케이션 서버에 대한 동작
기대치를 설정하는 데 사용할 수 있다. 설정된 기준에서 현저히
벗어나는 경우, 이후 예외 처리 절차를 트리거하는 데 사용할 수
있다.
Thomson & Beverloo 표준 트랙 [3페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
자발적으로 제공된 연락처 정보는 예외적인 상황에서 애플리케이션
서버 운영자에게 연락하는 데 사용할 수 있다.
푸시 서비스 배포 경험에 따르면 소프트웨어 오류나 특이한 상황은
푸시 메시지 양의 큰 증가를 유발할 수 있다. 애플리케이션 서버의
운영자에게 연락하는 것은 유용한 것으로 입증되었다.
사용할 수 있는 연락처 정보가 없는 경우에도, 잘 확립된 평판을
가진 애플리케이션 서버는 푸시 메시지를 폐기할지 여부를 선택할 때
식별되지 않은 애플리케이션 서버보다 우선권을 받을 수 있다.
1.2. 표기 규약
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", 그리고 "OPTIONAL"은 여기에 표시된 것처럼
모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에
설명된 대로 해석된다.
"push message", "push service", "push message subscription",
"application server", 그리고 "user agent"라는 용어는 [RFC8030]에
정의된 대로 사용된다.
2. 애플리케이션 서버 자체 식별
자체 식별을 원하는 애플리케이션 서버는 서명 키 쌍을 생성하고
유지한다. 이 키 쌍은 P-256 곡선 [FIPS186] 위의 타원 곡선
디지털 서명 알고리즘(ECDSA)과 함께 사용할 수 있어야 한다(MUST).
푸시 메시지를 보낼 때 이 키를 사용하면, 여러 메시지에 걸쳐
일관된 애플리케이션 서버의 신원이 설정된다.
푸시 메시지 전달을 요청할 때 애플리케이션은 자신의 서명 키로
서명된 JSON Web Token(JWT) [RFC7519]을 포함한다. 토큰에는 다음과
같은 여러 클레임이 포함된다.
o 토큰의 "aud" (Audience) 클레임은 푸시 리소스 URL의 오리진
([RFC6454]의 Section 6.1)의 유니코드 직렬화를 포함해야 한다(MUST).
이는 토큰을 특정 푸시 서비스에 결합하고, 같은 오리진을
공유하는 모든 푸시 리소스 URL에 대해 토큰을 재사용할 수
있도록 보장한다.
o "exp" (Expiry) 클레임은 토큰이 만료되는 이후의 시간과 함께
포함되어야 한다(MUST). 이는 토큰이 유효한 시간을 제한한다.
"exp" 클레임은 요청 시점으로부터 24시간을 초과해서는 안 된다
Thomson & Beverloo 표준 트랙 [4페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
(MUST NOT). 이를 24시간으로 제한하면 재사용 필요성과 유효한
토큰의 도난으로 인한 잠재 비용 및 가능성 사이의 균형을 맞출
수 있다.
이 JWT는 "vapid" 인증 스킴을 사용하여 Authorization 헤더 필드에
포함된다. JWT 서명이나 그 클레임이 유효하지 않은 경우, 푸시
서비스는 403 (Forbidden) 상태 코드 [RFC7231]로 요청을 거부할
수 있다(MAY). 푸시 서비스는 유효하지 않은 토큰의 정보를 사용해서는
안 된다(MUST NOT).
JWT는 JSON Web Signature(JWS) [RFC7515]를 사용해야 한다(MUST).
서명은 NIST P-256 곡선 [FIPS186]의 ECDSA를 사용해야 하며(MUST),
이는 "ES256" [RFC7518]으로 식별된다.
2.1. 애플리케이션 서버 연락처 정보
애플리케이션 서버가 연락처 세부 정보를 제공하려는 경우 JWT에
"sub" (Subject) 클레임을 포함할 수 있다(MAY). "sub" 클레임은
애플리케이션 서버의 연락처 URI를 "mailto:" (이메일) [RFC6068] 또는
"https:" [RFC2818] URI로 포함하는 것이 좋다(SHOULD).
2.2. 추가 클레임
애플리케이션 서버는 공개 또는 비공개 이름을 사용하여 추가
클레임을 포함할 수 있다(MAY)([RFC7519]의 Sections 4.2 및 4.3 참조).
JWT는 헤더 필드에 있으므로, 추가 클레임의 크기는 가능한 한 작게
유지하는 것이 좋다(SHOULD).
2.3. 암호학적 민첩성
"vapid" HTTP 인증 스킴(Section 3)은 이 문서에서 정의한 JWT의
특정 프로필을 식별하는 데 사용된다. 서명 알고리즘이나 기타
파라미터를 갱신하려면 다른 인증 스킴이 필요하다. 이렇게 하면
새로운 파라미터 협상 메커니즘을 정의하는 대신, 인증 스킴 협상을
위한 기존 메커니즘을 사용할 수 있다.
2.4. 예제
애플리케이션 서버는 [RFC8030]에 설명된 대로 푸시 메시지의
전달을 요청한다. 애플리케이션 서버가 자체 식별을 원하면 "vapid"
인증 스킴을 사용하는 자격 증명과 함께 Authorization 헤더 필드를
포함한다.
Thomson & Beverloo 표준 트랙 [5페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 30
Content-Length: 136
Content-Encoding: aes128gcm
Authorization: vapid
t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
uU_RCPCfA5aq9ojSwk5Y2EmClBPs
{ encrypted push message }
그림 1: JWT를 사용한 푸시 메시지 전달 요청
이 문서의 예제 헤더 필드에는 형식 제약을 충족하기 위해 추가적인
줄바꿈이 포함되어 있다는 점에 유의한다.
Authorization 헤더 필드의 "t" 파라미터에는 JWT가 들어 있으며,
"k" 파라미터에는 해당 토큰에 서명한 base64url 인코딩 키가
포함되어 있다. 서명 키에 대응하는 JWT 입력 값과 JSON Web Key(JWK)
[RFC7517]는 가독성을 위해 추가 공백을 더하여 그림 2에 표시되어
있다. 이 JWT는 2016-01-23T04:36:08Z까지 유효하다.
JWT header = { "typ": "JWT", "alg": "ES256" }
JWT body = { "aud": "https://push.example.net",
"exp": 1453523768,
"sub": "mailto:push@example.com" }
JWK = { "crv":"P-256",
"kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
그림 2: 디코딩된 예제 값
3. VAPID 인증 스킴
이 문서는 "vapid"라는 이름의 새로운 HTTP 인증 스킴 [RFC7235]을
정의한다. 이 인증 스킴은 Section 2에 설명된 서명된 JWT와 그
JWT에 서명한 키를 운반한다.
이 인증 스킴은 오리진 서버 인증 전용이다. 따라서 이 인증 스킴은
Proxy-Authenticate 또는 Proxy-Authorization 헤더 필드와 함께
사용되어서는 안 된다(MUST NOT).
Thomson & Beverloo 표준 트랙 [6페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
"vapid" 인증 스킴의 챌린지는 "auth-scheme" 생성 규칙만 포함한다.
현재 정의된 파라미터는 없다.
이 인증 스킴에는 "t"와 "k"라는 두 파라미터가 정의되어 있다.
"vapid" 인증 자격 증명에 대한 알려지지 않았거나 지원되지 않는
모든 파라미터는 무시되어야 한다(MUST). "realm" 파라미터는 이
인증 스킴에서 무시된다.
이 인증 스킴은 Web Push 프로토콜 [RFC8030]을 사용할 때
애플리케이션 서버가 사용하도록 의도되어 있다.
3.1. 토큰 파라미터("t")
"vapid" 인증 스킴의 "t" 파라미터는 Section 2에 설명된 JWT를
운반한다.
3.2. 공개 키 파라미터("k")
푸시 서비스가 JWT를 검증할 수 있으려면 애플리케이션 서버의 공개
키를 알아야 한다. 이 정보를 운반하기 위해 "vapid" 인증 스킴의
"k" 파라미터가 정의되어 있다.
"k" 파라미터는 압축되지 않은 형식 [X9.62]의 ECDSA 공개 키
[FIPS186]를 포함하며, 이 키는 base64url 인코딩 [RFC7515]을 사용해
인코딩된다.
참고: X9.62 인코딩은 두 가지 이유로 JWK [RFC7517]보다 우선하여
사용된다. JWK에는 정규 형식이 없으므로, X9.62 인코딩은 푸시
서비스가 서로 다른 출처의 키를 비교하기 쉽게 만든다. 둘째로,
X9.62 인코딩은 크기도 상당히 더 작다.
일부 타원 곡선 구현은 동일한 P-256 키를 서명과 키 교환 모두에
사용할 수 있게 한다. 애플리케이션 서버는 키 교환 [RFC8291] 및
인증 토큰 서명에 서로 다른 개인 키를 선택해야 한다(MUST). 푸시
서비스가 모든 푸시 메시지에 대해 두 파라미터 중 하나를 확인할
의무는 없지만, 푸시 서비스는 이러한 파라미터에 동일한 값이 있는
푸시 메시지를 400 (Bad Request) 상태 코드로 거부하는 것이 좋다
(SHOULD).
4. 구독 제한
애플리케이션 서버의 공개 키는 서버에 대한 안정적인 식별자로
기능한다. 이 키는 푸시 메시지 구독을 특정 애플리케이션 서버로
제한하는 데 사용할 수 있다.
Thomson & Beverloo 표준 트랙 [7페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
구독 제한은 애플리케이션 서버가 푸시 메시지 전달을 요청할 때
서명된 토큰을 제공하도록 요구함으로써 엔드포인트 비밀성에 대한
의존을 줄인다. 이는 푸시 메시지 구독의 세부 정보 유출에 대한
추가 보호 수준을 제공한다.
4.1. 제한된 푸시 메시지 구독 생성
제한된 구독을 생성하려는 사용자 에이전트는 푸시 메시지 구독
생성을 요청할 때 애플리케이션 서버의 공개 키를 포함한다. 이는
결과 구독의 사용을 대응하는 개인 키로 서명된 유효한 JWT를 제공할
수 있는 애플리케이션 서버로 제한한다.
그런 다음 사용자 에이전트는 푸시 메시지 구독을 생성하기 위한
요청에 공개 키를 추가한다. 푸시 메시지 구독 요청은 본문을
포함하도록 확장된다. 요청 본문은 [RFC7159]에 설명된 JSON
객체이다. 사용자 에이전트는 이 JSON 객체에 P-256 곡선의 공개
키를 포함하는 "vapid" 멤버를 추가하며, 이 키는 압축되지 않은
형식 [X9.62] 및 base64url 인코딩 [RFC7515]으로 인코딩된다. 본문의
미디어 타입은 "application/webpush-options+json"으로 설정된다
(이 미디어 타입의 등록은 Section 6.3 참조).
푸시 서비스는 다른 미디어 타입을 사용하는 요청의 본문을
무시해야 한다(MUST). "application/webpush-options+json" 미디어
타입의 경우, 푸시 서비스는 이해하지 못하는 이 객체의 모든 멤버를
무시해야 한다(MUST).
그림 3의 예제는 그림 1에서 사용된 키로 제한하는 것을 보여준다.
형식 제약을 충족하기 위해 추가 공백이 더해져 있다.
POST /subscribe/ HTTP/1.1
Host: push.example.net
Content-Type: application/webpush-options+json
Content-Length: 104
{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
그림 3: 예제 구독 요청
애플리케이션은 Push API [API]를 사용하여 사용자 에이전트에 공개 키를
제공할 수 있다.
Thomson & Beverloo 표준 트랙 [8페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
4.2. 제한된 구독 사용
푸시 메시지 구독이 애플리케이션 서버로 제한된 경우, 푸시 메시지
전달 요청에는 구독을 생성할 때 사용된 공개 키에 대응하는 개인
키로 서명된 JWT가 포함되어야 한다(MUST).
제한된 푸시 메시지 구독으로 전송된 메시지에 "vapid" 인증이
없거나 유효하지 않은 "vapid" 인증이 포함된 경우, 푸시 서비스는
그 메시지를 거부해야 한다(MUST). 인증이 없는 경우 401
(Unauthorized) 상태 코드가 사용될 수 있으며, 인증이 유효하지 않은
경우 403 (Forbidden) 상태 코드가 사용될 수 있다.
"vapid" 인증은 다음과 같은 경우 유효하지 않다.
o 인증 토큰이나 공개 키 중 하나가 요청에 포함되어 있지 않은
경우,
o 포함된 공개 키를 사용하여 JWT의 서명을 성공적으로 검증할 수
없는 경우,
o 현재 시간이 "exp" (Expiry) 클레임에 식별된 시간보다 늦거나,
만료 시간보다 24시간을 초과하여 이른 경우,
o 푸시 리소스의 오리진이 "aud" (Audience) 클레임에 포함되어 있지
않은 경우, 또는
o JWT 서명에 사용된 공개 키가 푸시 메시지 구독 생성에 포함된
공개 키와 일치하지 않는 경우.
푸시 서비스는 푸시 메시지를 전달할 때 JWT 또는 공개 키를 사용자
에이전트에 전달해서는 안 된다(MUST NOT).
서명 키를 교체해야 하는 애플리케이션 서버는 갱신된 키로 제한된
새로운 구독의 생성을 사용자 에이전트에 요청해야 한다.
애플리케이션 서버는 구독 생성을 요청할 때 사용한 키를 기억해야
한다.
5. 보안 고려사항
이 인증 스킴은 공격자가 유효한 JWT를 획득할 수 있는 경우 재생
공격에 취약하다. [RFC8030]에서 요구하는 대로 HTTPS를 사용해
요청을 보내면 기밀성이 제공된다. 또한 재사용 가능한 토큰이
재사용될 수 있는 기간에 좁은 제한을 적용하면, 도난당한 토큰이
공격자에게 갖는 잠재적 가치를 제한하고 토큰을 훔치는 난이도를
높일 수 있다.
Thomson & Beverloo 표준 트랙 [9페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
애플리케이션 서버는 위조된 연락처 정보를 제공할 수 있다.
애플리케이션 서버는 그 주장을 뒷받침할 어떤 증거도 없이 자신의
이메일 주소나 연락처 URI를 주장한다. 푸시 서비스 운영자는 검증되지
않은 연락처 정보의 존재를 보안상 중요한 의사결정 과정의 입력으로
사용할 수 없다.
JWT의 서명 검증에는 상당한 양의 계산이 필요하다. 서비스 거부
공격 상황에서 합법적인 요청을 식별하는 데 사용될 수 있는 것치고는
이상적이지 않다. 따라서 애플리케이션 서버에는 토큰을 재사용할
것이 권장되며, 이를 통해 푸시 서비스는 서명 검증 결과를 캐시할 수
있다.
서명 키를 변경하는 애플리케이션 서버는 서로 다른 키 아래에서
전송하는 푸시 메시지 간의 연결 가능성을 깨뜨린다. 애플리케이션
서버에 대한 일관된 신원에 의존하는 푸시 서비스는 새로운 키로 만든
요청을 다르게 분류할 수 있다. 새로운 서명 키로 점진적으로
마이그레이션하면 새로운 키를 사용하는 요청이 남용으로 분류될
가능성이 줄어든다.
6. IANA 고려사항
이 문서는 새로운 인증 스킴, 해당 스킴의 파라미터를 위한 레지스트리,
그리고 푸시 옵션을 위한 미디어 타입을 등록한다.
6.1. VAPID 인증 스킴 등록
이 문서는 [RFC7235]에 의해 수립된 "Hypertext Transfer Protocol
(HTTP) Authentication Scheme Registry"에 "vapid" 인증 스킴을
등록한다.
인증 스킴 이름: vapid
명세 텍스트 포인터: 이 문서의 Section 3
6.2. VAPID 인증 스킴 파라미터
이 문서는 "vapid" 인증 스킴의 파라미터를 위한 "VAPID
Authentication Scheme Parameters" 레지스트리를 생성한다. 이러한
파라미터는 요청(Authorization 헤더 필드)과 챌린지(WWW-Authenticate
헤더 필드)에서 사용하기 위해 정의된다. 이 레지스트리는 "Web Push
Parameters" 그룹 아래에 있다. 레지스트리는 "Specification Required"
정책 [RFC8126]에 따라 운영된다.
Thomson & Beverloo 표준 트랙 [10페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
등록에는 다음 정보가 포함되어야 한다(MUST).
파라미터 이름: "token" 문법 [RFC7230]을 따르는 파라미터의 이름
목적(선택 사항): 파라미터의 목적을 식별하는 간단한 텍스트
헤더 필드: 파라미터가 사용될 수 있는 헤더 필드
명세: 파라미터의 형식과 의미를 정의하는 명세에 대한 링크
이 레지스트리는 처음에 다음 항목을 포함한다.
+-------------+------------------+---------------+------------------+
| 파라미터 | 목적 | 헤더 | 명세 |
| 이름 | | 필드 | |
+-------------+------------------+---------------+------------------+
| t | JWT | Authorization | [RFC8292], |
| | 인증 | | Section 3.1 |
| | 토큰 | | |
| | | | |
| k | 서명 키 | Authorization | [RFC8292], |
| | | | Section 3.2 |
+-------------+------------------+---------------+------------------+
6.3. application/webpush-options+json 미디어 타입 등록
이 문서는 [RFC6838]에 설명된 절차에 따라 "Media Types"
레지스트리에 "application/webpush-options+json" 미디어 타입을
등록한다.
타입 이름: application
서브타입 이름: webpush-options+json
필수 파라미터: 없음
선택 파라미터: 없음
인코딩 고려사항: binary (JSON은 UTF-8로 인코딩된 텍스트임)
보안 고려사항: JSON에 특정된 보안 고려사항은 [RFC7159] 참조.
Thomson & Beverloo 표준 트랙 [11페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
상호운용성 고려사항: JSON에 특정된 상호운용성 고려사항은
[RFC7159] 참조.
공개된 명세: [RFC8292]
이 미디어 타입을 사용하는 애플리케이션: Web Push 프로토콜
[RFC8030]을 통한 웹 브라우저
프래그먼트 식별자 고려사항: 없음
추가 정보:
이 타입의 폐기된 별칭 이름: n/a
매직 넘버: n/a
파일 확장자: .json
Macintosh 파일 타입 코드: TEXT
추가 정보 문의 담당자 및 이메일 주소: Martin Thomson
(martin.thomson@gmail.com)
의도된 사용: LIMITED USE
사용 제한: Web Push 프로토콜 [RFC8030]과 함께 사용
저자: [RFC8292]의 "Authors' Addresses" 절 참조.
변경 관리자: 인터넷 엔지니어링 태스크 포스
7. 참고문헌
7.1. 규범적 참고문헌
[FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
Thomson & Beverloo 표준 트랙 [12페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<https://www.rfc-editor.org/info/rfc6068>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016,
<https://www.rfc-editor.org/info/rfc8030>.
Thomson & Beverloo 표준 트랙 [13페이지]
RFC 8292 Web Push를 위한 VAPID 2017년 11월
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291,
DOI 10.17487/RFC8291, November 2017,
<http://www.rfc-editor.org/info/rfc8291>.
[X9.62] ANSI, "Public Key Cryptography for the Financial Services
Industry: the Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 2005.
7.2. 정보성 참고문헌
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", October 2017,
<https://www.w3.org/TR/push-api/>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
감사의 말
이 문서는 Benjamin Bangert, JR Conlin, Chris Karlof, Costin
Manolache, Adam Roach 및 다른 이들의 기여가 없었다면 지금보다 훨씬
나빴을 것이다.
저자 주소
Martin Thomson
Mozilla
이메일: martin.thomson@gmail.com
Peter Beverloo
Google
이메일: beverloo@google.com
Thomson & Beverloo 표준 트랙 [14페이지]