Consent Framework draft-ietf-sipping-consent-framework-02.txt

1
Consent Frameworkdraft-ietf-sipping-consent-frame
work-02.txt

• Gonzalo.Camarillo_at_ericsson.com

2
Changes

• Fundamental architectural change
• Consent applies when users are added to a
  translation at a relay
• Not when the translation is executed at the relay
• Like in an email mailing list
• Decoupled
• Requesting for permission
• Amplification avoidance
• Credit-based approach

3
User A adds User B
Relay
User A
User B
4
User A Consumes Some Bandwidth
Relay
User A
User B
5
The Relay Sends a CONSENT
Relay
User A
User B
6
User B Uploads a Permission Document to the Relay
Relay
User A
User B
7
Adding Two Users
8
Authentication Model

• Return routability
• CONSENT carries an unguessable (e.g., long and
  random) URI
• The PUBLISH needs to be sent to that URI
• The only entity that knows the URI is the
  recipient of the CONSENT
• SIP identity can be used if available

9
Simplification

• The relay is always the one that sends the
  CONSENT
• Allows for an easy migration from return
  routability to SIP identity
• Assume that endpoints cannot sign their
  permission documents

10
Simplification (cont.)

• Simple mechanism for Inter-domain scenarios
• A different mechanism to deal with your registrar
  (e.g., CPL)

11
Permission Document Format

• Target
• Relay performing the translation
• Sender
• Needed for relays that handle request-contained
  URI lists
• Recipient
• Operations
• Methods

12
Permission Revocation

• Upload an empty permission document to the relay