< draft-ietf-sipcore-rejected-07.txt   draft-ietf-sipcore-rejected-08.txt >
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track B. Nagda Intended status: Standards Track B. Nagda
Expires: October 25, 2019 Massachusetts Institute of Technology Expires: November 22, 2019 Massachusetts Institute of Technology
April 23, 2019 May 21, 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-07 draft-ietf-sipcore-rejected-08
Abstract Abstract
This document defines the 608 (Rejected) SIP response code. This This document defines the 608 (Rejected) SIP response code. This
response code enables calling parties to learn that an intermediary response code enables calling parties to learn that an intermediary
rejected their call attempt. No one will deliver, and thus no one rejected their call attempt. No one will deliver, and thus no one
will answer, the call. As a 6xx code, the caller will be aware that will answer, the call. As a 6xx code, the caller will be aware that
future attempts to contact the same User Agent Server will likely future attempts to contact the same User Agent Server will likely
fail. The initial use case driving the need for the 608 response fail. The initial use case driving the need for the 608 response
code is when the intermediary is an analytics engine. In this case, code is when the intermediary is an analytics engine. In this case,
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 25, 2019. This Internet-Draft will expire on November 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN]
address the cryptographic signing and attestation, respectively, of address the cryptographic signing and attestation, respectively, of
signaling to ensure the integrity and authenticity of the asserted signaling to ensure the integrity and authenticity of the asserted
caller identity. caller identity.
This document describes a new SIP response code, 608, which allows This document describes a new SIP response code, 608, which allows
calling parties to learn that an intermediary rejected their call. calling parties to learn that an intermediary rejected their call.
As described below, we need a distinct indicator to differentiate As described below, we need a distinct indicator to differentiate
between a user rejection and an intermediary's rejection of a call. between a user rejection and an intermediary's rejection of a call.
In some jurisdictions, service providers may not block calls, even if In some jurisdictions, service providers may not be permitted to
unwanted by the user, unless there is an explicit user request. block calls, even if unwanted by the user, unless there is an
Moreover, users may misidentify the nature of a caller. explicit user request. Moreover, users may misidentify the nature of
a caller.
For example, a legitimate caller may call a user who finds the call For example, a legitimate caller may call a user who finds the call
to be unwanted. However, instead of marking the call as unwanted, to be unwanted. However, instead of marking the call as unwanted,
the user may mark the call as illegal. With that information, an the user may mark the call as illegal. With that information, an
analytics engine may determine to block all calls from that source. analytics engine may determine to block all calls from that source.
However, in some jurisdictions blocking calls from that source for However, in some jurisdictions blocking calls from that source for
other users may not be legal. Likewise, one can envision other users may not be legal. Likewise, one can envision
jurisdictions that allow an operator to block such calls, but only if jurisdictions that allow an operator to block such calls, but only if
there is a remediation mechanism in place to address false positives. there is a remediation mechanism in place to address false positives.
skipping to change at page 6, line 20 skipping to change at page 6, line 22
other words, those downstream entities should not rely on another other words, those downstream entities should not rely on another
entity 'deciding' the call is unwanted. By distinguishing between a entity 'deciding' the call is unwanted. By distinguishing between a
(human) user rejection and an intermediary engine's statistical (human) user rejection and an intermediary engine's statistical
rejection, a downstream network element that sees a 607 response code rejection, a downstream network element that sees a 607 response code
can weigh it as a human rejection in its call analytics, versus can weigh it as a human rejection in its call analytics, versus
deciding whether to consider a 608 at all, and if so, weighing it deciding whether to consider a 608 at all, and if so, weighing it
appropriately. appropriately.
It is useful for blocked callers to have a redress mechanism. One It is useful for blocked callers to have a redress mechanism. One
can imagine that some jurisdictions will require it. However, we can imagine that some jurisdictions will require it. However, we
must be mindful that most of the calls intermediaries block will, in must be mindful that most of the calls that intermediaries block
fact, be illegal and eligible for blocking. Thus, providing will, in fact, be illegal and eligible for blocking. Thus, providing
alternate contact information for a user would be counterproductive alternate contact information for a user would be counterproductive
to protecting that user from illegal communications. This is another to protecting that user from illegal communications. This is another
reason we do not propose to simply allow alternate contact reason we do not propose to simply allow alternate contact
information in a 607 response message. information in a 607 response message.
Why do we not use the same mechanism an analytics service provider Why do we not use the same mechanism an analytics service provider
offers their customers? Specifically, why not have the analytics offers their customers? Specifically, why not have the analytics
service provider allow the called party to correct a call blocked in service provider allow the called party to correct a call blocked in
error? The reason is while there is an existing relationship between error? The reason is while there is an existing relationship between
the customer (called party) and the analytics service provider, it is the customer (called party) and the analytics service provider, it is
skipping to change at page 7, line 9 skipping to change at page 7, line 11
[RFC6350] as we have a marshaling mechanism for creating a JavaScript [RFC6350] as we have a marshaling mechanism for creating a JavaScript
Object Notation (JSON) [RFC8259] object, such as a jCard, and a Object Notation (JSON) [RFC8259] object, such as a jCard, and a
standard integrity format for such an object, namely JSON Web standard integrity format for such an object, namely JSON Web
Signature (JWS) [RFC7515]. The SIP community is familiar with this Signature (JWS) [RFC7515]. The SIP community is familiar with this
concept as it is the mechanism used by STIR [RFC8224]. concept as it is the mechanism used by STIR [RFC8224].
Integrity protecting the jCard with a cryptographic signature might Integrity protecting the jCard with a cryptographic signature might
seem unnecessary at first, but it is essential to preventing seem unnecessary at first, but it is essential to preventing
potential network attacks. Suppose, for example, that one simply potential network attacks. Suppose, for example, that one simply
passes the redress address as a header field value. One can imagine passes the redress address as a header field value. One can imagine
an adverse agent that maliciously spoofs a 608 response with the same an adverse agent that maliciously spoofs a 608 response with a
redress address to many active callers, who may then all send redress victim's contact address to many active callers, who may then all
requests to the specified address (the basis for a denial-of-service send redress requests to the specified address (the basis for a
attack). The process would occur as follows: (1) a malicious agent denial-of-service attack). The process would occur as follows: (1) a
senses INVITE requests from a variety UACs and (2) spoofs 608 malicious agent senses INVITE requests from a variety of UACs and (2)
responses with an unsigned redress address before the intended spoofs 608 responses with an unsigned redress address before the
receivers can respond, causing (3) the UACs to all contact the intended receivers can respond, causing (3) the UACs to all contact
redress address at once. The jCard encoding allows the UAC to verify the redress address at once. The jCard encoding allows the UAC to
the blocking intermediary's identity before contacting the redress verify the blocking intermediary's identity before contacting the
address. This guards against a malicious agent spoofing 608 redress address. Specifically, because the sender signs the jCard,
responses, preventing the denial-of-service attack. Thus, if the we can cryptographically trace the sender of the jCard. Given the
jCard address is unreachable or undecipherable, either (1) a protocol machinery of having a signature, one can apply local policy
malicious agent is lying about the jCard or (2) the redress mechanism to decide whether to believe the sender of the jCard represents the
is misconfigured. owner of the contact information found in the jCard. This guards
against a malicious agent spoofing 608 responses.
2. Terminology 2. Terminology
The key words "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 BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Operation 3. Protocol Operation
skipping to change at page 12, line 15 skipping to change at page 12, line 15
4. Examples 4. Examples
These examples are not normative, do not include all protocol These examples are not normative, do not include all protocol
elements, and may have errors. Review the protocol documents for elements, and may have errors. Review the protocol documents for
actual syntax and semantics of the protocol elements. actual syntax and semantics of the protocol elements.
4.1. Full Exchange 4.1. Full Exchange
Given an INVITE (shamelessly taken from [SHAKEN]): Given an INVITE (shamelessly taken from [SHAKEN]):
INVITE sip:+12155550113@tel.one.example.net SIP/2.0 INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69 Max-Forwards: 69
Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f36cc> Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3>
To: <sip:+12155550113@tel.one.example.net> To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>, P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155550112> <tel:+12155550112>
CSeq: 2 INVITE CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS MESSAGE, OPTIONS
Content-Type: application/sdp Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608 Feature-Caps: *;+sip.608
Identity: Identity:
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I
joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC
J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI
xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6
IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n
Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC
A;info=<http://cert.example2.net/example.cert>;alg=ES256 A;info=<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153 Content-Length: 153
v=0 v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177 o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177 c=IN IP6 2001:db8::177
t=0 0 t=0 0
m=audio 54242 RTP/AVP 0 m=audio 54242 RTP/AVP 0
a=sendrecv a=sendrecv
An intermediary could reply: An intermediary could reply:
SIP/2.0 608 Rejected SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177:60012;branch=z9hG4bK-524287-1 Via: SIP/2.0/UDP [2001:db8::177:60012];branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.net> To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint.json>;purpose=jwscard Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
The location https://block.example.net/complaint.json resolves to a The location https://block.example.net/complaint-jws resolves to a
JWS. One would construct the JWS would as follows. JWS. One would construct the JWS as follows.
The JWS header of this example jCard could be: The JWS header of this example jCard could be:
{ {"alg":"ES256"}, { {"alg":"ES256"},
{"typ":"vcard+json"}, {"typ":"vcard+json"},
{"x5u":"https://certs.example.net/reject_key.cer"} } {"x5u":"https://certs.example.net/reject_key.cer"} }
Now, let us construct a minimal jCard. For this example, the jCard Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address, bitbucket@blocker.example.net: refers the caller to an email address, bitbucket@blocker.example.net:
skipping to change at page 14, line 21 skipping to change at page 14, line 21
decoded text works just fine. However, those extra line break octets decoded text works just fine. However, those extra line break octets
would affect the calculation of the signature. As such, would affect the calculation of the signature. As such,
implementations MUST NOT insert line breaks into the base64url implementations MUST NOT insert line breaks into the base64url
encodings of the JOSE header or JWT. This also means UACs MUST be encodings of the JOSE header or JWT. This also means UACs MUST be
prepared to receive arbitrarily long octet streams from the URI prepared to receive arbitrarily long octet streams from the URI
referenced by the Call-Info SIP header. referenced by the Call-Info SIP header.
base64url of JOSE header: base64url of JOSE header:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo= fQo
base64url of JWT: base64url of JWT:
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
In this case, the object to sign (remembering this is just a single, In this case, the object to sign (remembering this is just a single,
long line; the line breaks are for ease of review but do not appear long line; the line breaks are for ease of review but do not appear
in the actual object) is as follows: in the actual object) is as follows:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo= fQo
. .
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
We use the following X.509 PKCS #8-encoded ECDSA private key, also We use the following X.509 PKCS #8-encoded ECDSA private key, also
shamelessly taken from [SHAKEN]), as an example key for signing the shamelessly taken from [SHAKEN]), as an example key for signing the
hash of the above text. Do NOT use this key in real life! It is for hash of the above text. Do NOT use this key in real life! It is for
skipping to change at page 15, line 15 skipping to change at page 15, line 15
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
The resulting JWS, using the above key on the above object, renders The resulting JWS, using the above key on the above object, renders
the following ECDSA P-256 SHA-256 digital signature. the following ECDSA P-256 SHA-256 digital signature.
MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM
TS+skjf1163ihH5+yIHQS3quklEt/9o= TS+skjf1163ihH5+yIHQS3quklEt/9o
Thus, the JWS stored at https://blocker.example.net/complaints.json, Thus, the JWS stored at https://blocker.example.net/complaints-jws,
would contain: would contain:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA
gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB
bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA
gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ
0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB 0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB
dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e
hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o= hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o
4.2. Web Site jCard 4.2. Web Site jCard
For an intermediary that provides a Web site for adjudication, the For an intermediary that provides a Web site for adjudication, the
jCard could contain the following. Note we do not show the jCard could contain the following. Note we do not show the
calculation of the JWS; the URI reference in the Call-Info header calculation of the JWS; the URI reference in the Call-Info header
field would be to the JWS of the signed jCard. field would be to the JWS of the signed jCard.
["vcard", ["vcard",
[ [
 End of changes. 16 change blocks. 
61 lines changed or deleted 63 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/