< draft-hardt-gnap-jose-00.txt		draft-hardt-gnap-jose-01.txt >
	Network Working Group D. Hardt, Ed.		Network Working Group D. Hardt, Ed.
	Internet-Draft SignIn.Org		Internet-Draft SignIn.Org
	Intended status: Standards Track 7 June 2020		Intended status: Standards Track 4 July 2020
	Expires: 9 December 2020		Expires: 5 January 2021
	JOSE Authentication		JOSE Authentication
	draft-hardt-gnap-jose-00		draft-hardt-gnap-jose-01
	Abstract		Abstract
	TBD		TBD
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 9 December 2020.		This Internet-Draft will expire on 5 January 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	2.2.4. Public Key Resolution . . . . . . . . . . . . . . . . 9		2.2.4. Public Key Resolution . . . . . . . . . . . . . . . . 9
	2.3. Request Encryption . . . . . . . . . . . . . . . . . . . 9		2.3. Request Encryption . . . . . . . . . . . . . . . . . . . 9
	2.4. Response Signing . . . . . . . . . . . . . . . . . . . . 9		2.4. Response Signing . . . . . . . . . . . . . . . . . . . . 9
	2.5. Response Encryption . . . . . . . . . . . . . . . . . . . 10		2.5. Response Encryption . . . . . . . . . . . . . . . . . . . 10
	3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Normative References . . . . . . . . . . . . . . . . . . . . 10		6. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Document History . . . . . . . . . . . . . . . . . . 11		Appendix A. Document History . . . . . . . . . . . . . . . . . . 11
	A.1. draft-hardt-gnap-jose-00 . . . . . . . . . . . . . . . . 11		A.1. draft-hardt-gnap-jose-00 . . . . . . . . . . . . . . . . 11
			A.2. draft-hardt-gnap-jose-01 . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	TBD		TBD
	*Terminology*		*Terminology*
	This document uses the following terms defined in [GNAP]:		This document uses the following terms defined in [GNAP]:
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	The token may be included in an HTTP header, or as the HTTP message		The token may be included in an HTTP header, or as the HTTP message
	body.		body.
	The following sections specify how the Client uses JOSE to		The following sections specify how the Client uses JOSE to
	authenticate to the GS and RS.		authenticate to the GS and RS.
	2.1. Grant Server Access		2.1. Grant Server Access
	The Client authenticates to the GS by passing either a signed header		The Client authenticates to the GS by passing either a signed header
	parameter, or a signed message body. The following table shows the		parameter, or a signed message body. The following table shows the
	verb, uri and token location for each Client request to the GS:		method, uri and token location for each Client request to the GS:
	+---------------+-----------+-----------+----------+		+===============+=============+===========+==========+
	| request | http verb | uri | token in |		| request | http method | uri | token in |
	+===============+===========+===========+==========+		+===============+=============+===========+==========+
	| Create Grant | POST | GS URI | body |		| Create Grant | POST | GS URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Verify Grant | PATCH | Grant URI | body |		| Verify Grant | PATCH | Grant URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Read Grant | GET | Grant URI | header |		| Read Grant | GET | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Update Grant | PUT | Grant URI | body |		| Update Grant | PUT | Grant URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Delete Grant | DELETE | Grant URI | header |		| Delete Grant | DELETE | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Read AuthZ | GET | AZ URI | header |		| Read AuthZ | GET | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Update AuthZ | PUT | AZ URI | body |		| Update AuthZ | PUT | AZ URI | body |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Delete AuthZ | DELETE | AZ URI | header |		| Delete AuthZ | DELETE | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| GS Options | OPTIONS | GS URI | header |		| GS Options | OPTIONS | GS URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| Grant Options | OPTIONS | Grant URI | header |		| Grant Options | OPTIONS | Grant URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	| AuthZ Options | OPTIONS | AZ URI | header |		| AuthZ Options | OPTIONS | AZ URI | header |
	+---------------+-----------+-----------+----------+		+---------------+-------------+-----------+----------+
	Table 1		Table 1
	2.1.1. Authorization Header		2.1.1. Authorization Header
	For requests with the token in the header, the JWS payload MUST		For requests with the token in the header, the JWS payload MUST
	contain the following attributes:		contain the following attributes:
	*iat* - the time the token was created as a NumericDate.		*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section		*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.		4.1.7.
	*uri* - the value of the URI being called (GS URI, Grant URI, or AZ		*uri* - the value of the URI being called (GS URI, Grant URI, or AZ
	URI).		URI).
	*verb* - the HTTP verb being used in the call ("GET", "DELETE",		*method* - the HTTP method being used in the call ("GET", "DELETE",
	"OPTIONS")		"OPTIONS")
	The HTTP authorization header is set to the "jose" parameter followed		The HTTP authorization header is set to the "jose" parameter followed
	by one or more white space characters, followed by the resulting		by one or more white space characters, followed by the resulting
	token.		token.
	A non-normative example of a JWS payload and the HTTP request		A non-normative example of a JWS payload and the HTTP request
	follows:		follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",		"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://as.example/endpoint/grant/example6",		"uri" : "https://as.example/endpoint/grant/example6",
	"verb" : "GET"		"method" : "GET"
	}		}
	GET /endpoint/example.grant HTTP/2		GET /endpoint/example.grant HTTP/2
	Host: as.example		Host: as.example
	Authorization: jose eyJhbGciOiJIUzI1NiIsIn ...		Authorization: jose eyJhbGciOiJIUzI1NiIsIn ...
	[Editor: make a real example token]		[Editor: make a real example token]
	*GS Verification*		*GS Verification*
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	"x" : "Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",		"x" : "Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4",
	"y" : "GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"		"y" : "GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4"
	}		}
	}		}
	2.2. Resource Server Access		2.2. Resource Server Access
	In the "jose" mechanism Section 2.2.2, all Client requests to the RS		In the "jose" mechanism Section 2.2.2, all Client requests to the RS
	include a proof-of-possession token in the HTTP authorization header.		include a proof-of-possession token in the HTTP authorization header.
	In the "jose+body" mechanism Section 2.2.3, the Client signs the JSON		In the "jose+body" mechanism Section 2.2.3, the Client signs the JSON
	document in the request if the POST or PUT verbs are used, otherwise		document in the request if the POST or PUT methods are used,
	it is the same as the "jose" mechanism.		otherwise it is the same as the "jose" mechanism.
	2.2.1. JOSE header		2.2.1. JOSE header
	The GS provides the Client one or more JWS header parameters and		The GS provides the Client one or more JWS header parameters and
	values for a a certificate, or a reference to a certificate or		values for a a certificate, or a reference to a certificate or
	certificate chain, that the RS can use to resolve the public key		certificate chain, that the RS can use to resolve the public key
	matching the private key being used by the Client.		matching the private key being used by the Client.
	A non-normative examples JOSE header:		A non-normative examples JOSE header:
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 42 ¶
	The JWS payload MUST contain the following attributes:		The JWS payload MUST contain the following attributes:
	*iat* - the time the token was created as a NumericDate.		*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section		*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.		4.1.7.
	*uri* - the value of the RS URI being called.		*uri* - the value of the RS URI being called.
	*verb* - the HTTP verb being used in the call		*method* - the HTTP method being used in the call
	*token* - the access token provided by the GS to the Client		*token* - the access token provided by the GS to the Client
	The HTTP authorization header is set to the "jose" parameter followed		The HTTP authorization header is set to the "jose" parameter followed
	by one or more white space characters, followed by the resulting		by one or more white space characters, followed by the resulting
	token.		token.
	A non-normative example of a JWS payload and the HTTP request		A non-normative example of a JWS payload and the HTTP request
	follows:		follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",		"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://calendar.example/calendar",		"uri" : "https://calendar.example/calendar",
	"verb" : "GET",		"method" : "GET",
	"token" : "eyJJ2D6.example.access.token.mZf9pTSpA"		"token" : "eyJJ2D6.example.access.token.mZf9pTSpA"
	}		}
	GET /calendar HTTP/2		GET /calendar HTTP/2
	Host: calendar.example		Host: calendar.example
	Authorization: jose eyJhbG.example.jose.token.adks		Authorization: jose eyJhbG.example.jose.token.adks
	[Editor: make a real example token]		[Editor: make a real example token]
	*RS Verification*		*RS Verification*
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	Requests sending a message body MUST have the following JWS payload:		Requests sending a message body MUST have the following JWS payload:
	*iat* - the time the token was created as a NumericDate.		*iat* - the time the token was created as a NumericDate.
	*jti* - a unique identifier for the token per [RFC7519] section		*jti* - a unique identifier for the token per [RFC7519] section
	4.1.7.		4.1.7.
	*uri* - the value of the RS URI being called.		*uri* - the value of the RS URI being called.
	*verb* - the HTTP verb being used in the call		*method* - the HTTP method being used in the call
	*token* - the access token provided by the GS to the Client		*token* - the access token provided by the GS to the Client
	*body* - the message body being sent to the RS		*body* - the message body being sent to the RS
	A non-normative example of a JWS payload and the HTTP request		A non-normative example of a JWS payload and the HTTP request
	follows:		follows:
	{		{
	"iat" : 15790460234,		"iat" : 15790460234,
	"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",		"jti" : "f6d72254-4f23-417f-b55e-14ad323b1dc1",
	"uri" : "https://calendar.example/calendar",		"uri" : "https://calendar.example/calendar",
	"verb" : "POST",		"method": "POST",
	"token" : "eyJJ2D6.example.access.token.mZf9pTSpA",		"token" : "eyJJ2D6.example.access.token.mZf9pTSpA",
	"payload" : {		"payload" : {
	"event" : {		"event" : {
	"title" : "meeting with joe",		"title" : "meeting with joe",
	"start_date_utc" : "2020-02-21 11:00:00",		"start_date_utc" : "2020-02-21 11:00:00",
	"end_date_utc" : "2020-02-21 11:00:00"		"end_date_utc" : "2020-02-21 11:00:00"
	}		}
	}		}
	}		}
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 32 ¶
	[GNAP] Hardt, D., "The Grant Negotiation and Authorization		[GNAP] Hardt, D., "The Grant Negotiation and Authorization
	Protocol", June 2020,		Protocol", June 2020,
	<https://tools.ietf.org/html/draft-hardt-xauth-protocol>.		<https://tools.ietf.org/html/draft-hardt-xauth-protocol>.
	Appendix A. Document History		Appendix A. Document History
	A.1. draft-hardt-gnap-jose-00		A.1. draft-hardt-gnap-jose-00
	* Initial version		* Initial version
			A.2. draft-hardt-gnap-jose-01
			* renamed HTTP verb to method
	Author's Address		Author's Address
	Dick Hardt (editor)		Dick Hardt (editor)
	SignIn.Org		SignIn.Org
	United States		United States
	Email: dick.hardt@gmail.com		Email: dick.hardt@gmail.com
End of changes. 14 change blocks.
	45 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/