< draft-ietf-ace-cbor-web-token-11.txt		draft-ietf-ace-cbor-web-token-12.txt >
	ACE Working Group M. Jones		ACE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track E. Wahlstroem		Intended status: Standards Track E. Wahlstroem
	Expires: July 25, 2018		Expires: August 6, 2018
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	January 21, 2018		February 2, 2018
	CBOR Web Token (CWT)		CBOR Web Token (CWT)
	draft-ietf-ace-cbor-web-token-11		draft-ietf-ace-cbor-web-token-12
	Abstract		Abstract
	CBOR Web Token (CWT) is a compact means of representing claims to be		CBOR Web Token (CWT) is a compact means of representing claims to be
	transferred between two parties. The claims in a CWT are encoded in		transferred between two parties. The claims in a CWT are encoded in
	the Concise Binary Object Representation (CBOR) and CBOR Object		the Concise Binary Object Representation (CBOR) and CBOR Object
	Signing and Encryption (COSE) is used for added application layer		Signing and Encryption (COSE) is used for added application layer
	security protection. A claim is a piece of information asserted		security protection. A claim is a piece of information asserted
	about a subject and is represented as a name/value pair consisting of		about a subject and is represented as a name/value pair consisting of
	a claim name and a claim value. CWT is derived from JSON Web Token		a claim name and a claim value. CWT is derived from JSON Web Token
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 25, 2018.		This Internet-Draft will expire on August 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	A.2.1. 128-bit Symmetric Key . . . . . . . . . . . . . . . . 16		A.2.1. 128-bit Symmetric Key . . . . . . . . . . . . . . . . 16
	A.2.2. 256-bit Symmetric Key . . . . . . . . . . . . . . . . 17		A.2.2. 256-bit Symmetric Key . . . . . . . . . . . . . . . . 17
	A.2.3. ECDSA P-256 256-bit COSE Key . . . . . . . . . . . . 17		A.2.3. ECDSA P-256 256-bit COSE Key . . . . . . . . . . . . 17
	A.3. Example Signed CWT . . . . . . . . . . . . . . . . . . . 17		A.3. Example Signed CWT . . . . . . . . . . . . . . . . . . . 17
	A.4. Example MACed CWT . . . . . . . . . . . . . . . . . . . . 18		A.4. Example MACed CWT . . . . . . . . . . . . . . . . . . . . 18
	A.5. Example Encrypted CWT . . . . . . . . . . . . . . . . . . 19		A.5. Example Encrypted CWT . . . . . . . . . . . . . . . . . . 19
	A.6. Example Nested CWT . . . . . . . . . . . . . . . . . . . 20		A.6. Example Nested CWT . . . . . . . . . . . . . . . . . . . 20
	A.7. Example MACed CWT with a floating-point value . . . . . . 21		A.7. Example MACed CWT with a floating-point value . . . . . . 21
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 22		Appendix C. Document History . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The JSON Web Token (JWT) [RFC7519] is a standardized security token		The JSON Web Token (JWT) [RFC7519] is a standardized security token
	format that has found use in OAuth 2.0 and OpenID Connect		format that has found use in OAuth 2.0 and OpenID Connect
	deployments, among other applications. JWT uses JSON Web Signature		deployments, among other applications. JWT uses JSON Web Signature
	(JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] to secure the		(JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] to secure the
	contents of the JWT, which is a set of claims represented in JSON.		contents of the JWT, which is a set of claims represented in JSON.
	The use of JSON for encoding information is popular for Web and		The use of JSON for encoding information is popular for Web and
	native applications, but it is considered inefficient for some		native applications, but it is considered inefficient for some
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	signatures over encrypted text are not considered valid in many		signatures over encrypted text are not considered valid in many
	jurisdictions.		jurisdictions.
	9. IANA Considerations		9. IANA Considerations
	9.1. CBOR Web Token (CWT) Claims Registry		9.1. CBOR Web Token (CWT) Claims Registry
	This section establishes the IANA "CBOR Web Token (CWT) Claims"		This section establishes the IANA "CBOR Web Token (CWT) Claims"
	registry.		registry.
	Values are registered on a Specification Required [RFC5226] basis		Depending upon the values being requested, registration requests are
	after a three-week review period on the cwt-reg-review@ietf.org		evaluated on a Standards Track Required, Specification Required,
	mailing list, on the advice of one or more Designated Experts.		Expert Review, or Private Use basis [RFC8126] after a three-week
	However, to allow for the allocation of values prior to publication,		review period on the cwt-reg-review@ietf.org mailing list, on the
	the Designated Experts may approve registration once they are		advice of one or more Designated Experts. However, to allow for the
	satisfied that such a specification will be published. [[ Note to		allocation of values prior to publication, the Designated Experts may
	the RFC Editor: The name of the mailing list should be determined in		approve registration once they are satisfied that such a
	consultation with the IESG and IANA. Suggested name: cwt-reg-		specification will be published. [[ Note to the RFC Editor: The name
	review@ietf.org. ]]		of the mailing list should be determined in consultation with the
			IESG and IANA. Suggested name: cwt-reg-review@ietf.org. ]]
	Registration requests sent to the mailing list for review should use		Registration requests sent to the mailing list for review should use
	an appropriate subject (e.g., "Request to register claim: example").		an appropriate subject (e.g., "Request to register claim: example").
	Registration requests that are undetermined for a period longer than		Registration requests that are undetermined for a period longer than
	21 days can be brought to the IESG's attention (using the		21 days can be brought to the IESG's attention (using the
	iesg@ietf.org mailing list) for resolution.		iesg@ietf.org mailing list) for resolution.
	Criteria that should be applied by the Designated Experts includes		Criteria that should be applied by the Designated Experts includes
	determining whether the proposed registration duplicates existing		determining whether the proposed registration duplicates existing
	functionality, whether it is likely to be of general applicability or		functionality, whether it is likely to be of general applicability or
	whether it is useful only for a single application, and whether the		whether it is useful only for a single application, and whether the
	registration description is clear.		registration description is clear. Registrations for the limited set
			of values between -256 and 255 and strings of length 1 are to be
			restricted to claims with general applicability.
	It is suggested that multiple Designated Experts be appointed who are		It is suggested that multiple Designated Experts be appointed who are
	able to represent the perspectives of different applications using		able to represent the perspectives of different applications using
	this specification in order to enable broadly informed review of		this specification in order to enable broadly informed review of
	registration decisions. In cases where a registration decision could		registration decisions. In cases where a registration decision could
	be perceived as creating a conflict of interest for a particular		be perceived as creating a conflict of interest for a particular
	Expert, that Expert should defer to the judgment of the other		Expert, that Expert should defer to the judgment of the other
	Experts.		Experts.
	9.1.1. Registration Template		9.1.1. Registration Template
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 14 ¶
	JWT Claim Name:		JWT Claim Name:
	Claim Name of the equivalent JWT claim, as registered in		Claim Name of the equivalent JWT claim, as registered in
	[IANA.JWT.Claims]. CWT claims should normally have a		[IANA.JWT.Claims]. CWT claims should normally have a
	corresponding JWT claim. If a corresponding JWT claim would not		corresponding JWT claim. If a corresponding JWT claim would not
	make sense, the Designated Experts can choose to accept		make sense, the Designated Experts can choose to accept
	registrations for which the JWT Claim Name is listed as "N/A".		registrations for which the JWT Claim Name is listed as "N/A".
	Claim Key:		Claim Key:
	CBOR map key for the claim. Integer values between -256 and 255		CBOR map key for the claim. Integer values between -256 and 255
	and strings of length 1 are designated as Standards Track Document		and strings of length 1 are designated as Standards Track
	required. Integer values from -65536 to 65535 and strings of		Required. Integer values from -65536 to 65535 and strings of
	length 2 are designated as Specification Required. Integer values		length 2 are designated as Specification Required. Integer values
	of greater than 65535 and strings of length greater than 2 are		of greater than 65535 and strings of length greater than 2 are
	designated as expert review. Integer values less than -65536 are		designated as Expert Review. Integer values less than -65536 are
	marked as private use.		marked as Private Use.
	Claim Value Type(s):		Claim Value Type(s):
	CBOR types that can be used for the claim value.		CBOR types that can be used for the claim value.
	Change Controller:		Change Controller:
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party. Other details (e.g., postal		name of the responsible party. Other details (e.g., postal
	address, email address, home page URI) may also be included.		address, email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	skipping to change at page 14, line 24 ¶		skipping to change at page 14, line 24 ¶
	This section registers the CWT CBOR tag in the "CBOR Tags" registry		This section registers the CWT CBOR tag in the "CBOR Tags" registry
	[IANA.CBOR.Tags].		[IANA.CBOR.Tags].
	9.4.1. Registry Contents		9.4.1. Registry Contents
	o CBOR Tag: TBD (maybe 61 to use the same value as the Content-		o CBOR Tag: TBD (maybe 61 to use the same value as the Content-
	Format)		Format)
	o Data Item: CBOR Web Token (CWT)		o Data Item: CBOR Web Token (CWT)
	o Semantics: CBOR Web Token (CWT), as defined in [[ this		o Semantics: CBOR Web Token (CWT), as defined in [[ this
	specification ]]		specification ]]
	o Reference: [[ this specification ]]		o Description of Semantics: [[ this specification ]]
	o Point of Contact: Michael B. Jones, mbj@microsoft.com		o Point of Contact: Michael B. Jones, mbj@microsoft.com
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[IANA.CBOR.Tags]		[IANA.CBOR.Tags]
	IANA, "Concise Binary Object Representation (CBOR) Tags",		IANA, "Concise Binary Object Representation (CBOR) Tags",
	<http://www.iana.org/assignments/cbor-tags/		<http://www.iana.org/assignments/cbor-tags/
	cbor-tags.xhtml>.		cbor-tags.xhtml>.
	skipping to change at page 15, line 23 ¶		skipping to change at page 15, line 23 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[IANA.JWT.Claims]		[IANA.JWT.Claims]
	IANA, "JSON Web Token Claims",		IANA, "JSON Web Token Claims",
	<http://www.iana.org/assignments/jwt>.		<http://www.iana.org/assignments/jwt>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<https://www.rfc-editor.org/info/rfc6838>.		<https://www.rfc-editor.org/info/rfc6838>.
	[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, <https://www.rfc-editor.org/info/rfc7515>.		2015, <https://www.rfc-editor.org/info/rfc7515>.
	[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	RFC 7516, DOI 10.17487/RFC7516, May 2015,		RFC 7516, DOI 10.17487/RFC7516, May 2015,
	<https://www.rfc-editor.org/info/rfc7516>.		<https://www.rfc-editor.org/info/rfc7516>.
			[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>.
	Appendix A. Examples		Appendix A. Examples
	This appendix includes a set of CWT examples that show how the CWT		This appendix includes a set of CWT examples that show how the CWT
	Claims Set can be protected. There are examples that are signed,		Claims Set can be protected. There are examples that are signed,
	MACed, encrypted, and that use nested signing and encryption. To		MACed, encrypted, and that use nested signing and encryption. To
	make the examples easier to read, they are presented both as hex		make the examples easier to read, they are presented both as hex
	strings and in the extended CBOR diagnostic notation described in		strings and in the extended CBOR diagnostic notation described in
	Section 6 of [RFC7049].		Section 6 of [RFC7049].
	Where a byte string is to carry an embedded CBOR-encoded item, the		Where a byte string is to carry an embedded CBOR-encoded item, the
	skipping to change at page 22, line 31 ¶		skipping to change at page 22, line 31 ¶
	notation		notation
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	This specification is based on JSON Web Token (JWT) [RFC7519], the		This specification is based on JSON Web Token (JWT) [RFC7519], the
	authors of which also include Nat Sakimura and John Bradley. It also		authors of which also include Nat Sakimura and John Bradley. It also
	incorporates suggestions made by many people, including Carsten		incorporates suggestions made by many people, including Carsten
	Bormann, Esko Dijk, Benjamin Kaduk, Jim Schaad, Ludwig Seitz, and		Bormann, Esko Dijk, Benjamin Kaduk, Jim Schaad, Ludwig Seitz, and
	Goeran Selander.		Goeran Selander.
			[[ RFC Editor: Is it possible to preserve the non-ASCII spellings of
			the names Erik Wahlstroem and Goeran Selander in the final
			specification? ]]
	Appendix C. Document History		Appendix C. Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
			-12
			o Updated the RFC 5226 reference to RFC 8126.
			o Made the IANA registration criteria consistent across sections.
			o Stated that registrations for the limited set of values between
			-256 and 255 and strings of length 1 are to be restricted to
			claims with general applicability.
			o Changed the "Reference" field name to "Description of Semantics"
			in the CBOR Tag registration request.
			o Asked the RFC Editor whether it is possible to preserve the non-
			ASCII spellings of the names Erik Wahlstroem and Goeran Selander
			in the final specification.
	-11		-11
	o Corrected the "iv" value in the signed and encrypted CWT example.		o Corrected the "iv" value in the signed and encrypted CWT example.
	o Mention CoAP in the "application/cwt" media type registration.		o Mention CoAP in the "application/cwt" media type registration.
	o Changed references of the form "Section 4.1.1 of JWT <xref		o Changed references of the form "Section 4.1.1 of JWT <xref
	target="RFC7519"/>" to "Section 4.1.1 of <xref target="RFC7519"/>"		target="RFC7519"/>" to "Section 4.1.1 of <xref target="RFC7519"/>"
	so that rfcmarkup will generate correct external section reference		so that rfcmarkup will generate correct external section reference
	links.		links.
End of changes. 14 change blocks.
	25 lines changed or deleted		49 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/