draft-ietf-webpush-vapid-01.txt		draft-ietf-webpush-vapid-02.txt
	Network Working Group M. Thomson		Network Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track P. Beverloo		Intended status: Standards Track P. Beverloo
	Expires: December 31, 2016 Google		Expires: June 25, 2017 Google
	June 29, 2016		December 22, 2016
	Voluntary Application Server Identification for Web Push		Voluntary Application Server Identification for Web Push
	draft-ietf-webpush-vapid-01		draft-ietf-webpush-vapid-02
	Abstract		Abstract
	An application server can voluntarily identify itself to a push		An application server can voluntarily identify itself to a push
	service using the described technique. This identification		service using the described technique. This identification
	information can be used by the push service to attribute requests		information can be used by the push service to attribute requests
	that are made by the same application server to a single entity.		that are made by the same application server to a single entity.
	This can used to reduce the secrecy for push subscription URLs by		This can used to reduce the secrecy for push subscription URLs by
	being able to restrict subscriptions to a specific application		being able to restrict subscriptions to a specific application
	server. An application server is further able to include additional		server. An application server is further able to include additional
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 31, 2016.		This Internet-Draft will expire on June 25, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3		1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Application Server Self-Identification . . . . . . . . . . . 4		2. Application Server Self-Identification . . . . . . . . . . . 4
	2.1. Application Server Contact Information . . . . . . . . . 4		2.1. Application Server Contact Information . . . . . . . . . 4
	2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Additional Claims . . . . . . . . . . . . . . . . . . . . 4
	3. WebPush Authentication Scheme . . . . . . . . . . . . . . . . 5		2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Public Key Representation . . . . . . . . . . . . . . . . . . 6		3. Vapid Authentication Scheme . . . . . . . . . . . . . . . . . 6
	5. Subscription Restriction . . . . . . . . . . . . . . . . . . 6		3.1. Token Parameter (t) . . . . . . . . . . . . . . . . . . . 6
	5.1. Creating a Restricted Push Subscription . . . . . . . . . 7		3.2. Public Key Parameter (k) . . . . . . . . . . . . . . . . 6
	5.2. Using Restricted Subscriptions . . . . . . . . . . . . . 7		4. Subscription Restriction . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4.1. Creating a Restricted Push Subscription . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4.2. Using Restricted Subscriptions . . . . . . . . . . . . . 8
	7.1. WebPush Authentication Scheme . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7.2. p256ecdsa Parameter for Crypto-Key Header Field . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Vapid Authentication Scheme Parameters . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Web Push protocol [I-D.ietf-webpush-protocol] describes how an		The Web Push protocol [I-D.ietf-webpush-protocol] describes how an
	application server is able to request that a push service deliver a		application server is able to request that a push service deliver a
	push message to a user agent.		push message to a user agent.
	As a consequence of the expected deployment architecture, there is no		As a consequence of the expected deployment architecture, there is no
	basis for an application server to be known to a push service prior		basis for an application server to be known to a push service prior
	to requesting delivery of a push message. Requiring that the push		to requesting delivery of a push message. Requiring that the push
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 11 ¶
	The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this		The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
	document. It's not shouting, when they are capitalized, they have		document. It's not shouting, when they are capitalized, they have
	the special meaning described in [RFC2119].		the special meaning described in [RFC2119].
	The terms "push message", "push service", "push subscription",		The terms "push message", "push service", "push subscription",
	"application server", and "user agent" are used as defined in		"application server", and "user agent" are used as defined in
	[I-D.ietf-webpush-protocol].		[I-D.ietf-webpush-protocol].
	2. Application Server Self-Identification		2. Application Server Self-Identification
	Application servers that wish to self-identity generate and maintain		Application servers that wish to self-identify generate and maintain
	a signing key pair. This key pair MUST be usable with elliptic curve		a signing key pair. This key pair MUST be usable with elliptic curve
	digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of		digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of
	this key when sending push messages establishes an identity for the		this key when sending push messages establishes an identity for the
	application server that is consistent across multiple messages.		application server that is consistent across multiple messages.
	When requesting delivery of a push message, the application includes		When requesting delivery of a push message, the application includes
	a JSON Web Token (JWT) [RFC7519], signed using its signing key. The		a JSON Web Token (JWT) [RFC7519], signed using its signing key. The
	token includes a number of claims as follows:		token includes a number of claims as follows:
	o An "aud" (Audience) claim in the token MUST include the unicode		o An "aud" (Audience) claim in the token MUST include the unicode
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 33 ¶
	resource URL. This binds the token to a specific push service.		resource URL. This binds the token to a specific push service.
	This ensures that the token is reusable for all push resource URLs		This ensures that the token is reusable for all push resource URLs
	that share the same origin.		that share the same origin.
	o An "exp" (Expiry) claim MUST be included with the time after which		o An "exp" (Expiry) claim MUST be included with the time after which
	the token expires. This limits the time that a token over which a		the token expires. This limits the time that a token over which a
	token is valid. An "exp" claim MUST NOT be more than 24 hours		token is valid. An "exp" claim MUST NOT be more than 24 hours
	from the time of the request.		from the time of the request.
	This JWT is included in an Authorization header field, using an auth-		This JWT is included in an Authorization header field, using an auth-
	scheme of "WebPush". A push service MAY reject a request with a 403		scheme of "vapid". A push service MAY reject a request with a 403
	(Forbidden) status code [RFC7235] if the JWT signature or its claims		(Forbidden) status code [RFC7235] if the JWT signature or its claims
	are invalid.		are invalid.
	The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature		The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature
	MUST use ECDSA on the NIST P-256 curve [FIPS186], that is "ES256"		MUST use ECDSA on the NIST P-256 curve [FIPS186] which is identified
	[RFC7518].		as "ES256" [RFC7518].
	2.1. Application Server Contact Information		2.1. Application Server Contact Information
	If the application server wishes to provide contact details it MAY		If the application server wishes to provide contact details it MAY
	include an "sub" (Subject) claim in the JWT. The "sub" claim SHOULD		include a "sub" (Subject) claim in the JWT. The "sub" claim SHOULD
	include a contact URI for the application server as either a		include a contact URI for the application server as either a
	"mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI.		"mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI.
	2.2. Example		2.2. Additional Claims
			An application server MAY include additional claims using public or
			private names (see Sections 4.2 and 4.3 of [RFC7519]). Since the JWT
			is in a header field, the size of additional claims SHOULD be kept as
			small as possible.
			2.3. Example
	An application server requests the delivery of a push message as		An application server requests the delivery of a push message as
	described in [I-D.ietf-webpush-protocol]. If the application server		described in [I-D.ietf-webpush-protocol]. If the application server
	wishes to self-identify, it includes an Authorization header field		wishes to self-identify, it includes an Authorization header field
	with credentials that use the "WebPush" authentication scheme		with credentials that use the "vapid" authentication scheme
	Section 3 and a Crypto-Key header field that includes its public key		(Section 3).
	Section 4.
	POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1		POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
	Host: push.example.net		Host: push.example.net
	Content-Type: text/plain;charset=utf8		TTL: 30
	Content-Length: 36		Content-Length: 136
	Authorization: WebPush		Content-Encoding: aes128gcm
	eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3B		Authorization: vapid
	1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx		t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
	0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_HLGk		B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
	MlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA		Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
	Crypto-Key: p256ecdsa=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH		LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
	F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs		k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
			uU_RCPCfA5aq9ojSwk5Y2EmClBPs
	iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB		{ encrypted push message }
	Figure 1: Requesting Push Message Delivery with JWT		Figure 1: Requesting Push Message Delivery with JWT
	Note that the header fields shown in Figure 1 don't include line		Note that the example header fields in this document include extra
	wrapping. Extra whitespace is added to meet formatting constraints.		line wrapping to meet formatting constraints.
	The value of the Authorization header field is a base64url-encoded		The "t" parameter of the Authorization header field contains a JWT;
	JWT with the header and body shown in Figure 2. This JWT would be		the "k" parameter includes the base64url-encoded key that signed that
	valid until 2016-01-21T01:53:25Z [RFC3339].		token. The JWT input values and the JWK [RFC7517] corresponding to
			the signing key are shown in Figure 2 with additional whitespace
			added for readability purposes. This JWT would be valid until
			2016-01-21T01:53:25Z [RFC3339].
	header = {"typ":"JWT","alg":"ES256"}		JWT header = { "typ": "JWT", "alg": "ES256" }
	body = { "aud":"https://push.example.net",		JWT body = { "aud": "https://push.example.net",
	"exp":1453341205,		"exp": 1453341205,
	"sub":"mailto:push@example.com" }		"sub": "mailto:push@example.com" }
			JWK = { "crv":"P-256",
			"kty":"EC",
			"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
			"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
	Figure 2: Example JWT Header and Body		Figure 2: Decoded Example Values
	3. WebPush Authentication Scheme		3. Vapid Authentication Scheme
	A new "WebPush" HTTP authentication scheme [RFC7235] is defined.		A new "vapid" HTTP authentication scheme [RFC7235] is defined. This
	This authentication scheme carries a signed JWT, as described in		authentication scheme carries a signed JWT, as described in
	Section 2.		Section 2, plus the key that signed that JWT.
	This authentication scheme is for origin-server authentication only.		This authentication scheme is for origin-server authentication only.
	Therefore, this authentication scheme MUST NOT be used with the		Therefore, this authentication scheme MUST NOT be used with the
	Proxy-Authenticate or Proxy-Authorization header fields.		Proxy-Authenticate or Proxy-Authorization header fields.
	This authentication scheme does not require a challenge. Clients are		This authentication scheme does not require a challenge. Clients are
	able to generate the Authorization header field without any		able to generate the Authorization header field without any
	additional information from a server. Therefore, a challenge for		additional information from a server. Therefore, a challenge for
	this authentication scheme MUST NOT be sent in a WWW-Authenticate		this authentication scheme MUST NOT be sent in a WWW-Authenticate
	header field.		header field.
	All unknown or unsupported parameters to "WebPush" authentication		Two parameters are defined for this authentication scheme: "t" and
			"k". All unknown or unsupported parameters to "vapid" authentication
	credentials MUST be ignored. The "realm" parameter is ignored for		credentials MUST be ignored. The "realm" parameter is ignored for
	this authentication scheme.		this authentication scheme.
	4. Public Key Representation		This authentication scheme is intended for use by an application
			server when using the Web Push protocol [I-D.ietf-webpush-protocol],
			but it could be used in other contexts if applicable.
			3.1. Token Parameter (t)
			The "t" parameter of the "vapid" authentication scheme carries a JWT
			as described in Section 2.
			3.2. Public Key Parameter (k)
	In order for the push service to be able to validate the JWT, it		In order for the push service to be able to validate the JWT, it
	needs to learn the public key of the application server. A		needs to learn the public key of the application server. A "k"
	"p256ecdsa" parameter is defined for the Crypto-Key header field		parameter is defined for the "vapid" authentication scheme to carry
	[I-D.ietf-httpbis-encryption-encoding] to carry this information.		this information.
	The "p256ecdsa" parameter includes an elliptic curve digital		The "k" parameter includes an elliptic curve digital signature
	signature algorithm (ECDSA) public key [FIPS186] in uncompressed form		algorithm (ECDSA) public key [FIPS186] in uncompressed form [X9.62]
	[X9.62] that is encoded using the URL- and filename-safe variant of		that is encoded using base64url encoding [RFC7515].
	base-64 [RFC4648] with padding removed.
	Note that with push message encryption [I-D.ietf-webpush-encryption],		Note: X9.62 encoding is used over JWK [RFC7517] for two reasons. A
	this results in two values in the Crypto-Key header field, one with		JWK does not have a canonical form, so X9.62 encoding makes it
	the a "dh" key and another with a "p256ecdsa" key.		easier for the push service to handle comparison of keys from
			different sources. Secondarily, the X9.62 encoding is also
			considerably smaller.
	Some implementations permit the same P-256 key to be used for signing		Some implementations permit the same P-256 key to be used for signing
	and key exchange. An application server MUST select a different		and key exchange. An application server MUST select a different
	private key for the key exchange (i.e., "dh") and signing (i.e.,		private key for the key exchange [I-D.ietf-webpush-encryption] and
	"p256ecdsa"). Though a push service is not obligated to check either		signing the authentication token. Though a push service is not
	parameter for every push message, a push service SHOULD reject push		obligated to check either parameter for every push message, a push
	messages that have identical values for these parameters with a 400		service SHOULD reject push messages that have identical values for
	(Bad Request) status code.		these parameters with a 400 (Bad Request) status code.
	Editor's Note: JWK [RFC7517] seems like the obvious choice here.
	However, JWK doesn't define a compact representation for public
	keys, which complicates the representation of JWK in a header
	field.
	5. Subscription Restriction		4. Subscription Restriction
	The public key of the application server serves as a stable		The public key of the application server serves as a stable
	identifier for the server. This key can be used to restrict a push		identifier for the server. This key can be used to restrict a push
	subscription to a specific application server.		subscription to a specific application server.
	Subscription restriction reduces the reliance on endpoint secrecy by		Subscription restriction reduces the reliance on endpoint secrecy by
	requiring proof of possession to be demonstrated by an application		requiring proof of possession to be demonstrated by an application
	server when requesting delivery of a push message. This provides an		server when requesting delivery of a push message. This provides an
	additional level of protection against leaking of the details of the		additional level of protection against leaking of the details of the
	push subscription.		push subscription.
	5.1. Creating a Restricted Push Subscription		4.1. Creating a Restricted Push Subscription
	The user agent includes the public key of the application server when		The user agent includes the public key of the application server when
	requesting the creation of a push subscription. This restricts use		requesting the creation of a push subscription. This restricts use
	of the resulting subscription to application servers that are able to		of the resulting subscription to application servers that are able to
	provide proof of possession for the corresponding private key.		provide proof of possession for the corresponding private key.
	This public key is then added to the request to create a push		The public key is then added to the request to create a push
	subscription as described in Section 4. The Crypto-Key header field		subscription. The push subscription request is extended to include a
	includes exactly one public key. For example:		body. The body of the request is a JSON object as described in
			[RFC7159]. A "vapid" member is added to this JSON object, containing
			the public key on the P-256 curve, encoded in the uncompressed form
			[X9.62] and base64url encoded [RFC7515]. The MIME media type of the
			body is set to "application/json".
			The example in Figure 3 shows a restriction to the key used in
			Figure 1. Extra whitespace is added to to meet formatting
			constraints.
	POST /subscribe/ HTTP/1.1		POST /subscribe/ HTTP/1.1
	Host: push.example.net		Host: push.example.net
	Crypto-Key: p256ecdsa=BBa22H8qaZ-iDMH9izb4qE72puwyvfjH2RxoQr5oiS4b		Content-Type: application/json;charset=utf-8
	KImoRwJm5xK9hLrbfIik20g31z8MpLFMCMr8y2cu6gY		Content-Length: 104
	Figure 3: Example Subscribe Request		{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
			F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
	An application might use the Web Push API [API] to include this		Figure 3: Example Subscribe Request
	information. For example, the API might permit an application to
	provide a public key as part of a new field on the
	"PushSubscriptionOptions" dictionary.
	Note: Allowing the inclusion of multiple keys when creating a		An application might use the Web Push API [API] to provide the user
	subscription would allow a subscription to be associated with		agent with a public key.
	multiple application servers or application server instances.
	This might be more flexible, but it also would require more state
	to be maintained by the push service for each subscription.
	5.2. Using Restricted Subscriptions		4.2. Using Restricted Subscriptions
	When a push subscription has been associated with an application		When a push subscription has been associated with an application
	server, the request for push message delivery MUST include proof of		server, the request for push message delivery MUST include proof of
	possession for the associated private key that was used when creating		possession for the associated private key that was used when creating
	the push subscription.		the push subscription.
	A push service MUST reject a message that omits mandatory credentials		A push service MUST reject a message that omits mandatory credentials
	with a 401 (Unauthorized) status code. A push service MAY reject a		with a 401 (Unauthorized) status code. A push service MAY reject a
	message that includes invalid credentials with a 403 (Forbidden)		message that includes invalid credentials with a 403 (Forbidden)
	status code. Credentials are invalid if:		status code. Credentials are invalid if:
	o either the authentication credentials or public key are not		o either the authentication token or public key are not included in
	included in the request,		the request,
	o the signature on the JWT cannot be successfully verified using the		o the signature on the JWT cannot be successfully verified using the
	included public key,		included public key,
	o the current time is later than the time identified in the "exp"		o the current time is later than the time identified in the "exp"
	(Expiry) claim or more than 24 hours before the expiry time,		(Expiry) claim or more than 24 hours before the expiry time,
	o the origin of the push resource is not included in the "aud"		o the origin of the push resource is not included in the "aud"
	(Audience) claim, or		(Audience) claim, or
	o the public key used to sign the JWT doesn't match the one that was		o the public key used to sign the JWT doesn't match the one that was
	included in the creation of the push message.		included in the creation of the push subscription.
	Note: In theory, since the push service was given a public key, the
	push message request could omit the public key. On balance,
	requiring the key keeps things simple and it allows push services
	to compress the public key (by hashing it, for example). In any
	case, the relatively minor space savings aren't particularly
	important on the connection between the application server and
	push service.
	A push service MUST NOT forward the JWT or public key to the user		A push service MUST NOT forward the JWT or public key to the user
	agent when delivering the push message.		agent when delivering the push message.
	6. Security Considerations		5. Security Considerations
	This authentication scheme is vulnerable to replay attacks if an		This authentication scheme is vulnerable to replay attacks if an
	attacker can acquire a valid JWT. Applying narrow limits to the		attacker can acquire a valid JWT. Applying narrow limits to the
	period over which a replayable token can be reused limits the		period over which a replayable token can be reused limits the
	potential value of a stolen token to an attacker and can increase the		potential value of a stolen token to an attacker and can increase the
	difficulty of stealing a token.		difficulty of stealing a token.
	An application server might offer falsified contact information. A		An application server might offer falsified contact information. A
	push service operator therefore cannot use the presence of		push service operator therefore cannot use the presence of
	unvalidated contact information as input to any security-critical		unvalidated contact information as input to any security-critical
	decision-making process.		decision-making process.
	Validation of a signature on the JWT requires a non-trivial amount of		Validation of a signature on the JWT requires a non-trivial amount of
	computation. For something that might be used to identify legitimate		computation. For something that might be used to identify legitimate
	requests under denial of service attack conditions, this is not		requests under denial of service attack conditions, this is not
	ideal. Application servers are therefore encouraged to reuse a JWT,		ideal. Application servers are therefore encouraged to reuse tokens,
	which permits the push service to cache the results of signature		which permits the push service to cache the results of signature
	validation.		validation.
	7. IANA Considerations		6. IANA Considerations
	7.1. WebPush Authentication Scheme
	This registers the "WebPush" authentication scheme in the "Hypertext		This document registers the "vapid" authentication scheme in the
	Transfer Protocol (HTTP) Authentication Scheme Registry" established		"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
	in [RFC7235].		established in [RFC7235].
	Authentication Scheme Name: WebPush		Authentication Scheme Name: vapid
	Pointer to specification text: Section 3 of this document		Pointer to specification text: Section 3 of this document
	Notes: This scheme is origin-server only and does not define a		Notes: This scheme is origin-server only and does not define a
	challenge.		challenge.
	7.2. p256ecdsa Parameter for Crypto-Key Header Field		6.1. Vapid Authentication Scheme Parameters
	This registers a "p256ecdsa" parameter for the Crypto-Key header		This creates a "Vapid Authentication Scheme Parameters" registry for
	field in the "Hypertext Transfer Protocol (HTTP) Crypto-Key		parameters to the "vapid" authentication scheme. This registry is
	Parameters" established in [I-D.ietf-httpbis-encryption-encoding].		under the "WebPush Parameters" grouping. The registry operates on
			the "Specification Required" policy [RFC5226].
	Parameter Name: p256ecdsa		Registrations MUST include the following information:
	Purpose: Conveys a public key for that is used to generate an ECDSA		Parameter Name: A name for the parameter, which conforms to the
	signature.		"token" grammar [RFC7230]
	Reference: Section 4 of this document		Purpose (optional): A brief identifying the purpose of the
			parameter.
	8. Acknowledgements		Specification: A link to the specification that defines the format
			and semantics of the parameter.
			This registry initially contains the following entries:
			+---------------+-------------------------+-------------------------+
			| Parameter | Purpose | Specification |
			| Name | | |
			+---------------+-------------------------+-------------------------+
			| t | JWT authentication | [[RFC-to-be]], Section |
			| | token | 3.1 |
			| | | |
			| k | ECDSA signing key | [[RFC-to-be]], Section |
			| | | 3.2 |
			+---------------+-------------------------+-------------------------+
			7. Acknowledgements
	This document would have been much worse than it currently is if not		This document would have been much worse than it currently is if not
	for the contributions of Benjamin Bangert, Chris Karlof, Costin		for the contributions of Benjamin Bangert, JR Conlin, Chris Karlof,
	Manolache, and others.		Costin Manolache, and others.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[FIPS186] National Institute of Standards and Technology (NIST),		[FIPS186] National Institute of Standards and Technology (NIST),
	"Digital Signature Standard (DSS)", NIST PUB 186-4 , July		"Digital Signature Standard (DSS)", NIST PUB 186-4 , July
	2013.		2013.
	[I-D.ietf-httpbis-encryption-encoding]
	Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
	ietf-httpbis-encryption-encoding-01 (work in progress),
	March 2016.
	[I-D.ietf-webpush-protocol]		[I-D.ietf-webpush-protocol]
	Thomson, M., Damaggio, E., and B. Raymor, "Generic Event		Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
	Delivery Using HTTP Push", draft-ietf-webpush-protocol-06		Delivery Using HTTP Push", draft-ietf-webpush-protocol-12
	(work in progress), June 2016.		(work in progress), October 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	<http://www.rfc-editor.org/info/rfc4648>.		DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
	[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'		[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
	URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,		URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
	<http://www.rfc-editor.org/info/rfc6068>.		<http://www.rfc-editor.org/info/rfc6068>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<http://www.rfc-editor.org/info/rfc6454>.		<http://www.rfc-editor.org/info/rfc6454>.
			[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
			2014, <http://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,
			<http://www.rfc-editor.org/info/rfc7230>.
			[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Authentication", RFC 7235,
			DOI 10.17487/RFC7235, June 2014,
			<http://www.rfc-editor.org/info/rfc7235>.
	[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May		Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
	2015, <http://www.rfc-editor.org/info/rfc7515>.		2015, <http://www.rfc-editor.org/info/rfc7515>.
	[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,		[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
	DOI 10.17487/RFC7518, May 2015,		DOI 10.17487/RFC7518, May 2015,
	<http://www.rfc-editor.org/info/rfc7518>.		<http://www.rfc-editor.org/info/rfc7518>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<http://www.rfc-editor.org/info/rfc7519>.		<http://www.rfc-editor.org/info/rfc7519>.
	[X9.62] ANSI, "Public Key Cryptography For The Financial Services		[X9.62] ANSI, "Public Key Cryptography For The Financial Services
	Industry: The Elliptic Curve Digital Signature Algorithm		Industry: The Elliptic Curve Digital Signature Algorithm
	(ECDSA)", ANSI X9.62 , 1998.		(ECDSA)", ANSI X9.62 , 1998.
	9.2. Informative References		8.2. Informative References
	[API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015,		[API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015,
	<https://w3c.github.io/push-api/>.		<https://w3c.github.io/push-api/>.
	[I-D.ietf-webpush-encryption]		[I-D.ietf-webpush-encryption]
	Thomson, M., "Message Encryption for Web Push", draft-		Thomson, M., "Message Encryption for Web Push", draft-
	ietf-webpush-encryption-02 (work in progress), March 2016.		ietf-webpush-encryption-06 (work in progress), October
			2016.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<http://www.rfc-editor.org/info/rfc3339>.		<http://www.rfc-editor.org/info/rfc3339>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Authentication", RFC 7235,
	DOI 10.17487/RFC7235, June 2014,
	<http://www.rfc-editor.org/info/rfc7235>.
	[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,		[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
	DOI 10.17487/RFC7517, May 2015,		DOI 10.17487/RFC7517, May 2015,
	<http://www.rfc-editor.org/info/rfc7517>.		<http://www.rfc-editor.org/info/rfc7517>.
	Authors' Addresses		Authors' Addresses
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Email: martin.thomson@gmail.com		Email: martin.thomson@gmail.com
End of changes. 55 change blocks.
	142 lines changed or deleted		180 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/