< draft-ietf-stir-passport-rcd-16.txt		draft-ietf-stir-passport-rcd-17.txt >
	Network Working Group C. Wendt		Network Working Group C. Wendt
	Internet-Draft Somos Inc.		Internet-Draft Somos Inc.
	Intended status: Standards Track J. Peterson		Intended status: Standards Track J. Peterson
	Expires: 21 October 2022 Neustar Inc.		Expires: 26 October 2022 Neustar Inc.
	19 April 2022		24 April 2022
	PASSporT Extension for Rich Call Data		PASSporT Extension for Rich Call Data
	draft-ietf-stir-passport-rcd-16		draft-ietf-stir-passport-rcd-17
	Abstract		Abstract
	This document extends PASSporT, a token for conveying		This document extends PASSporT, a token for conveying
	cryptographically-signed call information about personal		cryptographically-signed call information about personal
	communications, to include rich meta-data about a call and caller		communications, to include rich meta-data about a call and caller
	that can be signed and integrity protected, transmitted, and		that can be signed and integrity protected, transmitted, and
	subsequently rendered to the called party. This framework is		subsequently rendered to the called party. This framework is
	intended to include and extend caller and call specific information		intended to include and extend caller and call specific information
	beyond human-readable display name comparable to the "Caller ID"		beyond human-readable display name comparable to the "Caller ID"
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 21 October 2022.		This Internet-Draft will expire on 26 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 28		17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 28
	17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 29		17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 29
	17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 29		17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 29
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 29		18. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	18.1. The use of JWT Claim Constraints in delegate certificates		18.1. The use of JWT Claim Constraints in delegate certificates
	to exclude unauthorized claims . . . . . . . . . . . . . 30		to exclude unauthorized claims . . . . . . . . . . . . . 30
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	19.1. Normative References . . . . . . . . . . . . . . . . . . 30		19.1. Normative References . . . . . . . . . . . . . . . . . . 30
	19.2. Informative References . . . . . . . . . . . . . . . . . 32		19.2. Informative References . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	PASSporT [RFC8225] is a token format based on JWT [RFC7519] for		PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
	conveying cryptographically-signed information about the parties		conveying cryptographically-signed information about the parties
	involved in personal communications; it is used to convey a signed		involved in personal communications; it is used to convey a signed
	assertion of the identity of the participants in real-time		assertion of the identity of the participants in real-time
	communications established via a protocol like SIP [RFC8224]. The		communications established via a protocol like SIP [RFC8224]. The
	STIR problem statement [RFC7340] declared securing the display name		STIR problem statement [RFC7340] declared securing the display name
	of callers outside of STIR's initial scope, so baseline STIR provides		of callers outside of STIR's initial scope, so baseline STIR provides
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	validated that it was received as intended by the signer of the		validated that it was received as intended by the signer of the
	PASSporT.		PASSporT.
	The third and fourth mode cover cases where there is a different		The third and fourth mode cover cases where there is a different
	authoritative entity responsible for the content of the RCD, separate		authoritative entity responsible for the content of the RCD, separate
	from the signer of the PASSporT itself, allowing the ability to have		from the signer of the PASSporT itself, allowing the ability to have
	forward control at the time of the creation of the certificate of the		forward control at the time of the creation of the certificate of the
	allowed or vetted content included in or referenced by the RCD claim		allowed or vetted content included in or referenced by the RCD claim
	contents. The primary framework for allowing the separation of		contents. The primary framework for allowing the separation of
	authority and the signing of PASSporTs by non-authorized entities is		authority and the signing of PASSporTs by non-authorized entities is
	detailed in [I-D.ietf-stir-cert-delegation] although other cases may		detailed in [RFC9060] although other cases may apply. As with the
	apply. As with the first and second modes, the third and fourth		first and second modes, the third and fourth modes differ with the
	modes differ with the absence or inclusion of externally referenced		absence or inclusion of externally referenced content using URIs.
	content using URIs.
	5. PASSporT Claim "rcd" Definition and Usage		5. PASSporT Claim "rcd" Definition and Usage
	5.1. PASSporT "rcd" Claim		5.1. PASSporT "rcd" Claim
	This specification defines a new JSON Web Token claim for "rcd", Rich		This specification defines a new JSON Web Token claim for "rcd", Rich
	Call Data, the value of which is a JSON object that can contain one		Call Data, the value of which is a JSON object that can contain one
	or more key value pairs. This document defines a default set of key		or more key value pairs. This document defines a default set of key
	values.		values.
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 43 ¶
	}		}
	The use of a JSON pointer and integrity digest for the "jcd" claim		The use of a JSON pointer and integrity digest for the "jcd" claim
	key and value is optional. The "jcd" value is the directly included		key and value is optional. The "jcd" value is the directly included
	jCard array and can be protected by the signature and can be		jCard array and can be protected by the signature and can be
	constrained directly with JWTClaimConstraints. However, for data		constrained directly with JWTClaimConstraints. However, for data
	length reasons (as with "icn" above) or more importantly for		length reasons (as with "icn" above) or more importantly for
	potential privacy and/or security considerations with a publically		potential privacy and/or security considerations with a publically
	accessible certificate this specification would recommend the use of		accessible certificate this specification would recommend the use of
	the "rcdi" JSON pointer and integrity digest as the contraint value		the "rcdi" JSON pointer and integrity digest as the contraint value
	in JWTClaimConstraints over the jCare data.		in JWTClaimConstraints over the jCard data.
	It is important to remember the array indexes for JSON Pointer are		It is important to remember the array indexes for JSON Pointer are
	dependent on the order of the elements in the jCard. The use of		dependent on the order of the elements in the jCard. The use of
	digest for the "/jcd" corresponding to the entire jCard array string		digest for the "/jcd" corresponding to the entire jCard array string
	can be included as a redundant mechanism to avoid any possibility of		can be included as a redundant mechanism to avoid any possibility of
	substitution, insertion attacks, or other potential techniques that		substitution, insertion attacks, or other potential techniques that
	may be possible to avoid integrity detection.		may be possible to avoid integrity detection.
	Each URI referenced in the jCard array string MUST have a		Each URI referenced in the jCard array string MUST have a
	corresponding JSON pointer string key and digest value.		corresponding JSON pointer string key and digest value.
	skipping to change at page 15, line 43 ¶		skipping to change at page 15, line 43 ¶
	and any linked content is certified by the party that is		and any linked content is certified by the party that is
	authoritative for the certificate being created and the construction		authoritative for the certificate being created and the construction
	of the "rcdi" claim is complete, the "rcdi" claim is linked to the		of the "rcdi" claim is complete, the "rcdi" claim is linked to the
	STIR certificate associated with the signature in the PASSporT via		STIR certificate associated with the signature in the PASSporT via
	JWT Claim Constraints extension as defined in [RFC8226] Section 8.		JWT Claim Constraints extension as defined in [RFC8226] Section 8.
	It should be recognized that the "rcdi" set of digests is intended to		It should be recognized that the "rcdi" set of digests is intended to
	be unique for only a specific combination of "rcd" content and URI		be unique for only a specific combination of "rcd" content and URI
	referenced external content, and therefore provides a robust		referenced external content, and therefore provides a robust
	integrity mechanism for an authentication service being performed by		integrity mechanism for an authentication service being performed by
	a non-authoritative party. This would often be associated with the		a non-authoritative party. This would often be associated with the
	use of delegate certificates [I-D.ietf-stir-cert-delegation] for the		use of delegate certificates [RFC9060] for the signing of calls by
	signing of calls by the calling party directly as an example, even		the calling party directly as an example, even though the "authorized
	though the "authorized party" is not necessarily the subject of a		party" is not necessarily the subject of a STIR certificate.
	STIR certificate.
	For the case that there should always be both "rcd" and "rcdi" values		For the case that there should always be both "rcd" and "rcdi" values
	included in the "rcd" PASSporT, the certificate JWT Claims Constraint		included in the "rcd" PASSporT, the certificate JWT Claims Constraint
	extension MUST include both of the following:		extension MUST include both of the following:
	* a "mustInclude" for the "rcd" claim, which simply constrains the		* a "mustInclude" for the "rcd" claim, which simply constrains the
	fact that an "rcd" must be included		fact that an "rcd" must be included
	* a "mustInclude" for the "rcdi" claim and a "permittedValues" equal		* a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
	to the created "rcdi" claim value string.		to the created "rcdi" claim value string.
	skipping to change at page 20, line 36 ¶		skipping to change at page 20, line 36 ¶
	"crn": "Rendezvous for Little Nellie",		"crn": "Rendezvous for Little Nellie",
	"orig": {"tn": "12025551000"},		"orig": {"tn": "12025551000"},
	"dest": {"tn": ["12155551001"]},		"dest": {"tn": ["12155551001"]},
	"iat": 1443208345,		"iat": 1443208345,
	"rcd": {		"rcd": {
	"nam": "Q Branch Spy Gadgets",		"nam": "Q Branch Spy Gadgets",
	"icn": "https://example.com/photos/q-256x256.png"		"icn": "https://example.com/photos/q-256x256.png"
	},		},
	"rcdi": {		"rcdi": {
	"/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",		"/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
	"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",		"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
	}		}
	}		}
	10. Compact form of "rcd" PASSporT		10. Compact form of "rcd" PASSporT
	10.1. Compact form of the "rcd" PASSporT claim		10.1. Compact form of the "rcd" PASSporT claim
	Compact form of an "rcd" PASSporT claim has some restrictions that		Compact form of an "rcd" PASSporT claim has some restrictions that
	will be enumerated below, but mainly follows standard PASSporT		will be enumerated below, but mainly follows standard PASSporT
	compact form procedures. For re-construction of the "nam" claim the		compact form procedures. For re-construction of the "nam" claim the
	skipping to change at page 22, line 35 ¶		skipping to change at page 22, line 35 ¶
	for a call.		for a call.
	In telephone operations today, a third-party information service is		In telephone operations today, a third-party information service is
	commonly queried with the calling party's number in order to learn		commonly queried with the calling party's number in order to learn
	the name of the calling party, and potentially other helpful		the name of the calling party, and potentially other helpful
	information could also be passed over that interface. The value of		information could also be passed over that interface. The value of
	using a PASSporT to convey this information from third parties lies		using a PASSporT to convey this information from third parties lies
	largely in the preservation of the third party's signature over the		largely in the preservation of the third party's signature over the
	data, and the potential for the PASSporT to be conveyed from		data, and the potential for the PASSporT to be conveyed from
	intermediaries to endpoint devices. Effectively, these use cases		intermediaries to endpoint devices. Effectively, these use cases
	form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The		form a sub-case of out-of-band [RFC8816] use cases. The manner in
	manner in which third-party services are discovered is outside the		which third-party services are discovered is outside the scope of
	scope of this document.		this document.
	An intermediary use case might look as follows: a SIP INVITE carries		An intermediary use case might look as follows: a SIP INVITE carries
	a display name in its From header field value and an initial PASSporT		a display name in its From header field value and an initial PASSporT
	object without the "rcd" claim. When a terminating verification		object without the "rcd" claim. When a terminating verification
	service implemented at a SIP proxy server receives this request, and		service implemented at a SIP proxy server receives this request, and
	determines that the signature is valid, it might query a third-party		determines that the signature is valid, it might query a third-party
	service that maps telephone numbers to calling party names. Upon		service that maps telephone numbers to calling party names. Upon
	receiving the PASSport in a response from that third-party service,		receiving the PASSport in a response from that third-party service,
	the terminating side could add a new Identity header field to the		the terminating side could add a new Identity header field to the
	request for the "rcd" PASSporT object provided by the third-party		request for the "rcd" PASSporT object provided by the third-party
	skipping to change at page 26, line 50 ¶		skipping to change at page 26, line 50 ¶
	example, is often data that is additive to the personal		example, is often data that is additive to the personal
	communications information defined in the core PASSporT data required		communications information defined in the core PASSporT data required
	to support the security properties defined in [RFC8225]. For cases		to support the security properties defined in [RFC8225]. For cases
	where the entity originating the personal communications is		where the entity originating the personal communications is
	supporting the authentication service for the calling identity and is		supporting the authentication service for the calling identity and is
	the authority of the Rich Call Data, rather than creating multiple		the authority of the Rich Call Data, rather than creating multiple
	Identity header fields cooresponding to multiple PASSporT extensions,		Identity header fields cooresponding to multiple PASSporT extensions,
	the authentication service can alternatively directly add the "rcd"		the authentication service can alternatively directly add the "rcd"
	claim to a PASSporT that authenticates the calling identity.		claim to a PASSporT that authenticates the calling identity.
	It is critically important for the user of this specification to		Note: There is one very important caveat to this capability, because
	recognize that the certificates used must include the necessary JWT		generally if there is URI referenced content in an "rcd" PASSporT
	Claims Constraints and permitted values for proper integrity and		there is often the requirement to use "rcdi" and JWT Claims
	security of the values in the "rcd" claim incorporated into PASSporTs		Constraints. So, it is important for the user of this specification
	that are not "rcd". The verifier of "rcd" claims MUST recognize if		to recognize that the certificates used should include the necessary
	the signing certificate contains no claim constraints for direct		JWT Claims Constraints for proper integrity and security of the
	values or referenced content that they should have some sort of		values in the "rcd" claim incorporated into PASSporTs that are not
	"trust" relationship with the signer of the PASSPorT that can vouch		"rcd".
	for or have an understanding of how the rich call data was properly
	vetted. An example scenario that demonstrates this might be when an
	"rcd" PASSporT with information that was properly vetted, integrity
	protected and constrained and is transferred by a middle party to
	another PASSporT and signed by that party without that integrity
	protection and constraints provided in the certificate. These
	scenarios lose the end-to-end trust and integrity required by this
	specification. However, it is recognized that some UNI or provider
	to device scenarios where there is an authenticated "trust"
	relationship MAY warrant the technique described in this section.
	15.1. Procedures for applying "rcd" as claims only		15.1. Procedures for applying "rcd" as claims only
	For a given PASSporT using some other extension than "rcd", the		For a given PASSporT using some other extension than "rcd", the
	Authentication Service MAY additionally include the "rcd" claim as		Authentication Service MAY additionally include the "rcd" claim as
	defined in this document. This would result in a set of claims that		defined in this document. This would result in a set of claims that
	correspond to the original intended extension with the addition of		correspond to the original intended extension with the addition of
	the "rcd" claim.		the "rcd" claim.
	The Verification service that receives the PASSporT, if it supports		The Verification service that receives the PASSporT, if it supports
	this specification and chooses to, should interpret the "rcd" claim		this specification and chooses to, should interpret the "rcd" claim
	as simply just an additional claim intended to deliver and/or		as simply just an additional claim intended to deliver and/or
	validate delivered Rich Call Data.		validate delivered Rich Call Data.
	15.2. Example for applying "rcd" as claims only		15.2. Example for applying "rcd" as claims only
	In the case of [RFC8588] which is the PASSporT extension supporting		In the case of [RFC8588] which is the PASSporT extension supporting
	the SHAKEN specification [ATIS-1000074], a common case for an		the SHAKEN specification [ATIS-1000074.v002], a common case for an
	Authentication service to co-exist in a CSP network along with the		Authentication service to co-exist in a CSP network along with the
	authority over the calling name used for the call. Rather than		authority over the calling name used for the call. Rather than
	require two identity headers, the CSP Authentication Service can		require two identity headers, the CSP Authentication Service can
	apply both the SHAKEN PASSporT claims and extension and simply add		apply both the SHAKEN PASSporT claims and extension and simply add
	the "rcd" required claims defined in this document.		the "rcd" required claims defined in this document.
	For example, the PASSporT claims for the "shaken" PASSporT with "rcd"		For example, the PASSporT claims for the "shaken" PASSporT with "rcd"
	claims would be as follows:		claims would be as follows:
	Protected Header		Protected Header
	skipping to change at page 30, line 32 ¶		skipping to change at page 30, line 19 ¶
	verification services or that doesn't follow the behavior defined in		verification services or that doesn't follow the behavior defined in
	this document, e.g., unreasonably sized data, the inclusion of		this document, e.g., unreasonably sized data, the inclusion of
	recursive URI references, etc. Along the same lines, the		recursive URI references, etc. Along the same lines, the
	verification service should also use precautionary best practices to		verification service should also use precautionary best practices to
	avoid attacks when accessing URI linked content.		avoid attacks when accessing URI linked content.
	18.1. The use of JWT Claim Constraints in delegate certificates to		18.1. The use of JWT Claim Constraints in delegate certificates to
	exclude unauthorized claims		exclude unauthorized claims
	While this can apply to any PASSporT that is signed with a STIR		While this can apply to any PASSporT that is signed with a STIR
	Delegate Certificates [I-D.ietf-stir-cert-delegation], it is		Delegate Certificates [RFC9060], it is important to note that when
	important to note that when constraining PASSporTs to include		constraining PASSporTs to include specific claims or contents of
	specific claims or contents of claims, it is also important to		claims, it is also important to consider potential attacks by non-
	consider potential attacks by non-authorized signers that may include		authorized signers that may include other potential PASSporT claims
	other potential PASSporT claims that weren't originally vetted by the		that weren't originally vetted by the authorized entity providing the
	authorized entity providing the delegate certificate. The use of JWT		delegate certificate. The use of JWT claims constraints as defined
	claims constraints as defined in [RFC9118] for preventing the ability		in [RFC9118] for preventing the ability to include claims beyond the
	to include claims beyond the claims defined in this document may need		claims defined in this document may need to be considered.
	to be considered.
	Certificate issuers SHOULD NOT include an entry in mustExclude for		Certificate issuers SHOULD NOT include an entry in mustExclude for
	the "rcdi" claim for a certificate that will be used with the		the "rcdi" claim for a certificate that will be used with the
	PASSporT Extension for Rich Call Data defined in this document.		PASSporT Extension for Rich Call Data defined in this document.
	Excluding this claim would prevent the integrity protection mechanism		Excluding this claim would prevent the integrity protection mechanism
	from working properly.		from working properly.
	19. References		19. References
	19.1. Normative References		19.1. Normative References
	[I-D.ietf-sipcore-callinfo-rcd]		[I-D.ietf-sipcore-callinfo-rcd]
	Wendt, C. and J. Peterson, "SIP Call-Info Parameters for		Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
	Rich Call Data", Work in Progress, Internet-Draft, draft-		Rich Call Data", Work in Progress, Internet-Draft, draft-
	ietf-sipcore-callinfo-rcd-04, 7 March 2022,		ietf-sipcore-callinfo-rcd-04, 7 March 2022,
	<https://www.ietf.org/archive/id/draft-ietf-sipcore-		<https://www.ietf.org/archive/id/draft-ietf-sipcore-
	callinfo-rcd-04.txt>.		callinfo-rcd-04.txt>.
	[I-D.ietf-stir-cert-delegation]
	Peterson, J., "Secure Telephone Identity Revisited (STIR)
	Certificate Delegation", Work in Progress, Internet-Draft,
	draft-ietf-stir-cert-delegation-04, 22 February 2021,
	<https://www.ietf.org/archive/id/draft-ietf-stir-cert-
	delegation-04.txt>.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	skipping to change at page 32, line 39 ¶		skipping to change at page 32, line 20 ¶
	Credentials: Certificates", RFC 8226,		Credentials: Certificates", RFC 8226,
	DOI 10.17487/RFC8226, February 2018,		DOI 10.17487/RFC8226, February 2018,
	<https://www.rfc-editor.org/info/rfc8226>.		<https://www.rfc-editor.org/info/rfc8226>.
	[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token		[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
	(PaSSporT) Extension for Signature-based Handling of		(PaSSporT) Extension for Signature-based Handling of
	Asserted information using toKENs (SHAKEN)", RFC 8588,		Asserted information using toKENs (SHAKEN)", RFC 8588,
	DOI 10.17487/RFC8588, May 2019,		DOI 10.17487/RFC8588, May 2019,
	<https://www.rfc-editor.org/info/rfc8588>.		<https://www.rfc-editor.org/info/rfc8588>.
			[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
			Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
			September 2021, <https://www.rfc-editor.org/info/rfc9060>.
	[RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim		[RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim
	Constraints for Secure Telephone Identity Revisited (STIR)		Constraints for Secure Telephone Identity Revisited (STIR)
	Certificates", RFC 9118, DOI 10.17487/RFC9118, August		Certificates", RFC 9118, DOI 10.17487/RFC9118, August
	2021, <https://www.rfc-editor.org/info/rfc9118>.		2021, <https://www.rfc-editor.org/info/rfc9118>.
	19.2. Informative References		19.2. Informative References
	[ATIS-1000074]		[ATIS-1000074.v002]
	ATIS/SIP Forum NNI Task Group, "Signature-based Handling		ATIS/SIP Forum NNI Task Group, "Signature-based Handling
	of Asserted information using toKENs (SHAKEN)		of Asserted information using toKENs (SHAKEN)
	<https://access.atis.org/apps/group_public/		<https://access.atis.org/apps/group_public/
	download.php/32237/ATIS-1000074.pdf>", January 2017.		download.php/62391/ATIS-1000074.v002.pdf>", November 2021.
	[I-D.ietf-stir-oob]		[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
	Rescorla, E. and J. Peterson, "Secure Telephone Identity
	Revisited (STIR) Out-of-Band Architecture and Use Cases",		Revisited (STIR) Out-of-Band Architecture and Use Cases",
	Work in Progress, Internet-Draft, draft-ietf-stir-oob-07,		RFC 8816, DOI 10.17487/RFC8816, February 2021,
	9 March 2020, <https://www.ietf.org/archive/id/draft-ietf-		<https://www.rfc-editor.org/info/rfc8816>.
	stir-oob-07.txt>.
	Authors' Addresses		Authors' Addresses
	Chris Wendt		Chris Wendt
	Somos Inc.		Somos Inc.
	Email: chris-ietf@chriswendt.net		Email: chris-ietf@chriswendt.net
	Jon Peterson		Jon Peterson
	Neustar Inc.		Neustar Inc.
	Email: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
End of changes. 18 change blocks.
	60 lines changed or deleted		42 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/