Subject: RE: [Simple] Another idea for presence authorization

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Jul 2001 14:43:46 -0400

I think we are agreeing that you can subscribe without
authorization.  I think we agree that you don't get any
Notifies unless you are authorized.

I do note in Jonathan's text that he used 202 for the
actual presence subscription acceptance, but 200 for
watcherinfo.  I don't quite understand that - it seemed
to be either an information leak, or some kind of a typo.

We could hold a discussion on DoS.  The issue is which is 
better - lots of subscriptions that succeed, or lots of
subscriptions that silently fail?  If you explicitly fail
(not authorized), information leaks - not good.

Brian

> -----Original Message-----
> From: Daniel Starin [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 2:37 PM
> To: 'Rosen, Brian'
> Cc: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [Simple] Another idea for presence authorization
> 
> 
> If I understand correctly,  you and Jonathan have come to a consensus
> that an initial Notify (specifying presence information) 
> should be given
> without authorization?  This seems to me to be similar to the 
> AIM model
> in which user A may add user B to a buddy list without authorization.
> User B may later set a specific policy on user A (like blocking them).
> 
> If this is the case,  I disagree with both of you and I believe that
> rfc2779 (the presence requirements) does as well.  It specifies.. "The
> principle controlling a PRESENTITY MUST be able to control which
> WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By
> allowing any random watcher to access even one Notify without
> authorization, this requirement is not met...
> 
> Dan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of 
> Rosen, Brian
> Sent: Friday, July 13, 2001 1:46 PM
> To: 'Daniel Starin'
> Cc: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [Simple] Another idea for presence authorization
> 
> Daniel
> 
> I suppose it's a matter of semantics, but I would claim 
> that you change authorization to change what information is revealed.
> Whether you do it before subscription, or after it, 
> you are changing your authorization.
> 
> I also think you made my point.  Authorization is complex,
> and standardizing it, at this time, is unwise.
> 
> Of what use is it to the PS if I give it a yes/no,
> and don't give it a what?  So you can accept the
> subscription but not send a Notify?  Not interesting
> methinks.  Besides, as you observe, even yes/no is really 
> transient (yes, at the moment, but I could change my mind).  
> All the more reason to get it out of the protocol.
> Even Jonathan proposes to accept the subscription without
> authorization.
> 
> We are talking about a complex interaction between the watcher
> and the PS as well as the presentity and the PS.  Until
> there is a much greater degree of consensus on how that
> interaction takes place, I don't see the value in
> specifying any of it.  Jonathan wants to standardize a simple
> yes/no authorization so that it can be done in the GUI of
> B's UA, and not take a browser.  I think that such an idea
> is far too limiting to be useful, and encourages lowest
> common denominator thinking.  It doesn't even give you
> the basic notion of presenting the name of the watcher - 
> all you get is the existing SIP headers, which would in
> many cases be a cryptic email identifier.  I'd much rather
> go the other direction and start talking about sending
> an XML credential in the authorization request, and an
> XML policy in the authorization reply.
> 
> BTW, I wanted to make sure that everyone agrees that
> authorization is not authentication;  if the PS requires
> authentication for the subscription (and it ought to),
> then authentication must take place before the subscribe
> will be acted upon.  All authorization is dealing with is
> what B will let you see, and it ranges from nothing to
> a lot.  Authentication is proving to the satisfaction
> of the PS that you are who you claim to be.
> 
> Brian
> 
> > -----Original Message-----
> > From: Daniel Starin [mailto:[email-masked]]
> > Sent: Friday, July 13, 2001 1:05 PM
> > To: 'Daniel Starin'; 'Rosen, Brian'
> > Cc: 'Jonathan Rosenberg'; [email-masked]
> > Subject: RE: [Simple] Another idea for presence authorization
> > 
> > 
> > Revised.... I hit send by accident...
> > 
> > The difference is, when I authorize someone, the way that I interact
> > with them may change throughout the time that the 
> subscription exists.
> > One minute I may want them to see detailed presence (IN / OUT /
> > AWAY / BUSY) while the next minute I may want them to see OUT 
> > regardless
> > of what my actual presence is.  The fact is, for the most 
> part, these
> > decisions are based on what is happening currently, not what happens
> > when the request for the subscription takes place.  At the time of
> > request, all that is usually known is Yes, you may subscribe, 
> > or no, you
> > may not.  If you happen to know that you also want to give 
> > the person a
> > specific type of presence (IN / OUT) at that time than so be it, you
> > can (after you have said Yes to their subscription).  But 
> many times,
> > you will not know specifically how you want your presence to be
> > distributed to those that subscribe to you at the moment they 
> > request a
> > subscription.
> > 
> > Thus a Yes/No authorization should be specified.  Possibly a "what"
> > should be specified as well but these two things should be distinct.
> > 
> > As for credentials.  I agree that some form of credentials must be
> > specified for Yes / No authorization...
> > 
> > Dan
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]] 
> > Sent: Friday, July 13, 2001 12:05 PM
> > To: 'Daniel Starin'
> > Cc: 'Jonathan Rosenberg'; [email-masked]
> > Subject: RE: [Simple] Another idea for presence authorization
> > 
> > I don't agree.  Authorization is specific - who and what.
> > You can't split it up like that, or at least there is very
> > little value in doing so.  If I gave you a standardized way
> > to say yes/no, but don't give you a standardized way to
> > specify what, the implementation is just as proprietary.
> > 
> > Also don't forget the credentials part.  In order to even say
> > yes/no, you need the credentials.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Daniel Starin [mailto:[email-masked]]
> > > Sent: Friday, July 13, 2001 11:59 AM
> > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'
> > > Cc: [email-masked]
> > > Subject: RE: [Simple] Another idea for presence authorization
> > > 
> > > 
> > > Brian,
> > > 
> > > It seems that there are two different issues you are discussing.  
> > > 
> > > One is whether or not A (the watcher) may access any of 
> B's presence
> > > information (a binary decision) and the other is IF B indeed 
> > > allows A to
> > > access presence information, what type of information will 
> > that be, -
> > > In/Out, In / Busy/Out, etc.
> > > 
> > > Regardless of what complex presence information a user may 
> > have, there
> > > will always be an initial binary decision (yes, you can 
> > > access presence
> > > or no, you cannot).  Because this decision must always be 
> > > made for each
> > > and every subscription request which is made, it may be 
> > reasonable to
> > > standardize how this will be done.
> > > 
> > > -Dan
> > > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of 
> > > Rosen, Brian
> > > Sent: Friday, July 13, 2001 10:44 AM
> > > To: 'Jonathan Rosenberg'
> > > Cc: [email-masked]
> > > Subject: RE: [Simple] Another idea for presence authorization
> > > 
> > > Let's start over.
> > > 
> > > A and B are both UAs.  I think we all agree on that.
> > > You want a PS.  I'll agree they are useful.  If you
> > > want a PS, then its a UAS to A.  I want to talk
> > > about how PS and B interact.
> > > 
> > > I don't know if you would allow me to go there, but,
> > > just for a moment, indulge me and let's talk about
> > > A and B without PS.  A wants to know B's presence.
> > > Okay, so A subscribes to B, and B supplies
> > > presence as NOTIFYies.  This all works fine, although
> > > it ignores how B authorizes A.  In particular,
> > > in order for B to authorize A, he needs credentials
> > > for A (who are you).  While the standard SIP headers
> > > might be enough, in many cases, you need more 
> > > information about A.  How do you get that?
> > > 
> > > With my example, everything (except credentials) is
> > > fine.  In particular, B can send presence to A
> > > because it's really B (B's real UA) that is the
> > > source of the presence info, and we would all agree
> > > that B the human interacts with B's UA in some
> > > implementation dependent manner for B's UA to
> > > find out the actual presence state.
> > > 
> > > Are we okay here?
> > > 
> > > Now let's put in the PS.  In your model, just for now,
> > > skip authorization, and let's just talk about how
> > > B tells PS that B's presence state changed.
> > > I can see two possibilities.  The one I like is that
> > > PS subscribes to B's presence.  The other is that
> > > there is a new header that is used for that purpose.
> > > My way is real simple, takes no extension, and does
> > > exactly what you want.  When B changes his presence,
> > > he does so on his UA (exactly as above), and Notifies
> > > PS.  PS, in turn, Notifies A.  Simple, clean, effective.
> > > 
> > > So what is PS?  I claim it's a straightforward
> > > B2BUA.  Instead of subscribing directly to B, PS
> > > subscribes to B and A (as well as any other authorized
> > > watchers) subscribe to PS.
> > > 
> > > Now, you introduce watcherinfo.  I'm okay with that.
> > > B subscribes to watcherinfo on PS, and PS Notifies B
> > > of subscriptions.  
> > > 
> > > Now, back to authorization
> > > 
> > > In several posts, I've stated that I'm interested in a
> > > rich notion of presence.  That covers a LOT of territory,
> > > but let me give you a small example.  Suppose I have
> > > 3 states in my presence model In-Busy-Out.  For
> > > some watchers, I will give them one of these three
> > > states.  However, there are some people for whom I
> > > don't want them to know that I'm in, but busy.  They
> > > only get two states - In/Out.  This is all pretty easy
> > > stuff. 
> > > 
> > > However, my authorization is not binary.  I have to
> > > tell PS which of the two models A gets.  Two URLs
> > > are not enough.
> > > 
> > > So, authorization, I claim, is complex.  You need
> > > arbitrary credentials from A, and you need arbitrary outputs
> > > from B. Thus, I claim, there is no sensible way to define the
> > > authorization process between B and PS, or for that
> > > matter, between A and PS in a standardized way.
> > > 
> > > One way to help would be to at least tell A where 
> > > to go to at least FIND OUT how to get authorization.  
> > > Simply subscribing (attempting to subscribe) is not enough.
> > > If you want to turn that around and say, fine, let's
> > > also tell B how to authorize, I can't argue.
> > > 
> > > Brian
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > > Sent: Friday, July 13, 2001 10:03 AM
> > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)';
> > > > [email-masked]'; Ben Campbell
> > > > Cc: [email-masked]
> > > > Subject: RE: [Simple] Another idea for presence authorization
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:[email-masked]]
> > > > > Sent: Wednesday, July 11, 2001 2:25 PM
> > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)';
> > > > > [email-masked]'; Ben Campbell
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [Simple] Another idea for presence authorization
> > > > > 
> > > > > 
> > > > > Well, I'm real confused.  
> > > > > 1. The "automata" you are talking about -- I don't understand
> > > > > what role it has in the context of this discussion.  We have
> > > > > "servers" that have presence information and "clients" that
> > > > > want to get it.  The server is an entity operating on 
> > behalf of a
> > > > > presentity.  The client is an entity operating on behalf of a 
> > > > > watcher.  In
> > > > > SIP terms, we have a UAC and a UAS.  
> > > > 
> > > > Its more complex than that, Brian. 
> > > > 
> > > > I'll repeat the picture I just sent in a previous email:
> > > > 
> > > > 
> > > > 
> > > >          |                  |                      |
> > > >          |                  |SUB B's pres.winfo (1)|
> > > >          |                  |<---------------------| B's 
> > > > client turns on
> > > >          |                  |200 OK             (2)|
> > > >          |                  |--------------------->|
> > > >          |                  |NOTIFY             (3)|
> > > >          |                  |--------------------->|
> > > >          |                  |200 OK             (4)|
> > > >          |                  |<---------------------|
> > > >          |                  |                      |
> > > >          |SUB B's pres  (5) |                      |
> > > >          |----------------->|                      |
> > > >          |202 Accepted   (6)|                      |
> > > >          |<-----------------|NOTIFY "A Pending" (9)|
> > > >          |NOTIFY B's pres(7)|--------------------->|B 
> > learns that A
> > > >          |<-----------------|200 OK            (10)|      
> > subscribed
> > > >          |200 OK         (8)|<---------------------|
> > > >          |----------------->|                      |
> > > >          |                  |                      |
> > > >          |                  |                      |
> > > >          |                  |Set policy        (11)|
> > > >          |                  |<---------------------|
> > > >          |                  |                      |
> > > >          |                  |                      |
> > > >          |                  |                      |
> > > >          |                  |                      |
> > > > 
> > > >       Subscriber          Presence              Presentity
> > > >          A                Server                   B
> > > > 
> > > > > The UAS
> > > > > is the agent of the presentity, and the UAC is the agent of
> > > > > the watcher.  Now, where is this automata?  In the UAS?
> > > > > The UAS is what the protocol defines, you seem to want to deal
> > > > > with something that is not the UAS but is connecting to it.
> > > > 
> > > > There is a presence server, which is a UAC for some 
> > > > transactions, and UAS
> > > > for others. There is a subscriber A, which is a UAC for some 
> > > > transactions
> > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a 
> > > presentity
> > > > application for B, which is a UAC for some transactions 
> > > > (SUBSCRIBE to its
> > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a 
> > > > per transaction
> > > > role. The presence server is the "agent" for B, in the sense 
> > > > that it accepts
> > > > subscribes and generates notifies on B's behalf. How it finds 
> > > > out about the
> > > > presence state is another orthogonal piece, not specified in 
> > > > the SUB/NOT
> > > > mechanism. Typically, its through registrations or through 
> > > > direct upload of
> > > > a presence document.
> > > > 
> > > > 
> > > > > 
> > > > > At the moment, the model I'm imagining in your head is one
> > > > > where the presentity and the watcher are both UACs and there
> > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger
> > > > > idea.  If that is the model you are pushing, I want to push
> > > > > back.  The UAC is the agent of the presentity, the UAS is the
> > > > > agent of the watcher, and the UAC doesn't need any protocol
> > > > > to the presentity -- it "is" the presentity.  
> > > > 
> > > > I cannot map these statements to sensible definitions of 
> > > UAC and UAS,
> > > > presentity or watcher. Please see above.
> > > > 
> > > > > If you want
> > > > > the presentity to be a UAC, then we need more than what we
> > > > > are talking about on this thread - we need to standardize
> > > > > how the UAC at the presentity tells the UAS how to change its
> > > > > presence, and then we get into all sorts of issues about 
> > > > > how this model supports rich presence information (since it
> > > > > requires that two UACs AND the UAS all have the same
> > > > > capabilities).  How the UAC interacts with the presentity
> > > > > is not the place we standardize.  It could be split into
> > > > > a "client" and a "server", but the interactions between those
> > > > > pieces are complex, and I don't see how we could standardize
> > > > > them right now.
> > > > 
> > > > I still cannot understand any of the above based on the 
> > > > definitions of UAC
> > > > and  UAS in the bis spec, and presentity, watcher, etc. 
> > > from rfc2778.
> > > > 
> > > > > 
> > > > > 2. I never used Yahoo Messenger.  I just loaded it.
> > > > > Yes, you get a message when someone puts you in his
> > > > > friend list.  However, what it is asking you seems to be
> > > > > whether you want to put him in YOUR buddy list.  In 
> particular,
> > > > > if you reject, you are still in his friend list, and he sees
> > > > > your presence. 
> > > > 
> > > > No, thats not true. When I subscribe to someone, they appear 
> > > > in my buddy
> > > > list, and the status is marked as "pending authorization" 
> > > > until the time
> > > > that they provide authorization. Once that happens, I see 
> > their real
> > > > presence. On the other side, when someone subscribes to me, I 
> > > > get a screen
> > > > pop, which asks for "approve", "approve and add", or "reject".
> > > > Approve/reject have the meanings we've been discussing - they 
> > > > approve or
> > > > reject the subscription. "approve and add" approves the 
> > > > subscription, and
> > > > also sends a subscription from me back to them, adding them 
> > > > to my buddy
> > > > list. 
> > > > 
> > > > I've been using this tool for several years. I think I can 
> > > make these
> > > > statements with soem confidence that they are correct.
> > > > 
> > > > -Jonathan R.
> > > > ---
> > > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > > Chief Scientist                             First Floor
> > > > dynamicsoft                                 East 
> Hanover, NJ 07936
> > > > [email-masked]                     FAX:   
> (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: 
> (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > > 
> > > _______________________________________________
> > > simple mailing list
> > > [email-masked]
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Daniel Starin" <[email-masked]>
Date: Fri, 13 Jul 2001 14:57:40 -0400

That’s the thing... I think Jonathan says that an initial notify will be
sent in step 7 of his diagram.... "NOTIFY B's pres"..... before
authorization... as far as I can tell.  I agree with his diagram in that
policies should be set at any time... but I think that initial notify
needs some authorization....

Dan

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, July 13, 2001 2:44 PM
To: 'Daniel Starin'
Cc: 'Jonathan Rosenberg'; [email-masked]
Subject: RE: [Simple] Another idea for presence authorization

Brian