draft-ietf-stir-passport-rcd-01.txt   draft-ietf-stir-passport-rcd-02.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Inc. Internet-Draft Neustar Inc.
Intended status: Informational C. Wendt Intended status: Standards Track C. Wendt
Expires: April 25, 2019 Comcast Expires: August 22, 2019 Comcast
October 22, 2018 February 18, 2019
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-01 draft-ietf-stir-passport-rcd-02
Abstract Abstract
This document extends PASSporT, a token for conveying This document extends PASSporT, a token for conveying
cryptographically-signed information about personal communications, cryptographically-signed information about personal communications,
to include rich data that can be rendered to users, such as a human- to include rich data that can be rendered to users, such as a human-
readable display name comparable to the "Caller ID" function common readable display name comparable to the "Caller ID" function common
on the telephone network. The element defined for this purpose is on the telephone network. The element defined for this purpose is
extensible to include related information about calls that helps extensible to include related information about calls that helps
people decide whether to pick up the phone. people decide whether to pick up the phone.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 25, 2019. This Internet-Draft will expire on August 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PASSporT 'rcd' Claim . . . . . . . . . . . . . . . . . . . . 3 3. PASSporT 'rcd' Claim . . . . . . . . . . . . . . . . . . . . 3
4. Further Information Associated with Callers . . . . . . . . . 4 3.1. 'nam' key . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 5 3.2. 'jcd' key . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Signing as a Third Party . . . . . . . . . . . . . . . . 6 3.3. 'jcl' key . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 6 3.4. 'rcd' Usage . . . . . . . . . . . . . . . . . . . . . . . 4
7. Using 'rcd' in SIP . . . . . . . . . . . . . . . . . . . . . 7 3.5. Example 'rcd' PASSporTs . . . . . . . . . . . . . . . . . 5
7.1. Authentication Service Behavior . . . . . . . . . . . . . 7 4. Further Information Associated with Callers . . . . . . . . . 6
7.2. Verification Service Behavior . . . . . . . . . . . . . . 7 5. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 7
8. Using 'rcd' as additional claims to other PASSporT extensions 8 5.1. Signing as a Third Party . . . . . . . . . . . . . . . . 8
8.1. Procedures for applying 'rcd' as claims only . . . . . . 9 6. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 9
8.2. Example for applying 'rcd' as claims only . . . . . . . . 9 7. Using 'rcd' in SIP . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Authentication Service Behavior . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.2. Verification Service Behavior . . . . . . . . . . . . . . 10
10.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 10 8. Using 'rcd' as additional claims to other PASSporT extensions 11
10.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 10 8.1. Procedures for applying 'rcd' as claims only . . . . . . 11
10.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 10 8.2. Example for applying 'rcd' as claims only . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 10.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 people conveying cryptographically-signed information about the people
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 3, line 37 skipping to change at page 3, line 42
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [RFC2119] and [RFC6919]. described in [RFC2119] and [RFC6919].
3. PASSporT 'rcd' Claim 3. 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 an array of JSON subelements. The Call Data, the value of which is a JSON object that can contain one
initial subelement defined here is a display name, "nam", associated or more key value pairs. This document defines a default set of
with the originator of personal communications, which may for example three key values one being mandatory, the others are optional.
derive from the display-name component of the From header field value
of a SIP request, or a similar field in other PASSporT using
protocols.
The "rcd" claim may appear in any PASSporT claims object as an 3.1. 'nam' key
optional element. The creator of a PASSporT MAY however add a "ppt"
value of "rcd" to the header of a PASSporT as well, in which case the The 'nam' key value is a display name, associated with the originator
PASSporT claims MUST contain a "rcd" claim, and any entities of personal communications, which may for example derive from the
display-name component of the From header field value of a SIP
request, or a similar field in other PASSporT using protocols. This
key is mandatory and MUST be included as as part of the 'rcd' claim
value JSON object.
3.2. 'jcd' key
The 'jcd' key value is defined to contain a value of a jCard
[RFC7095] JSON object. This jCard object is intended to be an
extensible object that the calling party of personal communications
can provide both the types of information defined in jCard or can use
the built in extensibility of the jCard specification to add
additional information. The 'jcd' is optional. If included, this
key MUST only be included once in the 'rcd' JSON object and SHOULD
NOT be included if there is a 'jcl' key included. The 'jcd' and
'jcl' keys should be mutually exclusive.
3.3. 'jcl' key
The 'jcl' key value is defined to contain a HTTPS URL that refers the
recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled
web server. This link is intended to be an external reference to a
JSON file with the same intended use of the 'jcd' jCard object and
has the same intended properties. The 'jcl' key is optional. If
included, this key MUST only be included once in the 'rcd' JSON
object and SHOULD NOT be included if there is a 'jcd' key included.
The 'jcd' and 'jcl' keys should be mutually exclusive.
3.4. 'rcd' Usage
The 'rcd' claim may appear in any PASSporT claims object as an
optional element. The creator of a PASSporT MAY however add a 'ppt'
value of 'rcd' to the header of a PASSporT as well, in which case the
PASSporT claims MUST contain a 'rcd' claim, and any entities
verifying the PASSporT object will be required to understand the verifying the PASSporT object will be required to understand the
"ppt" extension in order to process the PASSporT in question. A 'ppt' extension in order to process the PASSporT in question. A
PASSporT header wih the "ppt" included will look as follows: PASSporT header with the 'ppt' included will look as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
The PASSporT claims object will then contain the "rcd" key with its The PASSporT claims object will then contain the "rcd" key with its
corresponding value. The value of "rcd" is an array of JSON objects, corresponding value. The value of "rcd" is an array of JSON objects,
of which one, the "nam" object, is mandatory. The key syntax of of which one, the "nam" object, is mandatory. The key syntax of
"nam" follows the display-name ABNF given in [RFC3261]. "nam" follows the display-name ABNF given in [RFC3261].
{ "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551213"},
"iat":1443208345,
"iss":"Example, Inc.",
"rcd":{"nam":"Alice Atlanta"} }
After the header and claims PASSporT objects have been constructed, After the header and claims PASSporT objects have been constructed,
their signature is generated normally per the guidance in [RFC8225]. their signature is generated normally per the guidance in [RFC8225].
3.5. Example 'rcd' PASSporTs
An example of a 'nam' only PASSporT claims obejct is shown next (with
line breaks for readability only).
{ "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"},
"iat":1443208345,
"rcd":{"nam":"James Bond"} }
An example of a PASSporT claims object that includes the "jcd" which
is optional, but will also include the mandatory "nam" object is
shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"},
"iat":1443208345,
"rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"],
["fn",{},"text", "James Bond"],
["n",{},"text",["Bond","James","","","Mr."]],
["adr",{"type":"work"},"text",
["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"]
],
["email",{},"text","007@mi6-hq.com"],
["tel",{"type":["voice","text","cell"],"pref":"1"},"uri",
"tel:+1-202-555-1000"],
["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"],
["bday",{},"date","19241116"],
["logo",{},"uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"
]]]}}
In an example PASSporT where a jCard is linked via HTTPS URL and
'jcl' a jCard file served at a particular URL will be created.
An example jCard JSON file is shown as follows:
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "James Bond"],
["n", {}, "text", ["Bond", "James", "", "", "Mr."]],
["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008",
"USA"]
],
["email", {}, "text", "007@mi6-hq.com"],
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
"tel:+1-202-555-1000"],
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"],
["bday", {}, "date", "19241116"]
["logo", {}, "uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"]
]
]
If that jCard is hosted at the example address of
"https://example.org/james_bond.json", the cooresponding PASSporT
claims object would be as follows (with line breaks for readability
only):
{ "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"},
"iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"}
}
4. Further Information Associated with Callers 4. Further Information Associated with Callers
Beyond naming information, there may be additional human-readable Beyond naming information and the information that can be contained
in a jCard [RFC7095] object, there may be additional human-readable
information about the calling party that should be rendered to the information about the calling party that should be rendered to the
end user in order to help the called party decide whether or not to end user in order to help the called party decide whether or not to
pick up the phone. This is not limited to information about the pick up the phone. This is not limited to information about the
caller, but includes information about the call itself, which may caller, but includes information about the call itself, which may
derive from analytics that determine based on call patterns or derive from analytics that determine based on call patterns or
similar data if the call is likely to be one the called party wants similar data if the call is likely to be one the called party wants
to receive. Such data could include: to receive. Such data could include:
information related to the location of the caller, or information related to the location of the caller, or
skipping to change at page 6, line 29 skipping to change at page 8, line 39
A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that
do not have authority over the identity that appears in the "orig" do not have authority over the identity that appears in the "orig"
element of the PASSporT claims. Relying parties in STIR have always element of the PASSporT claims. Relying parties in STIR have always
been left to make their own authorization decisions about whether or been left to make their own authorization decisions about whether or
not the trust the signers of PASSporTs, and in the third-party case, not the trust the signers of PASSporTs, and in the third-party case,
where an entity has explicitly queried a service to acquire the where an entity has explicitly queried a service to acquire the
PASSporT object, it may be some external trust or business PASSporT object, it may be some external trust or business
relationship that induces the relying party to trust a PASSporT. relationship that induces the relying party to trust a PASSporT.
An example of a Third Party issued PASSporT claims object is as
follows.
{ "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"},
"iat":1443208345,
"iss":"Example, Inc.",
"rcd":{"nam":"James Bond"} }
6. Levels of Assurance 6. Levels of Assurance
As "rcd" can be provided by either first or third parties, relying As "rcd" can be provided by either first or third parties, relying
parties could benefit from an additional claim that indicates the parties could benefit from an additional claim that indicates the
relationship of the attesting party to the caller. Even in first relationship of the attesting party to the caller. Even in first
party cases, this admits of some complexity: the Communications party cases, this admits of some complexity: the Communications
Service Provider (CSP) to which a number was assigned might in turn Service Provider (CSP) to which a number was assigned might in turn
delegate the number to a reseller, who would then sell the number to delegate the number to a reseller, who would then sell the number to
an enterprise, in which case the CSP might have little insight into an enterprise, in which case the CSP might have little insight into
the caller's name. In third party cases, a caller's name could the caller's name. In third party cases, a caller's name could
skipping to change at page 7, line 28 skipping to change at page 9, line 49
SIP authentication services MUST add a "ppt" parameter to the SIP authentication services MUST add a "ppt" parameter to the
Identity header containing that PASSporT with a value of "rcd". The Identity header containing that PASSporT with a value of "rcd". The
resulting Identity header might look as follows: resulting Identity header might look as follows:
Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="rcd" info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="rcd"
This specification assumes that by default, a SIP authentication This specification assumes that by default, a SIP authentication
service will derive the value of "rcd" from the display-name service will derive the value of "rcd", specifically only for the
component of the From header field value of the request. It is 'nam' key value, from the display-name component of the From header
however a matter of authentication service policy to decide how it field value of the request, alternatively for some calls this may
populates the value of "rcd", which MAY also derive from other fields come from the P-Asserted-ID header. It is however a matter of
in the request, from customer profile data, or from access to authentication service policy to decide how it populates the value of
external services. If the authentication service generates a "rcd" and 'nam' key, which MAY also derive from other fields in the
PASSporT object containing "rcd" with a value that is not equivalent request, from customer profile data, or from access to external
to the From header field display-name value, it MUST use the full services. If the authentication service generates a PASSporT object
form of the PASSporT object in SIP. containing "rcd" with a value that is not equivalent to the From
header field display-name value, it MUST use the full form of the
PASSporT object in SIP.
7.2. Verification Service Behavior 7.2. Verification Service Behavior
[RFC8224] Section 6.2 Step 5 requires that specifications defining [RFC8224] Section 6.2 Step 5 requires that specifications defining
"ppt" values describe any additional verifier behavior. The behavior "ppt" values describe any additional verifier behavior. The behavior
specified for the "ppt" values of "rcd" is as follows. If the specified for the "ppt" values of "rcd" is as follows. If the
PASSporT is in compact form, then the verification service SHOULD PASSporT is in compact form, then the verification service SHOULD
extract the display-name from the From header field value, if any, extract the display-name from the From header field value, if any,
and use that as the value for the "rcd" key when it recomputes the and use that as the value for the "rcd" key when it recomputes the
header and claims of the PASSporT object. If the signature validates header and claims of the PASSporT object. If the signature validates
skipping to change at page 9, line 26 skipping to change at page 11, line 49
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.
8.2. Example for applying 'rcd' as claims only 8.2. Example for applying 'rcd' as claims only
In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT
extension supporting the SHAKEN specification [ATIS-1000074], a extension supporting the SHAKEN specification [ATIS-1000074], a
common case for an Authenication service to co-exist in a CSP network common case for an Authentication service to co-exist in a CSP
along with the authority over the calling name used for the call. network along with the authority over the calling name used for the
Rather than require two identity headers, the CSP Authenticaton call. Rather than require two identity headers, the CSP
Service can apply both the SHAKEN PASSporT claims and extension and Authentication Service can apply both the SHAKEN PASSporT claims and
simply add the 'rcd' required claims defined in this document. extension and simply add 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
{ {
"alg":"ES256", "alg":"ES256",
"typ":"passport", "typ":"passport",
"ppt":"shaken", "ppt":"shaken",
"x5u":"https://cert.example.org/passport.cer" "x5u":"https://cert.example.org/passport.cer"
} }
Payload Payload
{ {
"attest":"A" "attest":"A",
"dest":{"uri":["sip:alice@example.com"]} "dest":{"tn":["12025551001"]},
"iat":"1443208345", "iat":1443208345,
"orig":{"tn":"12155551212"}, "orig":{"tn":"12025551000"},
"origid":"123e4567-e89b-12d3-a456-426655440000" "origid":"123e4567-e89b-12d3-a456-426655440000",
"rcd":{"nam":"Alice Atlanta"} } "rcd":{"nam":"James Bond"}
} }
A Verification Service that supports 'rcd' and 'shaken' PASSporT A Verification Service that supports 'rcd' and 'shaken' PASSporT
extensions will be able to receive the above PASSporT and interpret extensions will be able to receive the above PASSporT and interpret
both the 'shaken' claims as well as the 'rcd' defined claim. both the 'shaken' claims as well as the 'rcd' defined claim.
If the Verification Service only understands the 'shaken' extension If the Verification Service only understands the 'shaken' extension
claims but doesn't support 'rcd', the 'rcd' can simply be ignored and claims but doesn't support 'rcd', the 'rcd' can simply be ignored and
disregarded. disregarded.
9. Acknowledgements 9. Acknowledgements
skipping to change at page 11, line 31 skipping to change at page 14, line 10
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>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>. <https://www.rfc-editor.org/info/rfc6919>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[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>.
[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>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
skipping to change at page 12, line 15 skipping to change at page 14, line 43
12.2. Informative References 12.2. Informative References
[ATIS-1000074] [ATIS-1000074]
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/32237/ATIS-1000074.pdf>", January 2017.
[I-D.ietf-stir-passport-shaken] [I-D.ietf-stir-passport-shaken]
Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension
(SHAKEN)", draft-ietf-stir-passport-shaken-04 (work in (SHAKEN)", draft-ietf-stir-passport-shaken-07 (work in
progress), October 2018. progress), January 2019.
[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>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar Inc. Neustar Inc.
 End of changes. 18 change blocks. 
68 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/