draft-ietf-ace-oauth-authz-36.txt		draft-ietf-ace-oauth-authz-37.txt
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft Combitech		Internet-Draft Combitech
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: May 21, 2021 Ericsson		Expires: August 8, 2021 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	November 17, 2020		February 4, 2021
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	using the OAuth 2.0 Framework (ACE-OAuth)		using the OAuth 2.0 Framework (ACE-OAuth)
	draft-ietf-ace-oauth-authz-36		draft-ietf-ace-oauth-authz-37
	Abstract		Abstract
	This specification defines a framework for authentication and		This specification defines a framework for authentication and
	authorization in Internet of Things (IoT) environments called ACE-		authorization in Internet of Things (IoT) environments called ACE-
	OAuth. The framework is based on a set of building blocks including		OAuth. The framework is based on a set of building blocks including
	OAuth 2.0 and the Constrained Application Protocol (CoAP), thus		OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
	transforming a well-known and widely used authorization solution into		transforming a well-known and widely used authorization solution into
	a form suitable for IoT devices. Existing specifications are used		a form suitable for IoT devices. Existing specifications are used
	where possible, but extensions are added and profiles are defined to		where possible, but extensions are added and profiles are defined to
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 May 21, 2021.		This Internet-Draft will expire on August 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 36, line 49 ¶		skipping to change at page 36, line 49 ¶
	token is valid, the RS MUST respond to the POST request with 2.01		token is valid, the RS MUST respond to the POST request with 2.01
	(Created). Section Section 5.10.1.1 outlines how an RS MUST proceed		(Created). Section Section 5.10.1.1 outlines how an RS MUST proceed
	to verify the validity of an access token.		to verify the validity of an access token.
	The RS MUST be prepared to store at least one access token for future		The RS MUST be prepared to store at least one access token for future
	use. This is a difference to how access tokens are handled in OAuth		use. This is a difference to how access tokens are handled in OAuth
	2.0, where the access token is typically sent along with each		2.0, where the access token is typically sent along with each
	request, and therefore not stored at the RS.		request, and therefore not stored at the RS.
	This specification RECOMMENDS that an RS stores only one token per		This specification RECOMMENDS that an RS stores only one token per
	proof-of-possession key, meaning that an additional token linked to		proof-of-possession key. This means that an additional token linked
	the same key will overwrite any existing token at the RS. The reason		to the same key will supersede any existing token at the RS, by
	is that this greatly simplifies (constrained) implementations, with		replacing the corresponding authorization information. The reason is
			that this greatly simplifies (constrained) implementations, with
	respect to required storage and resolving a request to the applicable		respect to required storage and resolving a request to the applicable
	token.		token.
	If the payload sent to the authz-info endpoint does not parse to a		If the payload sent to the authz-info endpoint does not parse to a
	token, the RS MUST respond with a response code equivalent to the		token, the RS MUST respond with a response code equivalent to the
	CoAP code 4.00 (Bad Request).		CoAP code 4.00 (Bad Request).
	The RS MAY make an introspection request to validate the token before		The RS MAY make an introspection request to validate the token before
	responding to the POST request to the authz-info endpoint, e.g. if		responding to the POST request to the authz-info endpoint, e.g. if
	the token is an opaque reference. Some transport protocols may		the token is an opaque reference. Some transport protocols may
	skipping to change at page 62, line 29 ¶		skipping to change at page 62, line 29 ¶
	<https://www.bluetooth.com/specifications/bluetooth-core-		<https://www.bluetooth.com/specifications/bluetooth-core-
	specification/>.		specification/>.
	[I-D.erdtman-ace-rpcc]		[I-D.erdtman-ace-rpcc]
	Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-		Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
	Key as OAuth client credentials", draft-erdtman-ace-		Key as OAuth client credentials", draft-erdtman-ace-
	rpcc-02 (work in progress), October 2017.		rpcc-02 (work in progress), October 2017.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-32 (work		and Secure Transport", draft-ietf-quic-transport-34 (work
	in progress), October 2020.		in progress), January 2021.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-39 (work in progress),		1.3", draft-ietf-tls-dtls13-40 (work in progress), January
	November 2020.		2021.
	[Margi10impact]		[Margi10impact]
	Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,		Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
	M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,		M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
	"Impact of Operating Systems on Wireless Sensor Networks		"Impact of Operating Systems on Wireless Sensor Networks
	(Security) Applications and Testbeds", Proceedings of		(Security) Applications and Testbeds", Proceedings of
	the 19th International Conference on Computer		the 19th International Conference on Computer
	Communications and Networks (ICCCN), August 2010.		Communications and Networks (ICCCN), August 2010.
	[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT		[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
End of changes. 8 change blocks.
	12 lines changed or deleted		13 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/