draft-ietf-ace-oscore-profile-06.txt		draft-ietf-ace-oscore-profile-07.txt
	ACE Working Group F. Palombini		ACE Working Group F. Palombini
	Internet-Draft Ericsson AB		Internet-Draft Ericsson AB
	Intended status: Standards Track L. Seitz		Intended status: Standards Track L. Seitz
	Expires: July 7, 2019 RISE SICS AB		Expires: August 23, 2019 RISE SICS AB
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	M. Gunnarsson		M. Gunnarsson
	RISE SICS AB		RISE SICS AB
	January 3, 2019		February 19, 2019
	OSCORE profile of the Authentication and Authorization for Constrained		OSCORE profile of the Authentication and Authorization for Constrained
	Environments Framework		Environments Framework
	draft-ietf-ace-oscore-profile-06		draft-ietf-ace-oscore-profile-07
	Abstract		Abstract
	This memo specifies a profile for the Authentication and		This memo specifies a profile for the Authentication and
	Authorization for Constrained Environments (ACE) framework. It		Authorization for Constrained Environments (ACE) framework. It
	utilizes Object Security for Constrained RESTful Environments		utilizes Object Security for Constrained RESTful Environments
	(OSCORE) to provide communication security, server authentication,		(OSCORE) to provide communication security, server authentication,
	and proof-of-possession for a key owned by the client and bound to an		and proof-of-possession for a key owned by the client and bound to an
	OAuth 2.0 access token.		OAuth 2.0 access token.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 July 7, 2019.		This Internet-Draft will expire on August 23, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21		9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 21
	9.2. OSCORE Security Context Parameters Registry . . . . . . . 22		9.2. OSCORE Security Context Parameters Registry . . . . . . . 22
	9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22		9.3. CWT Confirmation Methods Registry . . . . . . . . . . . . 22
	9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23		9.4. JWT Confirmation Methods Registry . . . . . . . . . . . . 23
	9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23		9.5. Expert Review Instructions . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . 24		10.1. Normative References . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25		Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 25
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	This memo specifies a profile of the ACE framework		This memo specifies a profile of the ACE framework
	[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource		[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
	server use CoAP [RFC7252] to communicate. The client uses an access		server use CoAP [RFC7252] to communicate. The client uses an access
	token, bound to a key (the proof-of-possession key) to authorize its		token, bound to a key (the proof-of-possession key) to authorize its
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)		OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)
	[RFC8152] to secure CoAP messages. Note that OSCORE can be used to		[RFC8152] to secure CoAP messages. Note that OSCORE can be used to
	secure CoAP messages, as well as HTTP and combinations of HTTP and		secure CoAP messages, as well as HTTP and combinations of HTTP and
	CoAP; a profile of ACE similar to the one described in this document,		CoAP; a profile of ACE similar to the one described in this document,
	with the difference of using HTTP instead of CoAP as communication		with the difference of using HTTP instead of CoAP as communication
	protocol, could be specified analogously to this one.		protocol, could be specified analogously to this one.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119]. These		"OPTIONAL" in this document are to be interpreted as described in BCP
	words may also appear in this document in lowercase, absent their		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	normative meanings.		capitals, as shown here.
	Certain security-related terms such as "authentication",		Certain security-related terms such as "authentication",
	"authorization", "confidentiality", "(data) integrity", "message		"authorization", "confidentiality", "(data) integrity", "message
	authentication code", and "verify" are taken from [RFC4949].		authentication code", and "verify" are taken from [RFC4949].
	RESTful terminology follows HTTP [RFC7231].		RESTful terminology follows HTTP [RFC7231].
	Terminology for entities in the architecture is defined in OAuth 2.0		Terminology for entities in the architecture is defined in OAuth 2.0
	[RFC6749], such as client (C), resource server (RS), and		[RFC6749], such as client (C), resource server (RS), and
	authorization server (AS). It is assumed in this document that a		authorization server (AS). It is assumed in this document that a
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	Figure 8 shows an example CWT, containing the necessary OSCORE		Figure 8 shows an example CWT, containing the necessary OSCORE
	parameters in the 'cnf' claim for update of access rights, in CBOR		parameters in the 'cnf' claim for update of access rights, in CBOR
	diagnostic notation without tag and value abbreviations.		diagnostic notation without tag and value abbreviations.
	{		{
	"aud" : "tempSensorInLivingRoom",		"aud" : "tempSensorInLivingRoom",
	"iat" : "1360189224",		"iat" : "1360189224",
	"exp" : "1360289224",		"exp" : "1360289224",
	"scope" : "temperature_h",		"scope" : "temperature_h",
	"cnf" : {		"cnf" : {
	"kid" : b64'Qg'		"kid" : b64'qA'
	}		}
	}		}
	Figure 8: Example CWT with OSCORE parameters for update of access		Figure 8: Example CWT with OSCORE parameters for update of access
	rights.		rights.
	3.2.1. OSCORE_Security_Context Object		3.2.1. OSCORE_Security_Context Object
	An OSCORE_Security_Context is an object that represents part or all		An OSCORE_Security_Context is an object that represents part or all
	of an OSCORE Security Context (Section 3.1 of		of an OSCORE Security Context (Section 3.1 of
	skipping to change at page 13, line 16 ¶		skipping to change at page 13, line 16 ¶
	bstr, and has label 1.		bstr, and has label 1.
	clientId: This parameter identifies a client identifier as a byte		clientId: This parameter identifies a client identifier as a byte
	string. This identifier is used as OSCORE Sender ID in the client		string. This identifier is used as OSCORE Sender ID in the client
	and OSCORE Recipient ID in the server. For more information about		and OSCORE Recipient ID in the server. For more information about
	this field, see section 3.1 of [I-D.ietf-core-object-security].		this field, see section 3.1 of [I-D.ietf-core-object-security].
	In JSON, the "clientId" value is a Base64 encoded byte string. In		In JSON, the "clientId" value is a Base64 encoded byte string. In
	CBOR, the "clientId" type is bstr, and has label 2.		CBOR, the "clientId" type is bstr, and has label 2.
	serverId: This parameter identifies a server identifier as a byte		serverId: This parameter identifies a server identifier as a byte
	string. This identifier is used as OSCORE Sender ID in the client		string. This identifier is used as OSCORE Sender ID in the server
	and OSCORE Recipient ID in the server. For more information about		and OSCORE Recipient ID in the client. For more information about
	this field, see section 3.1 of [I-D.ietf-core-object-security].		this field, see section 3.1 of [I-D.ietf-core-object-security].
	In JSON, the "serverId" value is a Base64 encoded byte string. In		In JSON, the "serverId" value is a Base64 encoded byte string. In
	CBOR, the "serverId" type is bstr, and has label 3.		CBOR, the "serverId" type is bstr, and has label 3.
	hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more		hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
	information about this field, see section 3.1 of		information about this field, see section 3.1 of
	[I-D.ietf-core-object-security]. The values used MUST be		[I-D.ietf-core-object-security]. The values used MUST be
	registered in the IANA "COSE Algorithms" registry and MUST be		registered in the IANA "COSE Algorithms" registry and MUST be
	HMAC-based HKDF algorithms. The value can either be the integer		HMAC-based HKDF algorithms. The value can either be the integer
	or the text string value of the HMAC-based HKDF algorithm in the		or the text string value of the HMAC-based HKDF algorithm in the
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	"salt" value is a Base64 encoded byte string. In CBOR, the "salt"		"salt" value is a Base64 encoded byte string. In CBOR, the "salt"
	type is bstr, and has label 6.		type is bstr, and has label 6.
	contextId: This parameter identifies the security context as a byte		contextId: This parameter identifies the security context as a byte
	string. This identifier is used as OSCORE ID Context. For more		string. This identifier is used as OSCORE ID Context. For more
	information about this field, see section 3.1 of		information about this field, see section 3.1 of
	[I-D.ietf-core-object-security]. In JSON, the "contextID" value		[I-D.ietf-core-object-security]. In JSON, the "contextID" value
	is a Base64 encoded byte string. In CBOR, the "contextID" type is		is a Base64 encoded byte string. In CBOR, the "contextID" type is
	bstr, and has label 7.		bstr, and has label 7.
	repl: This parameter is used to carry the OSCORE value, encoded as a		rpl: This parameter is used to carry the OSCORE value, encoded as a
	bstr. This parameter identifies the OSCORE Replay Window Size and		bstr. This parameter identifies the OSCORE Replay Window Size and
	Type value, which is a byte string. For more information about		Type value, which is a byte string. For more information about
	this field, see section 3.1 of [I-D.ietf-core-object-security].		this field, see section 3.1 of [I-D.ietf-core-object-security].
	In JSON, the "repl" value is a Base64 encoded byte string. In		In JSON, the "rpl" value is a Base64 encoded byte string. In
	CBOR, the "repl" type is bstr, and has label 8.		CBOR, the "rpl" type is bstr, and has label 8.
	An example of JSON OSCORE_Security_Context is given in Figure 9.		An example of JSON OSCORE_Security_Context is given in Figure 9.
	"OSCORE_Security_Context" : {		"OSCORE_Security_Context" : {
	"alg" : "AES-CCM-16-64-128",		"alg" : "AES-CCM-16-64-128",
	"clientId" : b64'qA',		"clientId" : b64'qA',
	"serverId" : b64'Qg',		"serverId" : b64'Qg',
	"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'		"ms" : b64'+a+Dg2jjU+eIiOFCa9lObw'
	}		}
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	Figure 10: Example C-to-RS POST /authz-info request using CWT		Figure 10: Example C-to-RS POST /authz-info request using CWT
	4.2. RS-to-C: 2.01 (Created)		4.2. RS-to-C: 2.01 (Created)
	The RS MUST follow the procedures defined in section 5.8.1 of		The RS MUST follow the procedures defined in section 5.8.1 of
	[I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the		[I-D.ietf-ace-oauth-authz]: the RS MUST verify the validity of the
	token. If the token is valid, the RS MUST respond to the POST		token. If the token is valid, the RS MUST respond to the POST
	request with 2.01 (Created). If the token is valid but is associated		request with 2.01 (Created). If the token is valid but is associated
	to claims that the RS cannot process (e.g., an unknown scope), or if		to claims that the RS cannot process (e.g., an unknown scope), or if
	any of the expected parameters in the OSCORE_Security_Context is		any of the expected parameters in the OSCORE_Security_Context is
	missing (e.g. any of the mandatory parameters from the AS), the RS		missing (e.g. any of the mandatory parameters from the AS), or if any
	MUST respond with a response code equivalent to the CoAP code 4.00		parameters received in the OSCORE_Security_Context is unrecognized,
	(Bad Request). In the latter case the RS MAY provide additional		the RS MUST respond with an error response code equivalent to the
	information in the error response, in order to clarify what went		CoAP code 4.00 (Bad Request). In the latter two cases, the RS MAY
	wrong. The RS MAY make an introspection request to validate the		provide additional information in the error response, in order to
	token before responding to the POST request to the authz-info		clarify what went wrong. The RS MAY make an introspection request to
	endpoint.		validate the token before responding to the POST request to the
			authz-info endpoint.
	Additionally, the RS MUST generate a nonce N2 very unlikely to have		Additionally, the RS MUST generate a nonce N2 very unlikely to have
	been previously used with the same input keying material, and send it		been previously used with the same input keying material, and send it
	within the 2.01 (Created) response. The payload of the 2.01		within the 2.01 (Created) response. The payload of the 2.01
	(Created) response MUST be a CBOR map containing the 'nonce'		(Created) response MUST be a CBOR map containing the 'nonce'
	parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set		parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set
	to N2. This profile RECOMMENDS to use a 64-bit long random number as		to N2. This profile RECOMMENDS to use a 64-bit long random number as
	nonce. Moreover, if the OSCORE_Security_Context in the token did not		nonce. Moreover, if the OSCORE_Security_Context in the token did not
	contain a 'clientId' parameter, the RS MUST generate an identifier,		contain a 'clientId' parameter, the RS MUST generate an identifier,
	unique in the set of all its existing client identifiers, and send it		unique in the set of all its existing client identifiers, and send it
	skipping to change at page 18, line 16 ¶		skipping to change at page 18, line 16 ¶
	If any of the expected parameters is missing (e.g. any of the		If any of the expected parameters is missing (e.g. any of the
	mandatory parameters from the AS, or the 'clientId', either received		mandatory parameters from the AS, or the 'clientId', either received
	from the AS or in the 2.01 (Created) response from the RS), the		from the AS or in the 2.01 (Created) response from the RS), the
	client MUST stop the exchange, and MUST NOT derive the Security		client MUST stop the exchange, and MUST NOT derive the Security
	Context. The client MAY restart the exchange, to get the correct		Context. The client MAY restart the exchange, to get the correct
	security material.		security material.
	The client then uses this Security Context to send requests to RS		The client then uses this Security Context to send requests to RS
	using OSCORE. In the first request sent to the RS, the client MAY		using OSCORE. In the first request sent to the RS, the client MAY
	include the kid context, with value ID Context, i.e. N1 concatenated		include the kid context if the application needs to, with value ID
	with N2.		Context, i.e. N1 concatenated with N2.
	After sending the 2.01 (Created) response, the RS MUST set the ID		After sending the 2.01 (Created) response, the RS MUST set the ID
	Context of the Security Context created to communicate with the		Context of the Security Context created to communicate with the
	client to the concatenation of N1 and N2, in this order: ID Context =		client to the concatenation of N1 and N2, in this order: ID Context =
	N1 | N2, where | denotes byte string concatenation. The RS MUST set		N1 | N2, where | denotes byte string concatenation. The RS MUST set
	the Master Secret, Sender ID and Recipient ID from the parameters,		the Master Secret, Sender ID and Recipient ID from the parameters,
	received from the client in the access token in Section 4.1 after		received from the client in the access token in Section 4.1 after
	validation of the token as specified in Section 4.2. The RS MUST set		validation of the token as specified in Section 4.2. The RS MUST set
	the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the		the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the
	parameters received from the client in the access token in		parameters received from the client in the access token in
	Section 4.1 after validation of the token as specified in		Section 4.1 after validation of the token as specified in
	Section 4.2, if present. In case these parameters are omitted, the		Section 4.2, if present. In case these parameters are omitted, the
	default values are used as described in section 3.2 of		default values are used as described in section 3.2 of
	[I-D.ietf-core-object-security]. After that, the RS MUST derive the		[I-D.ietf-core-object-security]. After that, the RS MUST derive the
	complete Security Context following section 3.2.1 of		complete Security Context following section 3.2.1 of
	[I-D.ietf-core-object-security], and MUST associate this Security		[I-D.ietf-core-object-security], and MUST associate this Security
	Context with the authorization information from the access token.		Context with the authorization information from the access token.
	The RS then uses this Security Context to verify the request and send		The RS then uses this Security Context to verify the request and send
	responses to RS using OSCORE. If OSCORE verification fails, error		responses to C using OSCORE. If OSCORE verification fails, error
	responses are used, as specified in section 8 of		responses are used, as specified in section 8 of
	[I-D.ietf-core-object-security]. Additionally, if OSCORE		[I-D.ietf-core-object-security]. Additionally, if OSCORE
	verification succeeds, the verification of access rights is performed		verification succeeds, the verification of access rights is performed
	as described in section Section 4.4. The RS MUST NOT use the		as described in section Section 4.4. The RS MUST NOT use the
	Security Context after the related token has expired, and MUST		Security Context after the related token has expired, and MUST
	respond with a unprotected 4.01 (Unauthorized) error message.		respond with a unprotected 4.01 (Unauthorized) error message.
	4.4. Access rights verification		4.4. Access rights verification
	The RS MUST follow the procedures defined in section 5.8.2 of		The RS MUST follow the procedures defined in section 5.8.2 of
	skipping to change at page 24, line 15 ¶		skipping to change at page 24, line 15 ¶
	size.		size.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21
	(work in progress), November 2018.		(work in progress), February 2019.
	[I-D.ietf-ace-oauth-params]		[I-D.ietf-ace-oauth-params]
	Seitz, L., "Additional OAuth Parameters for Authorization		Seitz, L., "Additional OAuth Parameters for Authorization
	in Constrained Environments (ACE)", draft-ietf-ace-oauth-		in Constrained Environments (ACE)", draft-ietf-ace-oauth-
	params-01 (work in progress), November 2018.		params-04 (work in progress), February 2019.
	[I-D.ietf-core-object-security]		[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-15 (work in		(OSCORE)", draft-ietf-core-object-security-15 (work in
	progress), August 2018.		progress), August 2018.
	[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,
	skipping to change at page 24, line 43 ¶		skipping to change at page 24, line 43 ¶
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
			[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>.
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ace-cwt-proof-of-possession]		[I-D.ietf-ace-cwt-proof-of-possession]
	Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-		Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
End of changes. 16 change blocks.
	28 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/