Consent-based Communications in SIP draft-ietf-sipping-consent-reqs-04 Consent-based Communications in SIP draft-ietf-sipping-consent-reqs-04.txt draft-ietf-sipping-consent-framework-04.txt draft-camarillo-sip-consent-method-00.txt draft-camarillo-sipping-consent-reg-event-00.txt draft-camarillo-sipping-consent-format-00.txt draft-camarillo-sipping-grant-permission-00.txt draft-camarillo-sipping-list-state-00.txt Gonzalo.Camarillo@ericsson.com

Status Requirements in RFC Editor’s queue draft-ietf-sipping-consent-reqs-04.txt WG consensus on the framework draft-ietf-sipping-consent-framework-04.txt Drafts defining normative behavior to implement the framework draft-camarillo-sip-consent-method-00.txt draft-camarillo-sipping-consent-reg-event-00.txt draft-camarillo-sipping-consent-format-00.txt draft-camarillo-sipping-grant-permission-00.txt draft-camarillo-sipping-list-state-00.txt

Architecture PermissionRequest Permission Server Client Relay Translation Logic Permissions Permission Request Manipulation Permission Grant Recipient

Permission Document Format Based on the common policy format Conditions Actions Transformations New conditions Sender Target New action Trans-handling Block Pending allow

Permission Document Example <cp:rule id="1"> <cp:conditions> <cp:identity> <cp:id entity="bob@example.org" scheme="sip"/> </cp:identity> <target> <cp:id entity="alices-friends@example.com" scheme="sip"/> </target> <sender> <cp:any/> </sender> </cp:conditions> <cp:actions> <trans-handling>allow</trans-handling> </cp:actions> <cp:transformations/> </cp:rule>

B’s Permission Server A@example.com Relay B@example.com Add Recipient: B@example.com Pending

Adding Recipients XCAP to manipulate URI lists application/resource-lists+xml New <consent-status> element <list name="friends"> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>pending</cs:consent-status> </entry> </list>

B’s Permission Server A@example.com Relay B@example.com Add Recipient: B@example.com Pending REFER Refer-To: B@example.com?method=CONSENT 200 OK SUBSCRIBE Event: list-state 200 OK NOTIFY 200 OK

List-state Event Package Uses XCAP-diff to inform about changes in the state of the list Open issue: do we want to use XCAP-patch as well? New <consent-status> element pending, granted, denied Open issue: do we need more values? Trying: CONSENT has been sent Failed: Error response received for the CONSENT request <list name="friends"> <entry uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> <cs:consent-status>pending</cs:consent-status> </entry> </list>

B’s Permission Server A@example.com Relay B@example.com Add Recipient: B@example.com Pending REFER Refer-To: B@example.com?method=CONSENT 200 OK SUBSCRIBE Event: list-state 200 OK NOTIFY 200 OK CONSENT B@example.com Permission-Upload: uri-up’ Permission Document 202 Accepted

CONSENT Request Permission-Upload header field URI where to send a PUBLISH uploading the permission document Open issue: header field or part of the permission document?

B’s Permission Server A@example.com Relay B@example.com CONSENT B@example.com Permission-Upload: uri-up Permission Document 202 Accepted 200 OK SUBSCRIBE Event: grant-permission NOTIFY uri-up Permission Document

Grant-permission Event Package Uses XCAP-diff Open issue: should it use XCAP-patch as well? Open issue: client needs to delete permission documents Provides Permission document Permission Upload URI Open Issue: part of the permission document? <permit> <cp:rule id="1"> <cp:conditions> <cp:identity><cp:id entity="bob@example.org" scheme="sip"/></cp:identity> <cr:target><cp:id entity="alices-friends@example.com" scheme="sip"/></cr:target> <cr:sender><cp:any/></cr:sender> </cp:conditions> <cp:actions> <cr:trans-handling>pending</cr:trans-handling> </cp:actions> <cp:transformations/> </cp:rule> <upload>sip:upload@example.com</upload> </permit>

B’s Permission Server A@example.com Relay B@example.com CONSENT B@example.com Permission-Upload: uri-up Permission Document 202 Accepted SUBSCRIBE Event: grant-permission 200 OK NOTIFY uri-up Permission Document 200 OK PUBLISH uri-up Permission Document 200 OK NOTIFY 200 OK

Consent in REGISTRATION Not applicable when sip-outbound is used i.e., same connection to register and to receive traffic

A@example.com Registrar A@ws123.example.com SUBSCRIBE Event: reg-event 200 OK NOTIFY

Extension to reg-event New <consent-status> element <registration aor="sip:user@example.com" id="as9" state="active"> <contact id="76" state="active“ event="registered“ duration-registered="7322" q="0.8"> <uri>sip:user@192.0.2.1</uri> <cs:consent-status>pending</cs:consent-status> </contact> </registration>

A@example.com Registrar A@ws123.example.com SUBSCRIBE Event: reg-event 200 OK NOTIFY 200 OK REGISTER Contact: A@ws123.example.com Supported: consent-reg 202 Accepted Require: consent-reg Trigger-Consent: 123@registrar ?Refer-To=<A%40ws123.example.com> REFER 123@registrar Refer-To: A@ws123.example.com 200 OK

A@example.com Registrar A@ws123.example.com REFER 123@registrar Refer-To: A@ws123.example.com 200 OK CONSENT A@ws123.example.com Permission-Upload: uri-up Permission Document 202 Accepted PUBLISH uri-up Permission Document 200 OK NOTIFY 200 OK

Request-contained URI Lists The URI-list server maintains a list of URI for which it has permission If the request-contained list has one or mode URIs for which there is no permission, an error is returned

A@example.com URI-list Server INVITE B@example.com C@example.com 470 Consent Needed Trigger-Consent: 123@relay.example.com ?Refer-To=<B%40example.com> Call-Info: 456@Relay;purpose=list-state ACK

Open Issues Does a URI get added to the list just by arriving in a request? Alternatively, clients need to use XCAP

Way Forward WG items?