rfc9448.original		rfc9448.txt
	Network Working Group C. Wendt		Internet Engineering Task Force (IETF) C. Wendt
	Internet-Draft Somos Inc.		Request for Comments: 9448 D. Hancock
	Intended status: Standards Track D. Hancock		Category: Standards Track Somos Inc.
	Expires: 11 August 2023 Comcast		ISSN: 2070-1721 M. Barnes
	M. Barnes
	J. Peterson		J. Peterson
	Neustar Inc.		Neustar Inc.
	7 February 2023		September 2023
	TNAuthList profile of ACME Authority Token		TNAuthList Profile of Automated Certificate Management Environment
	draft-ietf-acme-authority-token-tnauthlist-13		(ACME) Authority Token
	Abstract		Abstract
	This document defines a profile of the Automated Certificate		This document defines a profile of the Automated Certificate
	Management Environment (ACME) Authority Token for the automated and		Management Environment (ACME) Authority Token for the automated and
	authorized creation of certificates for VoIP Telephone Providers to		authorized creation of certificates for Voice over IP (VoIP)
	support Secure Telephony Identity (STI) using the TNAuthList defined		telephone providers to support Secure Telephone Identity (STI) using
	by STI certificates.		the TNAuthList defined by STI certificates.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 11 August 2023.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9448.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language
	3. ACME new-order identifiers for TNAuthList . . . . . . . . . . 3		3. ACME New-Order Identifiers for TNAuthList
	4. TNAuthList Identifier Authorization . . . . . . . . . . . . . 5		4. TNAuthList Identifier Authorization
	5. TNAuthList Authority Token . . . . . . . . . . . . . . . . . 7		5. TNAuthList Authority Token
	5.1. "iss" claim . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. "iss" Claim
	5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7		5.2. "exp" Claim
	5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 7		5.3. "jti" Claim
	5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 7		5.4. "atc" Claim
	5.5. Acquiring the token from the Token Authority . . . . . . 8		5.5. Acquiring the Token from the Token Authority
	5.6. Token Authority Responsibilities . . . . . . . . . . . . 10		5.6. Token Authority Responsibilities
	5.7. Scope of the TNAuthList . . . . . . . . . . . . . . . . . 10		5.7. Scope of the TNAuthList
	6. Validating the TNAuthList Authority Token . . . . . . . . . . 10		6. Validating the TNAuthList Authority Token
	7. Using ACME-issued Certificates with JSON Web Signature . . . 11		7. Using ACME-Issued Certificates with JSON Web Signature
	8. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13		8. Usage Considerations
	8.1. Large number of Non-contiguous TNAuthList values . . . . 13		8.1. Large Number of Noncontiguous TNAuthList Values
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		10. Security Considerations
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		11. References
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11.1. Normative References
	12.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.2. Informative References
	12.2. Informative References . . . . . . . . . . . . . . . . . 16		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses
	1. Introduction		1. Introduction
	[RFC8555] is a mechanism for automating certificate management on the		[RFC8555] describes a mechanism for automating certificate management
	Internet. It enables administrative entities to prove effective		on the Internet. It enables administrative entities to prove
	control over resources like domain names, and automates the process		effective control over resources like domain names, and it automates
	of generating and issuing certificates.		the process of generating and issuing certificates. [RFC9447]
	[I-D.ietf-acme-authority-token] extends ACME to provide a general		extends ACME to provide a general method of extending the authority
	method of extending the authority and authorization of entities to		and authorization of entities to control a resource via a third party
	control a resource via a third party Token Authority beyond the		Token Authority beyond the certification authority (CA).
	Certification Authority (CA).
	This document is a profile document using the Authority Token		This document is a profile document using the Authority Token
	mechanism defined in [I-D.ietf-acme-authority-token]. It is a		mechanism defined in [RFC9447]. It is a profile that specifically
	profile that specifically addresses the STIR problem statement		addresses the Secure Telephone Identity Revisited (STIR) problem
	[RFC7340] which identifies the need for Internet credentials that can		statement described in [RFC7340], which identifies the need for
	attest authority for the originator of VoIP calls in order to detect		Internet credentials that can attest authority for the originator of
	impersonation, which is currently an enabler for common attacks		VoIP calls in order to detect impersonation, which is currently an
	associated with illegal robocalling, voicemail hacking, and swatting.		enabler for common attacks associated with illegal robocalling,
			voicemail hacking, and swatting. These credentials are used to sign
	These credentials are used to sign PASSporTs [RFC8225], which can be		Personal Assertion Tokens (PASSporTs) [RFC8225], which can be carried
	carried in using protocols such as SIP [RFC8224]. Currently, the		in using protocols such as SIP [RFC8224]. Currently, the only
	only defined credentials for this purpose are the certificates		defined credentials for this purpose are the certificates specified
	specified in [RFC8226] using the TNAuthList. This document defines		in [RFC8226] using the TNAuthList. This document defines the use of
	the use of the TNAuthList Authority Token in the ACME challenge to		the TNAuthList Authority Token in the ACME challenge to prove the
	proof the authoritative use of the contents of the TNAuthList,		authoritative use of the contents of the TNAuthList, including a
	including a Service Provider Token (SPC), a Telephone Number, or a		Service Provider Code (SPC), a telephone number, or a set of
	set of telephone numbers or telephone number blocks.		telephone numbers or telephone number blocks.
	This document also describes the ability for a telephone authority to		This document also describes the ability for a telephone authority to
	authorize the creation of CA types of certificates for delegation as		authorize the creation of CA types of certificates for delegation, as
	defined in [RFC9060].		defined in [RFC9060].
	2. Terminology		2. Requirements Language
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. ACME new-order identifiers for TNAuthList		3. ACME New-Order Identifiers for TNAuthList
	In [RFC8555], Section 7 defines the procedure that an ACME client		Section 7 of [RFC8555] defines the procedure that an ACME client uses
	uses to order a new certificate from a CA. The new-order request		to order a new certificate from a CA. The new-order request contains
	contains an identifier field that specifies the identifier objects		an identifier field that specifies the identifier objects the order
	the order corresponds to. This draft defines a new type of		corresponds to. This document defines a new type of identifier
	identifier object called TNAuthList. A TNAuthList identifier		object called TNAuthList. A TNAuthList identifier contains the
	contains the identity information to be populated in the TN		identity information to be populated in the TNAuthList of the new
	Authorization List of the new certificate. For the TNAuthList		certificate. For the TNAuthList identifier, the new-order request
	identifier, the new-order request includes a type set to the string		includes a type set to the string "TNAuthList". The value of the
	"TNAuthList". The value of the TNAuthList identifier MUST be set to		TNAuthList identifier MUST be set to the details of the TNAuthList
	the details of the TNAuthList requested.		requested.
	The format of the string that represents the TNAuthList MUST be		The string that represents the TNAuthList MUST be constructed using
	constructed using base64url encoding, as per [RFC8555] base64url		base64url encoding, as described in Section 5 of [RFC4648] and as
	encoding described in Section 5 of [RFC4648] according to the profile		defined in Section 2 of JSON Web Signature [RFC7515]. The base64url
	specified in JSON Web Signature in Section 2 of [RFC7515]. The		encoding MUST NOT include any padding characters, and the TNAuthList
	base64url encoding MUST NOT include any padding characters and the		ASN.1 object MUST be encoded using DER encoding rules.
	TNAuthList ASN.1 object MUST encoded using DER encoding rules.
	An example of an ACME order object “identifiers” field containing a		An example of an ACME order object "identifiers" field containing a
	TNAuthList certificate would look as follows,		TNAuthList certificate is as follows:
	"identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]		"identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]
	where the "value" object string represents the arbitrary length		where the "value" object string represents the arbitrary length of
	base64url encoded string.		the base64url-encoded string.
	A full new-order request would look as follows,		A full new-order request would look as follows:
	POST /acme/new-order HTTP/1.1		POST /acme/new-order HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "5XJ1L3lEkMG7tR6pA00clA",		"nonce": "5XJ1L3lEkMG7tR6pA00clA",
	skipping to change at page 4, line 27 ¶		skipping to change at line 164 ¶
	}),		}),
	"payload": base64url({		"payload": base64url({
	"identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}],		"identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}],
	"notBefore": "2021-01-01T00:00:00Z",		"notBefore": "2021-01-01T00:00:00Z",
	"notAfter": "2021-01-08T00:00:00Z"		"notAfter": "2021-01-08T00:00:00Z"
	}),		}),
	"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"		"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
	}		}
	On receiving a valid new-order request, the ACME server creates an		On receiving a valid new-order request, the ACME server creates an
	authorization object, [RFC8555] Section 7.1.4, containing the		authorization object ([RFC8555], Section 7.1.4), containing the
	challenge that the ACME client must satisfy to demonstrate authority		challenge that the ACME client must satisfy to demonstrate authority
	for the identifiers specified by the new order (in this case, the		for the identifiers specified by the new order (in this case, the
	TNAuthList identifier). The CA adds the authorization object URL to		TNAuthList identifier). The CA adds the authorization object URL to
	the "authorizations" field of the order object, and returns the order		the "authorizations" field of the order object and returns the order
	object to the ACME client in the body of a 201 (Created) response.		object to the ACME client in the body of a 201 (Created) response.
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	Content-Type: application/json		Content-Type: application/json
	Replay-Nonce: MYAuvOpaoIiywTezizk5vw		Replay-Nonce: MYAuvOpaoIiywTezizk5vw
	Location: https://example.com/acme/order/1234		Location: https://example.com/acme/order/1234
	{		{
	"status": "pending",		"status": "pending",
	"expires": "2022-01-08T00:00:00Z",		"expires": "2022-01-08T00:00:00Z",
	skipping to change at page 5, line 9 ¶		skipping to change at line 195 ¶
	"authorizations": [		"authorizations": [
	"https://example.com/acme/authz/1234"		"https://example.com/acme/authz/1234"
	],		],
	"finalize": "https://example.com/acme/order/1234/finalize"		"finalize": "https://example.com/acme/order/1234/finalize"
	}		}
	4. TNAuthList Identifier Authorization		4. TNAuthList Identifier Authorization
	On receiving the new-order response, the ACME client queries the		On receiving the new-order response, the ACME client queries the
	referenced authorization object to obtain the challenges for the		referenced authorization object to obtain the challenges for the
	identifier contained in the new-order request as shown in the		identifier contained in the new-order request, as shown in the
	following example request and response.		following example request and response.
	POST /acme/authz/1234 HTTP/1.1		POST /acme/authz/1234 HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": " https://example.com/acme/acct/evOfKhNU60wg",		"kid": " https://example.com/acme/acct/evOfKhNU60wg",
	skipping to change at page 6, line 4 ¶		skipping to change at line 236 ¶
	"challenges": [		"challenges": [
	{		{
	"type": "tkauth-01",		"type": "tkauth-01",
	"tkauth-type": "atc",		"tkauth-type": "atc",
	"token-authority": "https://authority.example.org",		"token-authority": "https://authority.example.org",
	"url": "https://example.com/acme/chall/prV_B7yEyA4",		"url": "https://example.com/acme/chall/prV_B7yEyA4",
	"token": "IlirfxKKXAsHtmzK29Pj8A"		"token": "IlirfxKKXAsHtmzK29Pj8A"
	}		}
	]		]
	}		}
	When processing a certificate order containing an identifier of type		When processing a certificate order containing an identifier of type
	"TNAuthList", a CA uses the Authority Token challenge type of		"TNAuthList", a CA uses the Authority Token challenge type of
	"tkauth-01" with a "tkauth-type" of "atc" in		"tkauth-01" with a "tkauth-type" of "atc" in [RFC9447] to verify that
	[I-D.ietf-acme-authority-token] to verify that the requesting ACME		the requesting ACME client has authenticated and authorized control
	client has authenticated and authorized control over the requested		over the requested resources represented by the "TNAuthList" value.
	resources represented by the "TNAuthList" value.
	The challenge "token-authority" parameter is only used in cases where		The challenge "token-authority" parameter is only used in cases where
	the VoIP telephone network requires the CA to identify the Token		the VoIP telephone network requires the CA to identify the Token
	Authority. This is currently not the case for the SHAKEN		Authority. This is currently not the case for the Signature-based
	[ATIS-1000080] certificate framework governance, but may be used by		Handling of Asserted information using toKENs (SHAKEN) [ATIS-1000080]
	other frameworks. If a "token-authority" parameter is present, then		certificate framework governance but may be used by other frameworks.
	the ACME client MAY use the "token-authority" value to identify the		If a "token-authority" parameter is present, then the ACME client MAY
	URL representing the Token Authority that will provide the TNAuthList		use the "token-authority" value to identify the URL representing the
	Authority Token response to the challenge. If the "token-authority"		Token Authority that will provide the TNAuthList Authority Token
	parameter is not present, then the ACME client MUST identify the		response to the challenge. If the "token-authority" parameter is not
	Token Authority based on locally configured information or local		present, then the ACME client MUST identify the Token Authority based
	policies.		on locally configured information or local policies.
	The ACME client responds to the challenge by posting the TNAuthList		The ACME client responds to the challenge by posting the TNAuthList
	Authority Token to the challenge URL identified in the returned ACME		Authority Token to the challenge URL identified in the returned ACME
	authorization object, an example of which follows.		authorization object, an example of which follows:
	POST /acme/chall/prV_B7yEyA4 HTTP/1.1		POST /acme/chall/prV_B7yEyA4 HTTP/1.1
	Host: boulder.example.com		Host: boulder.example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "Q_s3MWoqT05TrdkM2MTDcw",		"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
	skipping to change at page 7, line 7 ¶		skipping to change at line 282 ¶
	}),		}),
	"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"		"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
	}		}
	The "tkauth" field is defined as a new field in the challenge object		The "tkauth" field is defined as a new field in the challenge object
	specific to the tkauth-01 challenge type that should contain the		specific to the tkauth-01 challenge type that should contain the
	TNAuthList Authority Token defined in the next section.		TNAuthList Authority Token defined in the next section.
	5. TNAuthList Authority Token		5. TNAuthList Authority Token
	The Telephone Number Authority List Authority Token (TNAuthList		The TNAuthList Authority Token is a profile instance of the ACME
	Authority Token) is a profile instance of the ACME Authority Token		Authority Token defined in [RFC9447].
	defined in [I-D.ietf-acme-authority-token].
	The TNAuthList Authority Token Protected header MUST comply with the		The TNAuthList Authority Token protected header MUST comply with
	Authority Token Protected header as defined in		"Request Authentication" (Section 6.2 of [RFC8555]).
	[I-D.ietf-acme-authority-token].
	The TNAuthList Authority Token Payload MUST include the mandatory		The TNAuthList Authority Token Payload MUST include the mandatory
	claims "exp", "jti", and "atc", and MAY include the optional claims		claims "exp", "jti", and "atc" and MAY include the optional claims
	defined for the Authority Token detailed in the next subsections.		defined for the Authority Token detailed in the next subsections.
	5.1. "iss" claim		5.1. "iss" Claim
	The "iss" claim is an optional claim defined in [RFC7519]		The "iss" claim is an optional claim defined in [RFC7519],
	Section 4.1.1. It can be used as a URL identifying the Token		Section 4.1.1. It can be used as a URL identifying the Token
	Authority that issued the TNAuthList Authority Token beyond the "x5u"		Authority that issued the TNAuthList Authority Token beyond the "x5u"
	or other Header claims that identify the location of the certificate		or other header claims that identify the location of the certificate
	or certificate chain of the Token Authority used to validate the		or certificate chain of the Token Authority used to validate the
	TNAuthList Authority Token.		TNAuthList Authority Token.
	5.2. "exp" claim		5.2. "exp" Claim
	The "exp" claim, defined in [RFC7519] Section 4.1.4, MUST be included		The "exp" claim, defined in [RFC7519], Section 4.1.4, MUST be
	and contains the DateTime value of the ending date and time that the		included and contains the DateTime value of the ending date and time
	TNAuthList Authority Token expires.		that the TNAuthList Authority Token expires.
	5.3. "jti" claim		5.3. "jti" Claim
	The "jti" claim, defined in [RFC7519] Section 4.1.7, MUST be included		The "jti" claim, defined in [RFC7519], Section 4.1.7, MUST be
	and contains a unique identifier for this TNAuthList Authority Token		included and contains a unique identifier for this TNAuthList
	transaction.		Authority Token transaction.
	5.4. "atc" claim		5.4. "atc" Claim
	The "atc" claim MUST be included and is defined in		The "atc" claim MUST be included and is defined in [RFC9447]. It
	[I-D.ietf-acme-authority-token]. It contains a JSON object with the		contains a JSON object with the following elements:
	following elements:
	* a "tktype" key with a string value equal to "TNAuthList" to		* a "tktype" key with a string value equal to "TNAuthList" to
	represent a TNAuthList profile of the authority token		represent a TNAuthList profile of the Authority Token [RFC9447]
	[I-D.ietf-acme-authority-token] defined by this document. "tktype"		defined by this document. "tktype" is a required key and MUST be
	is a required key and MUST be included.		included.
	* a "tkvalue" key with a string value equal to the base64url		* a "tkvalue" key with a string value equal to the base64url
	encoding of the TN Authorization List certificate extension ASN.1		encoding of the TNAuthList certificate extension ASN.1 object
	object using DER encoding rules. "tkvalue" is a required key and		using DER encoding rules. "tkvalue" is a required key and MUST be
	MUST be included.		included.
	* a "ca" key with a boolean value set to either true when the		* a "ca" key with a boolean value set to either true when the
	requested certificate is allowed to be a CA cert for delegation		requested certificate is allowed to be a CA cert for delegation
	uses or false when the requested certificate is not intended to be		uses or false when the requested certificate is not intended to be
	a CA cert, only an end-entity certificate. "ca" is an optional		a CA cert, only an end-entity certificate. "ca" is an optional
	key, if not included the "ca" value is considered false by		key; if not included, the "ca" value is considered false by
	default.		default.
	* a "fingerprint" key is constructed as defined in [RFC8555]		* a "fingerprint" key constructed as defined in [RFC8555],
	Section 8.1 corresponding to the computation of the "Thumbprint"		Section 8.1, corresponding to the computation of the "Thumbprint"
	step using the ACME account key credentials. "fingerprint" is a		step using the ACME account key credentials. "fingerprint" is a
	required key and MUST be included.		required key and MUST be included.
	An example of the TNAuthList Authority Token is as follows:		An example of the TNAuthList Authority Token is as follows:
	{		{
	"protected": base64url({		"protected": base64url({
	"typ":"JWT",		"typ":"JWT",
	"alg":"ES256",		"alg":"ES256",
	"x5u":"https://authority.example.org/cert"		"x5u":"https://authority.example.org/cert"
	skipping to change at page 8, line 43 ¶		skipping to change at line 361 ¶
	"jti":"id6098364921",		"jti":"id6098364921",
	"atc":{"tktype":"TNAuthList",		"atc":{"tktype":"TNAuthList",
	"tkvalue":"F83n2a...avn27DN3",		"tkvalue":"F83n2a...avn27DN3",
	"ca":false,		"ca":false,
	"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:		"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:
	D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}		D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
	}),		}),
	"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"		"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
	}		}
	5.5. Acquiring the token from the Token Authority		5.5. Acquiring the Token from the Token Authority
	Following [I-D.ietf-acme-authority-token] Section 5, the authority		Following [RFC9447], Section 5, the Authority Token should be
	token should be acquired using a RESTful HTTP POST transaction as		acquired using a RESTful HTTP POST transaction as follows:
	follows:
	POST /at/account/:id/token HTTP/1.1		POST /at/account/:id/token HTTP/1.1
	Host: authority.example.org		Host: authority.example.org
	Content-Type: application/json		Content-Type: application/json
	The request will pass the account id as a string in the request		The request will pass the account identifier as a string in the
	parameter "id". This string will be managed as an identifier		request parameter "id". This string will be managed as an identifier
	specific to the Token Authority's relationship with a communications		specific to the Token Authority's relationship with a Communications
	service provider (CSP). There is assumed to also be a corresponding		Service Provider (CSP). There is assumed to also be a corresponding
	authentication procedure that can be verified for the success of this		authentication procedure that can be verified for the success of this
	transaction. For example, an HTTP authorization header containing a		transaction, for example, an HTTP authorization header containing
	valid authorization credentials as defined in [RFC7231] Section 14.8.		valid authorization credentials, as defined in [RFC9110],
			Section 11.6.2.
	The body of the POST request MUST contain a JSON object with key		The body of the POST request MUST contain a JSON object with key
	value pairs corresponding to values that are requested as the content		value pairs corresponding to values that are requested as the content
	of the claims in the issued token. As an example, the body SHOULD		of the claims in the issued token. As an example, the body SHOULD
	contain a JSON object as follows:		contain a JSON object as follows:
	{		{
	"tktype":"TNAuthList",		"tktype":"TNAuthList",
	"tkvalue":"F83n2a...avn27DN3",		"tkvalue":"F83n2a...avn27DN3",
	"ca":false,		"ca":false,
	"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3		"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3
	:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"		:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"
	}		}
	The response to the POST request if successful returns a 200 OK with		If successful, the response to the POST request returns a 200 (OK)
	a JSON body that contains, at a minimum, the TNAuthList Authority		with a JSON body that contains, at a minimum, the TNAuthList
	Token as a JSON object with a key of "token" and the base64url		Authority Token as a JSON object with a key of "token" and the
	encoded string representing the atc token. JSON is easily		base64url-encoded string representing the atc token. JSON is easily
	extensible, so users of this specification may want to pass other		extensible, so users of this specification may want to pass other
	pieces of information relevant to a specific application.		pieces of information relevant to a specific application.
	An example successful response would be as follows:		An example of a successful response would be as follows:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}		{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}
	If the request is not successful, the response should indicate the		If the request is not successful, the response should indicate the
	error condition. Specifically, for the case that the authorization		error condition. Specifically, for the case that the authorization
	credentials are invalid or if the Account ID provided does not exist,		credentials are invalid or if the account identifier provided does
	the response code MUST be 403 - Forbidden. Other 4xx and 5xx		not exist, the response code MUST be 403 (Forbidden). Other 4xx and
	responses MUST follow standard [RFC7231] HTTP error condition		5xx responses MUST follow standard HTTP error condition conventions
	conventions.		[RFC9110].
	5.6. Token Authority Responsibilities		5.6. Token Authority Responsibilities
	When creating the TNAuthList Authority Token, the Token Authority		When creating the TNAuthList Authority Token, the Token Authority
	MUST validate that the information contained in the ASN.1 TNAuthList		MUST validate that the information contained in the ASN.1 TNAuthList
	accurately represents the service provider code (SPC) or telephone		accurately represents the service provider code (SPC) or telephone
	number (TN) resources the requesting party is authorized to represent		number (TN) resources the requesting party is authorized to represent
	based on their pre-established and verified secure relationship		based on their pre-established, verified, and secure relationship
	between the Token Authority and the requesting party. Note that the		between the Token Authority and the requesting party. Note that the
	fingerprint in the token request is not meant to be verified by the		fingerprint in the token request is not meant to be verified by the
	Token Authority, but rather is meant to be signed as part of the		Token Authority but rather is meant to be signed as part of the token
	token so that the party that requests the token can, as part of the		so that the party that requests the token can, as part of the
	challenge response, allow the ACME server to validate the token		challenge response, allow the ACME server to validate that the token
	requested and used came from the same party that controls the ACME		requested and used came from the same party that controls the ACME
	client.		client.
	5.7. Scope of the TNAuthList		5.7. Scope of the TNAuthList
	Because this specification specifically involves the TNAuthList		Because this specification specifically involves the TNAuthList
	defined in [RFC8226] which involves SPC, TNBlock, and individual TNs,		defined in [RFC8226], which involves SPC, telephone number ranges,
	the client may also request an Authority Token with some subset of		and individual telephone numbers, the client may also request an
	its own authority as the TNAuthList provided in the "tkvalue" element		Authority Token with some subset of its own authority as the
	in the "atc" JSON object. Generally, the scope of authority		TNAuthList provided in the "tkvalue" element in the "atc" JSON
	representing a communications service provider is represented by a		object. Generally, the scope of authority representing a CSP is
	particular SPC (e.g. in North America, an operating company number		represented by a particular SPC (e.g., in North America, an operating
	(OCN) or service provider identifier (SPID)). That provider is also		company number (OCN) or service provider identifier (SPID)). Based
	generally associated, based on number allocations, with a particular		on number allocations, that provider is also generally associated
	set of different TN Blocks and/or TNs. TNAuthList can be constructed		with a particular set of different telephone number ranges and/or
	to define a limited scope of the TNBlocks or TNs either associated		telephone numbers. The TNAuthList can be constructed to define a
	with an SPC or with the scope of TN Blocks or TNs the client has		limited scope of the TelephoneNumberRanges or TelephoneNumbers
			([RFC8226], Section 9) either associated with an SPC or with the
			scope of telephone number ranges or telephone numbers the client has
	authority over.		authority over.
	As recommended in [I-D.ietf-acme-authority-token] security		As recommended in the Security Considerations section in [RFC9447],
	considerations, an Authority Token can either have a scope that		an Authority Token can either have a scope that attests all of the
	attests all of the resources which a client is eligible to receive		resources that a client is eligible to receive certificates for or
	certificates for, or potentially a more limited scope that is		potentially a more limited scope that is intended to capture only
	intended to capture only those resources for which a client will		those resources for which a client will receive a certificate from a
	receive a certificate from a particular certification authority. Any		particular certification authority. Any certification authority that
	certification authority that sees an Authority Token can learn		sees an Authority Token can learn information about the resources a
	information about the resources a client can claim. In cases where		client can claim. In cases where this incurs a privacy risk,
	this incurs a privacy risk, Authority Token scopes should be limited		Authority Token scopes should be limited to only the resources that
	to only the resources that will be attested by the requested ACME		will be attested by the requested ACME certificate.
	certificate.
	6. Validating the TNAuthList Authority Token		6. Validating the TNAuthList Authority Token
	Upon receiving a response to the challenge, the ACME server MUST		Upon receiving a response to the challenge, the ACME server MUST
	perform the following steps to determine the validity of the		perform the following steps to determine the validity of the
	response.		response.
	* Verify that the value of the "atc" claim is a well-formed JSON		1. Verify that the value of the "atc" claim is a well-formed JSON
	object containing the mandatory key values.		object containing the mandatory key values.
	* If there is an "x5u" parameter verify the "x5u" parameter is a		2. If there is an "x5u" parameter, verify the "x5u" parameter is an
	HTTPS URL with a reference to a certificate representing the		HTTPS URL with a reference to a certificate representing the
	trusted issuer of authority tokens for the eco-system.		trusted issuer of Authority Tokens for the ecosystem.
	* If there is an "x5c" parameter verify the certificate array		3. If there is an "x5c" parameter, verify the certificate array
	contains a certificate representing the trusted issuer of		contains a certificate representing the trusted issuer of
	authority tokens for the eco-system.		Authority Tokens for the ecosystem.
	* Verify the TNAuthList Authority Token signature using the public		4. Verify the TNAuthList Authority Token signature using the public
	key of the certificate referenced by the token's "x5u" or "x5c"		key of the certificate referenced by the token's "x5u" or "x5c"
	parameter.		parameter.
	* Verify that "atc" claim contains a "tktype" identifier with the		5. Verify that "atc" claim contains a "tktype" identifier with the
	value "TNAuthList".		value "TNAuthList".
	* Verify that the "atc" claim "tkvalue" identifier contains the		6. Verify that the "atc" claim "tkvalue" identifier contains the
	equivalent base64url encoded TNAuthList certificate extension		equivalent base64url-encoded TNAuthList certificate extension
	string value as the Identifier specified in the original		string value as the identifier specified in the original
	challenge.		challenge.
	* Verify that the remaining claims are valid (e.g., verify that		7. Verify that the remaining claims are valid (e.g., verify that
	token has not expired)		token has not expired).
	* Verify that the "atc" claim "fingerprint" is valid and matches the		8. Verify that the "atc" claim "fingerprint" is valid and matches
	account key of the client making the request		the account key of the client making the request.
	* Verify that the "atc" claim "ca" identifier boolean corresponds to		9. Verify that the "atc" claim "ca" identifier boolean corresponds
	the CA boolean in the Basic Constraints extension in the CSR for		to the CA boolean in the Basic Constraints extension in the
	either CA certificate or end-entity certificate		Certificate Signing Request (CSR) for either CA certificate or
			end-entity certificate.
	If all steps in the token validation process pass, then the ACME		If all steps in the token validation process pass, then the ACME
	server MUST set the challenge object "status" to "valid". If any		server MUST set the challenge object "status" to "valid". If any
	step of the validation process fails, the "status" in the challenge		step of the validation process fails, the "status" in the challenge
	object MUST be set to "invalid".		object MUST be set to "invalid".
	7. Using ACME-issued Certificates with JSON Web Signature		7. Using ACME-Issued Certificates with JSON Web Signature
	JSON Web Signature (JWS, [RFC7515]) objects can include an "x5u"		JSON Web Signature (JWS) [RFC7515] objects can include an "x5u"
	header parameter to refer to a certificate that is used to validate		header parameter to refer to a certificate that is used to validate
	the JWS signature. For example, the STIR PASSporT framework		the JWS signature. For example, the STIR PASSporT framework
	[RFC8225] uses "x5u" to indicate the STIR certificate used to		[RFC8225] uses "x5u" to indicate the STIR certificate used to
	validate the PASSporT JWS object. The URLs used in "x5u" are		validate the PASSporT JWS object. The URLs used in "x5u" are
	expected to provide the required certificate in response to a GET		expected to provide the required certificate in response to a GET
	request, not a POST-as-GET as required for the "certificate" URL in		request, not a POST-as-GET, as required for the "certificate" URL in
	the ACME order object. Thus the current mechanism generally requires		the ACME order object. Thus, the current mechanism generally
	the ACME client to download the certificate and host it on a public		requires the ACME client to download the certificate and host it on a
	URL to make it accessible to relying parties. This section defines		public URL to make it accessible to relying parties. This section
	an optional mechanism for the Certificate Authority (CA) to host the		defines an optional mechanism for the certification authority (CA) to
	certificate directly and provide a URL that the ACME client owner can		host the certificate directly and provide a URL that the ACME client
	directly reference in the "x5u" of their signed PASSporTs.		owner can directly reference in the "x5u" of their signed PASSporTs.
	As described in Section 7.4 of [RFC8555] when the certificate is		As described in Section 7.4 of [RFC8555], when the certificate is
	ready for making a finalize request, the server will return a 200		ready for making a "finalize" request, the server will return a 200
	(OK) with the updated order object. In this response, an ACME Server		(OK) with the updated order object. In this response, an ACME server
	can add a newly defined field called "x5u" that can pass this URL to		can add a newly defined field called "x5u" that can pass this URL to
	the ACME client for usage in generated PASSporTs as a publically		the ACME client for usage in generated PASSporTs as a publicly
	available URL for PASSporT validation.		available URL for PASSporT validation.
	x5u (optional, string): A URL that can be used to reference the		x5u (optional, string): a URL that can be used to reference the
	certificate in the "x5u" parameter of a JWS object [RFC7515]		certificate in the "x5u" parameter of a JWS object [RFC7515]
	The publishing of the certificates at the new "x5u" URL should follow		The publishing of the certificates at the new "x5u" URL should follow
	the GET request requirement as mentioned above and should be		the GET request requirement as mentioned above and should be
	consistent with the timely publication according to the durations of		consistent with the timely publication according to the durations of
	the certificate lifecycle.		the certificate life cycle.
	The following is an example of the use of "x5u" in the response when		The following is an example of the use of "x5u" in the response when
	the certificate status is "valid".		the certificate status is "valid".
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X		Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
	Link: <https://example.com/acme/directory>;rel="index"		Link: <https://example.com/acme/directory>;rel="index"
	Location: https://example.com/acme/order/TOlocE8rfgo		Location: https://example.com/acme/order/TOlocE8rfgo
	skipping to change at page 13, line 34 ¶		skipping to change at line 565 ¶
	"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",		"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
	"certificate": "https://example.com/acme/cert/mAt3xBGaobw",		"certificate": "https://example.com/acme/cert/mAt3xBGaobw",
	"x5u": "https://example.com/cert-repo/giJI53km23.pem"		"x5u": "https://example.com/cert-repo/giJI53km23.pem"
	}		}
	8. Usage Considerations		8. Usage Considerations
	8.1. Large number of Non-contiguous TNAuthList values		8.1. Large Number of Noncontiguous TNAuthList Values
	There are many scenarios and reasons to have various combinations of		There are many scenarios and reasons to have various combinations of
	SPCs, TNs, and TN Ranges. [RFC8226] has provided a somewhat		SPCs, TNs, and TN ranges. [RFC8226] has provided a somewhat
	unbounded set of combinations. It's possible that a complex non-		unbounded set of combinations. It's possible that a complex
	contiguous set of telephone numbers are being managed by a CSP. Best		noncontiguous set of telephone numbers are being managed by a CSP.
	practice may be simply to split a set of non-contiguous numbers under		Best practice may be simply to split a set of noncontiguous numbers
	management into multiple STI certificates to represent the various		under management into multiple STI certificates to represent the
	contiguous parts of the greater non-contiguous set of TNs,		various contiguous parts of the greater noncontiguous set of TNs,
	particularly if length of the set of values in identifier object		particularly if the length of the set of values in an identifier
	grows to be too large.		object grows to be too large.
	9. Security Considerations		9. IANA Considerations
			Per this document, IANA has added a new identifier object type to the
			"ACME Identifier Types" registry defined in Section 9.7.7 of
			[RFC8555].
			+============+===========+
			| Label | Reference |
			+============+===========+
			| TNAuthList | RFC 9448 |
			+------------+-----------+
			Table 1
			10. Security Considerations
	The token represented by this document has the credentials to		The token represented by this document has the credentials to
	represent the scope of a telephone number, a block of telephone		represent the scope of a telephone number, a block of telephone
	numbers, or an entire set of telephone numbers represented by an SPC.		numbers, or an entire set of telephone numbers represented by an SPC.
	The creation, transport, and any storage of this token MUST follow		The creation, transport, and any storage of this token MUST follow
	the strictest of security best practices beyond the recommendations		the strictest of security best practices beyond the recommendations
	of the use of encrypted transport protocols in this document to		of the use of encrypted transport protocols in this document to
	protect it from getting in the hands of bad actors with illegitimate		protect it from getting in the hands of bad actors with illegitimate
	intent to impersonate telephone numbers.		intent to impersonate telephone numbers.
	This document inherits the security properties of		This document inherits the security properties of [RFC9447].
	[I-D.ietf-acme-authority-token]. Implementations should follow the		Implementations should follow the best practices identified in
	best practices identified in [RFC8725].		[RFC8725].
	This document only specifies SHA256 for the fingerprint hash.		This document only specifies SHA256 for the fingerprint hash.
	However, the syntax of the fingerprint object would permit other		However, the syntax of the fingerprint object would permit other
	algorithms if, due to concerns about algorithmic agility, a more		algorithms if, due to concerns about algorithmic agility, a more
	robust algorithm were required at a future time. Future		robust algorithm were required at a future time. Future
	specifications can define new algorithms for the fingerprint object		specifications can define new algorithms for the fingerprint object
	as needed.		as needed.
	10. IANA Considerations		11. References
	This document requests the addition of a new identifier object type
	to the "ACME Identifier Types" registry defined in Section 9.7.7 of
	[RFC8555].
	+------------+-----------+
	| Label | Reference |
	+------------+-----------+
	| TNAuthList | RFCThis |
	+------------+-----------+
	11. Acknowledgements
	We would like to thank Richard Barnes and Russ Housley for valuable
	contributions to this document.
	12. References
	12.1. Normative References
	[I-D.ietf-acme-authority-token]		11.1. Normative References
	Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
	Challenges Using an Authority Token", Work in Progress,
	Internet-Draft, draft-ietf-acme-authority-token-09, 24
	October 2022, <https://www.ietf.org/archive/id/draft-ietf-
	acme-authority-token-09.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>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<https://www.rfc-editor.org/info/rfc4648>.		<https://www.rfc-editor.org/info/rfc4648>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.
	[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>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[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,
	skipping to change at page 16, line 9 ¶		skipping to change at line 657 ¶
	[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best		[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
	Current Practices", BCP 225, RFC 8725,		Current Practices", BCP 225, RFC 8725,
	DOI 10.17487/RFC8725, February 2020,		DOI 10.17487/RFC8725, February 2020,
	<https://www.rfc-editor.org/info/rfc8725>.		<https://www.rfc-editor.org/info/rfc8725>.
	[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)		[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
	Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,		Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
	September 2021, <https://www.rfc-editor.org/info/rfc9060>.		September 2021, <https://www.rfc-editor.org/info/rfc9060>.
	12.2. Informative References		[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "HTTP Semantics", STD 97, RFC 9110,
			DOI 10.17487/RFC9110, June 2022,
			<https://www.rfc-editor.org/info/rfc9110>.
			[RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
			"Automated Certificate Management Environment (ACME)
			Challenges Using an Authority Token", RFC 9447,
			DOI 10.17487/RFC9447, August 2023,
			<https://www.rfc-editor.org/info/rfc9447>.
			11.2. Informative References
	[ATIS-1000080]		[ATIS-1000080]
	ATIS/SIP Forum NNI Task Group, "Signature-based Handling		ATIS, "Signature-based Handling of Asserted information
	of Asserted information using toKENs (SHAKEN) Governance		using toKENs (SHAKEN): Governance Model and Certificate
	Model and Certificate Management		Management", ATIS-1000080.v005, December 2022,
	<https://access.atis.org/apps/group_public/		<https://access.atis.org/apps/group_public/
	download.php/32237/ATIS-1000080.pdf>", July 2017.		download.php/69428/ATIS-1000080.v005.pdf>.
	[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure		[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
	Telephone Identity Problem Statement and Requirements",		Telephone Identity Problem Statement and Requirements",
	RFC 7340, DOI 10.17487/RFC7340, September 2014,		RFC 7340, DOI 10.17487/RFC7340, September 2014,
	<https://www.rfc-editor.org/info/rfc7340>.		<https://www.rfc-editor.org/info/rfc7340>.
	[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 8224,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,		DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.		<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion		[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
	Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,		Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
	<https://www.rfc-editor.org/info/rfc8225>.		<https://www.rfc-editor.org/info/rfc8225>.
			Acknowledgements
			We would like to thank Richard Barnes and Russ Housley for valuable
			contributions to this document.
	Authors' Addresses		Authors' Addresses
	Chris Wendt		Chris Wendt
	Somos Inc.		Somos Inc.
	United States of America		United States of America
	Email: chris-ietf@chriswendt.net		Email: chris-ietf@chriswendt.net
	David Hancock		David Hancock
	Comcast		Somos Inc.
	United States of America		United States of America
	Email: davidhancock.ietf@gmail.com		Email: davidhancock.ietf@gmail.com
	Mary Barnes		Mary Barnes
	Neustar Inc.		Neustar Inc.
	United States of America		United States of America
	Email: mary.ietf.barnes@gmail.com		Email: mary.ietf.barnes@gmail.com
	Jon Peterson		Jon Peterson
	Neustar Inc.		Neustar Inc.
	1800 Sutter St Suite 570		Suite 570
	Concord, CA 94520,		1800 Sutter St
			Concord, CA 94520
	United States of America		United States of America
	Email: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
End of changes. 85 change blocks.
	287 lines changed or deleted		284 lines changed or added
This html diff was produced by rfcdiff 1.48.