1. Presence Authorization Rules Jonathan Rosenberg Cisco Systems

2. Changes 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 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 into common policy

3. Changes 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

4. Issue #1: Blacklisting 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: with domain exceptions?

5. Issue #1 Proposal Unauthenticated identities match rules with no conditions Authenticated identities match –Except for anonymous (?) Anonymous and authenticated matches 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?