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

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

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
>

---

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

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

Brian