1 / 8

Presence Authorization Rules

Presence Authorization Rules. Jonathan Rosenberg Cisco Systems. 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.

krom
Télécharger la présentation

Presence Authorization Rules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related