draft-ietf-stir-passport-rcd-07.txt   draft-ietf-stir-passport-rcd-08.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Inc. Internet-Draft Neustar Inc.
Intended status: Standards Track C. Wendt Intended status: Standards Track C. Wendt
Expires: May 6, 2021 Comcast Expires: May 20, 2021 Comcast
November 02, 2020 November 16, 2020
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-07 draft-ietf-stir-passport-rcd-08
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 users. This framework is intended to extend subsequently rendered to users. This framework is intended to extend
caller and call specific information beyond human-readable display caller and call specific information beyond human-readable display
name comparable to the "Caller ID" function common on the telephone name comparable to the "Caller ID" function common on the telephone
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 May 6, 2021. This Internet-Draft will expire on May 20, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 12, line 8 skipping to change at page 12, line 8
/Fleming007impression.jpg"] /Fleming007impression.jpg"]
] ]
] ]
If that jCard is hosted at the example address of If that jCard is hosted at the example address of
"https://example.org/james_bond.json", the corresponding PASSporT "https://example.org/james_bond.json", the corresponding PASSporT
claims object would be as follows (with line breaks for readability claims object would be as follows (with line breaks for readability
only): only):
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"}
} }
If we were to add a "rcdi" integrity claim to the last example, the If we were to add a "rcdi" integrity claim to the last example, the
corresponding PASSporT claims object would be as follows (with line corresponding PASSporT claims object would be as follows (with line
breaks for readability only): breaks for readability only):
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"}
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm" "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm"
} }
7. Compact form of "rcd" PASSporT 7. Compact form of "rcd" PASSporT
7.1. Compact form of the "rcd" PASSporT claim 7.1. Compact form of the "rcd" PASSporT claim
Compact form of an "rcd" PASSporT claim has some restrictions but Compact form of an "rcd" PASSporT claim has some restrictions but
skipping to change at page 15, line 28 skipping to change at page 15, line 28
about whether or not the trust the signers of PASSporTs, and in the about whether or not the trust the signers of PASSporTs, and in the
third-party case, where an entity has explicitly queried a service to third-party case, where an entity has explicitly queried a service to
acquire the PASSporT object, it may be some external trust or acquire the PASSporT object, it may be some external trust or
business relationship that induces the relying party to trust a business relationship that induces the relying party to trust a
PASSporT. PASSporT.
An example of a Third Party issued PASSporT claims object is as An example of a Third Party issued PASSporT claims object is as
follows. follows.
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"iss":"Example, Inc.", "iss":"Example, Inc.",
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
10. Levels of Assurance 10. 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
skipping to change at page 16, line 24 skipping to change at page 16, line 24
11.1. Authentication Service Behavior 11.1. Authentication Service Behavior
An authentication service creating a PASSporT containing a "rcd" An authentication service creating a PASSporT containing a "rcd"
claim MAY include a "ppt" for "rcd" or not. Third-party claim MAY include a "ppt" for "rcd" or not. Third-party
authentication services following the behavior in Section 9.1 MUST authentication services following the behavior in Section 9.1 MUST
include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any
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/HmtyNS7Ltrg9 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0
Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \
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", specifically only for the service will derive the value of "rcd", specifically only for the
"nam" key value, from the display-name component of the From header "nam" key value, from the display-name component of the From header
field value of the request, alternatively for some calls this may field value of the request, alternatively for some calls this may
come from the P-Asserted-ID header. It is however a matter of come from the P-Asserted-ID header. It is however a matter of
authentication service policy to decide how it populates the value of authentication service policy to decide how it populates the value of
"rcd" and "nam" key, which MAY also derive from other fields in the "rcd" and "nam" key, which MAY also derive from other fields in the
request, from customer profile data, or from access to external request, from customer profile data, or from access to external
services. If the authentication service generates a PASSporT object services. If the authentication service generates a PASSporT object
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 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/