1. 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

2. 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

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

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

5. Permission Document Example
<cp:rule id="1">
<cp:conditions>
<cp:identity>
<cp:id scheme="sip"/>
</cp:identity>
<target>
<cp:id scheme="sip"/>
</target>
<sender>
<cp:any/>
</sender>
</cp:conditions>
<cp:actions>
<trans-handling>allow</trans-handling>
</cp:actions>
<cp:transformations/>
</cp:rule>

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

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

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

9. 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
<display-name>Bill Doe</display-name>
<cs:consent-status>pending</cs:consent-status>
</entry>
</list>

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

11. 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?

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

13. 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 scheme="sip"/></cp:identity>
<cr:target><cp:id 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>
</permit>

14. B’s Permission Server A@example.com Relay B@example.com
CONSENT 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

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

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

17. Extension to reg-event
New <consent-status> element
<registration id="as9" state="active"> <contact id="76" state="active“ event="registered“ duration-registered="7322" q="0.8"> <cs:consent-status>pending</cs:consent-status> </contact> </registration>

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

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

20. 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

21. A@example.com URI-list Server INVITE B@example.com C@example.com
470 Consent Needed Trigger-Consent: ?Refer-To=<B%40example.com> Call-Info:
ACK

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

23. Way Forward
WG items?