Download
presence authorization rules n.
Skip this Video
Loading SlideShow in 5 Seconds..
Presence Authorization Rules PowerPoint Presentation
Download Presentation
Presence Authorization Rules

Presence Authorization Rules

136 Vues Download Presentation
Télécharger la présentation

Presence Authorization Rules

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Presence Authorization Rules Jonathan Rosenberg Cisco Systems

  2. instanceID as a selector for person, device and service Class as a selector for person, service and device Added provide-all-attributes Moving away from substitution groups Note dangers of using <sphere> for sub-handling MIME type inherited from common policy No normative rules about when privacy processing happens, final document must conform to policy Anonymous case is only authenticated identities, describe how for SIP Added back draft-ietf-sip-identity details Schema definitions for <anonymous> into common policy Changes

  3. Detailed rules for sub-handling, including a new case Active to pending causes a NOTIFY, no reason Indicate which parts of a presence doc are always in the output Timestamp, basic status, contact and device ID Defined component-ID permission Degree to which contact URI and device ID are obfuscated Hashed Random each time Added provide-note Changes

  4. Issue #1: Blacklisting <again> • Folks continue to want to do things like • Give Bob and Judy access • Bill and Aki get denied • Everyone else requires confirmation • Blacklists are problematic • New identities are easy to mint • You need to constantly add new rules to deal with folks who mint new identities • Aki’s suggestion: <any> with domain exceptions?

  5. Issue #1 Proposal • Unauthenticated identities match rules with no conditions • Authenticated identities match <any-identity> • Except for anonymous (?) • Anonymous and authenticated matches <anonymous> • That’s it. Implications • Blacklists work only within a specific domain, by granting access to domain and adding exceptions • Matches todays models

  6. Issue #2: Glob Matching • Recently proposed by Paul • Please lets keep scope limited, I say no

  7. Issue #3: Filter-based sub-handling • Proposal to be able to say, “allow anyone to see just my basic status, but anyone else requires confirmation” • This is meaningless unless subscriber asks for basic info or more, and thus is in the territory of filters • Propose to not consider this at this time

  8. Issue #4: tel URI interactions • Paul?