Subject: RE: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions]

From: [email-masked]
Date: Tue, 23 Mar 2004 23:02:46 +0200

Henning,

I mean exceptions in the scope of whom a rule should apply to. Comments inline:

Henning Schulzrinne wrote:
> 
> I don't understand this comment. Black lists can easily be 
> implemented 
> by splitting them across domains. This is just a syntactic 
> transformation.
> 

As I understand it there is more to it. This is from the latest geopriv common policy draft:

---
   No all-except conditions: It is not possible to express exclusion
      conditions based on identities such as "everybody except Alice".
      However, this restriction does not prevent all forms of
      blacklisting. It is still possible to express an authorization
      rule like 'I allow access to my location information for everyone
      of domain example.com except for John'. See the example in section
      Section 7.1 describing how exceptions can be made work.
---

So it is to my understanding impossible for instance to provide presence to everyone except an enumerated list of identities. This is usually what black-listing means.

> The note issue ('different information') is a more 
> interesting one. We 
> had earlier decided not to support lying, so this seems to 
> refer only to 
> free-form fields like 'note'. 

Well, lying can be done simply by publishing false information. I guess you mean that it wouldn't be allowed to provide user X with contradicting information compared to user Y (more accuracy seems to be fine). I think this is a feature that has some usefulness beyond just note.

> The problem you note can be 
> solved within 
> the framework by an ordering mechanism that associates a value with a 
> parameter. That way, the highest ("best") value would be picked, but 
> only one, instead of all. I think the easiest would be to 
> associate an 
> ordering with 'class' and just have the publisher upload different 
> tuples. I don't think it makes sense to use the policies to 
> set actual 
> presence values.
> 

I think this is a very good idea, and would solve this particular problem. There would just need to be a mechanism how to express the ordering within "class". "class" itself is going to need more specifying, since currently it is hard to use it among multiple PUAs.

> Exceptions greatly complicate the processing and, in conjunction with 
> external lists, are privacy-unsafe. Thus, I'm opposed to 
> including such 
> mechanisms. 

I suppose you mean now exceptions only, not the "class" ordering you just proposed yourself?

> Since people mean many different things when they 
> talk about 
> exceptions, it would be helpful if you could actually state 
> an exception 
> rule that you envision.
> 

Presentity has presence tuples A, B, C. (let's say B and C are otherwise the same, but have a different "note") 
He wants to enforce the following policy:
- Provide tuples A and B to everyone except Joe and Frank
- Provide tuples A and C to Frank (note, not B)
(Joe gets nothing)

Very simple, practical, and realistic - yet undoable with the current drafts.

> Henning

Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple