Subject: 10.4 IDENTIFY Command

From: [email-masked]
Date: Wed, 6 Nov 2002 18:37:46 -0500

In trying to match earlier issues w/the latest draft I ran across this 
one.  The 09-submitted draft says:

   The CS determines through an internal mechanism if the credentials
   supplied at authentication permit the operation as the selected
   identity.

and this implys that whatever credentials (UPN??) I originally 
authenticate with determines if I can change my identity later on AND to 
which identities I can change to.  This seems a bit restrictive as it 
basically puts the onus on the CS implementors to know in a priori not 
only what identities can authenticate w/the CS but also what identities 
they can assume.

So, in order for my new AA to be able to assume my identity its not a 
matter of her proving it by some (re)authentication mechanism, its an 
issue of making sure my CS is configured w/this information somehow (the 
actual mechanism appears to be TBD).  Unfortunately since we have no 
Administrative kinds of features like this spec'd in CAP 1.0 (at least not 
that Ive found yet) isnt this a kind of chicken and egg problem that will 
bite us in the butt at our first CAP interop??  There has to be a better 
way....

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Andrea Campi <[email-masked]>
Date: Thu, 7 Nov 2002 01:50:40 +0100

On Thursday, November 7, 2002, at 12:37 AM, [email-masked] 
wrote:
> issue of making sure my CS is configured w/this information somehow 
> (the actual mechanism appears to be TBD).  Unfortunately since we have 
> no Administrative kinds of features like this spec'd in CAP 1.0 (at 
> least not that Ive found yet) isnt this a kind of chicken and egg 
> problem that will bite us in the butt at our first CAP interop?? 
>  There has to be a better way....
>

Sorry but I don't get your point. After all, we do use SASL, so we have 
separate autentication and authorization information available. 
Administration and storage of AAA is out of scope; everybody is free to 
keep the info in whatever kind of store they prefer.

Again, probably I'm not understanding what you're worried about...

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Wed, 06 Nov 2002 18:15:56 -0700

> only what identities can authenticate w/the CS but also what identities 

Just curious, do you feel the the CS should ask the CUA if the
user has permission? Or are you saying that the CS should not
do it internally?

> Administrative kinds of features like this spec'd in CAP 1.0 (at least 
> not that Ive found yet) isnt this a kind of chicken and egg problem that 
> will bite us in the butt at our first CAP interop??  There has to be a 
> better way....

Do you have a proposal that will allow one CUA to inform a CS
'trust me' I have permission?

-- 
-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:15:01 -0500

> user has permission? Or are you saying that the CS should not

I think that we have a disjoin in our design WRT IDENTIFY.  The CU can 
configure the CUA w/a list of identities to try and switch to but the CS 
has the final authority over allowing or disallowing the actualy IDENTIFY 
command to succeed or not.  As such I think that there should be some way 
for the CUA to get the list of 'alternate' or assumable identities from 
the CS.

Otherwise my CUA just has to take the list its configured w/and try to see 
if the CS will allow the change.  Its possible that the list of, say, 20 
alternate identities my AA has (she's also the team AA) does not jive 
w/the CS's derived list of allowable identities.  So her CUA just keeps 
going "I want to change my identity to UPN2", "I want to change my 
identity to UPN3", etc. 

It would be MUCH simpler if the CUA had a way to get the list from the CS. 
 That way it could cut down on extra network traffic AND it could do 
something nice in the UI like indicate "You are not authorized to assume 
UPN3 and UPN6 that you have configured."

At one point early on in CAP we had the design that the CS would return 
back the 'primary' UPN that the CUA was assuming and we had discussed the 
possibility of sending back the list of alternate UPNs.  It seems to me 
that this never got resolved (I didnt check, I have 500+ msgs to wade thru 
still) but I think we should do it.  If not at authentication time (not 
everyone will change identities) then via a command of some kind.

> 'trust me' I have permission?

You misread my concern.  I think the CUA should have a way to get the list 
of allowable identities from the CS, not push a list to the CS.  That 
would be "administration" stuff and not something on the list of 
discussable topics for 1.0.

Bruce

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:05:03 -0500

> separate autentication and authorization information available. 

Yes we do but we do not have any clear way to get that information to the 
CUA.  That is, there is no clear proscribed way for the CUA to "discover" 
what credentials they may use as inputs for the IDENTIFY command.  A long 
time ago a suggestion was made about resolving this disjoin.

One suggestion was to have the CS always return the UPN and other 
identities (UPNs) that were assumable when the CUA authenticated.  Another 
was to have some command that a CUA could use to query "What other 
identities can I assume based on my authenticated credentials?" in case 
they actually wanted to do it (Most non-AA types wont really need to do it 
really).  I dont think either got any WG discussion.

I just find it somewhat cumbersome to provide a command to change UPNs but 
we have no clear and interoperable way to get them from the CS.  After all 
the CS uses some undefined voodoo to decide if I can change my identity so 
the CUA must either play Marco Polo to figure out what I can actually 
change my identity to (even if my CUA were given the list by the CU in 
some dialog, the CS does not necessarily agree w/that list!) OR I just 
have to expect that some OOB mechanism is in play to make sure that 
whatever my AA configures her CUA with is also configured on the CS...

> Again, probably I'm not understanding what you're worried about...

Does this make it clearer?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Nov 2002 12:08:16 -0700

[email-masked] wrote:
> has the final authority over allowing or disallowing the actualy 
> IDENTIFY command to succeed or not.  As such I think that there should 
> be some way for the CUA to get the list of 'alternate' or assumable 
> identities from the CS.

We agreed a long time ago that user administration is out of scope
in this version if CAP.

 >...

> back the 'primary' UPN that the CUA was assuming and we had discussed 
> the possibility of sending back the list of alternate UPNs.  It seems to 
> me that this never got resolved (I didnt check, I have 500+ msgs to wade 
> thru still) but I think we should do it.  If not at authentication time 
> (not everyone will change identities) then via a command of some kind.

Yes - and we dropped it when we concluded that it was user administration.

 > ...
--

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Nov 2002 12:12:05 -0700

[email-masked] wrote:
> Yes we do but we do not have any clear way to get that information to 
> the CUA.  That is, there is no clear proscribed way for the CUA to 
> "discover" what credentials they may use as inputs for the IDENTIFY 
> command.  A long time ago a suggestion was made about resolving this 
> disjoin.

Yes - join the SASL WG and make SASL extensions :-)

That's a whole new protocol and we agreed that user administration
is out of scope. I don't see any reason that there can not be a
separate draft written and proposed to add that functionality.

--

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:39:59 -0500

> Yes - join the SASL WG and make SASL extensions :-)

Eh?  So now its no longer an administrative issue, its a SASL extension 
thats undefined?? %^|

Im curious how a CS implementation is to derive a UPN from _any_ SASL or 
CAP or (insert alternate plan here) authentication/authorization mechanism 
and use it for the CAP session if that feature/ability is "administration" 
and as such not defined in CAP 1.0?  That seems to be deemed 
"administration" and as such not defined in CAP 1.0.  Guess we just dont 
authenticate at all OR some magical voodoo happens in a per-CS 
implementation to derive some set of UPNs in any manner each sees fit 
which may result in different UPNs being generated for the same set of 
inputs...  Just what I want in a protocol designed to promote 
interoperability.

Ok, a bit of sarcasm creeping in due to more than a little frustration so 
Ill take a deep breath and try again...

Still no answer I can grok here: Why is having the CS return a list of 
UPNs to the CUA after authentication/authorization has taken place 
considered "administration" or a "SASL" thing?  If the CS has the list of 
UPNs it will allow me to assume using the IDENTIFY command then why is it 
that it cannot provide me that list on demand?  Ahh, I get it; "That would 
be telling..."

> separate draft written and proposed to add that functionality.

Let me say this again until it sinks in: Im am not, repeat _NOT_, talking 
about the CUA doing anything to change the list in any fashion!  (Ok so 
far??)  Im talking about having the ability for the CUA to simply read the 
list from the CS so that it can better use the IDENTIFY command w/o having 
to guess at what the CS will or will not allow. (Whew, I hope I didnt 
loose anyone there with such a complex concept.)

FMI: Why is this not the "IDENTITY" command since the CUA is changing the 
identity they are operating as??

Bruce

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:27:35 -0500

> We agreed a long time ago that user administration is out of scope

Yes we did but this concern is NOT administration; its a usability issue!! 
 I am _NOT_ talking about having the CUA somehow administer the list; Im 
talking about it getting the list so it can use it for the IDENTIFY 
command (and for any CUA side GUI-isms it wants/needs).

I have said before and Ill say it again: There should be some consistant 
way for a CUA to get a list of identities that it can change to. Otherwise 
the CUA is just playing Marco Polo trying to see what UPNs the CS will let 
it switch to!

We had this ability early on when the CS returned the 'primary' UPN and a 
list of other assumable UPNs as part of either authentiation or some other 
process (I dont have my very early CAP draft markups still...).  I do not 
see this in CAP now and I think it should be there still; I never saw any 
talk of removing that feature/ability so why did it disappear?

> Yes - and we dropped it when we concluded that it was user 
administration.

Got a thread reference?  I dont recall that discussion and I certainly 
disagree w/that conclusion. 

If the CUA is only reading the list from the CS I dont see how anyone can 
claim that its an administrative function w/a straight face.  Thats like 
saying reading my calendar is administrative so we may as well drop that 
too...

Bruce

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:27:35 -0500

Bruce

---

From: [email-masked]
Date: Tue, 12 Nov 2002 10:39:59 -0500

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Thu, 14 Nov 2002 18:19:40 +0100

> time ago a suggestion was made about resolving this disjoin.
[...]
> Does this make it clearer?

[I just came back from a few days' vacation and I'm slowly catching up]

Yes now it's clear. I agree some mechanism for discovering allowed
identities would be useful, but I also see Doug has some reason in
calling this 'administration' - as in CUA, not CS, administration.

After all, this comes into play when you authorize somebody to act
as your attendee; since the way you do this is out of scope for CAP,
it could be argued that anything more complex than you telling your
attendee what the right identity is, is out of scope too.
Also, your argument would also extend to: once you are authenticated,
how do you discover which UPNs you are authorized to access? Should
your CUA search for them and apply VCAR (I hope not) or will it try
accessing all of them and see what the CS replies? IMHO, some amount
of client administration will be needed no matter what.

This is not to say I'm against adding such a mechanism; on the
contrary, I think it would be great (and in fact we need it or
everybody will implement something like this in different ways).
It's just that I don't think we MUST do it NOW (maybe we can start
right now to prepare a separate RFC? I have no idea).

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Mon, 18 Nov 2002 13:30:12 -0500

> as your attendee; since the way you do this is out of scope for CAP,

Correct.  Im NOT discussing that aspect of authentication/authorization.

> attendee what the right identity is, is out of scope too.

Currently even that is not done (but used to in earlier drafts).

Since the CUA is only reading the list from the CS I dont buy the argument 
that its Administration in that sense.  If I were talking about modifying 
the list or suggesting a list to the CS then I would agree w/that but Im 
not. 

I also dont recall any WG traffic discussing this as Administration and 
thus dropable from CAP and I disagree w/it.  Getting info like that from 
the CS is not administration any more than reading my calendar entries is 
administration...

The CS has to have a list of acceptable identities that a CUA can assume 
based on the authentiation process (kinda sorta since authentication is 
not the same as that authorization but thats a digresson).  As such I dont 
see a strong reason for the CS to _not_ be able to provide that to the CUA 
so that a CUA does not have to play guessing games when using the IDENTIFY 
command. 

As a matter of design simplicity I think its better to take a more 
structured approach as it makes building more robust CUAs possible.  If 
given the option to either guess at which identities will work and which 
wont or get an accurate list from the other side, I know which is cleaner 
IMHO.

> how do you discover which UPNs you are authorized to access? 

The CS had determined the list it will allow and that is what Im trying to 
get it to return to the CUA if the CUA wants it.  It was part of our 
earlier designs and Doug claims the WG agreed to remove it.  I certainly 
didnt see that discussion nor do I agree w/its removal.

>                                                             Should

Not sure what your VCAR question is but I can address the CUA bit. 

Sure, the CU may configure their CUA w/a list of identies that they expect 
to be able to assume using the IDENTIFY command.  However this list may or 
may not match what the CS determines to be allowed.  My CUA can try try to 
assume all the assorted identities configured in it with the CS accepting 
or failing the command.  My argument is that instead of having my CUA try 
identities the CS will not allow (w/o even any response way to say why it 
was rejected) it would be simpler if my CUA could ask the CS for the list 
and then do something nifty in the UI like gray out those that are not 
allowed, etc.  That way no failed IDENTIFY commands happen; no playing 
guessing games between the CUA and CS.  The CUA may know what the CU 
_wants_ and it can find out what the CS _will_allow_ and thus bridge the 
discrepancy in some nice or easy manner.

> everybody will implement something like this in different ways).

Great.

> right now to prepare a separate RFC? I have no idea).

I would really like to see it in CAP 1.0 since it was in earlier so 
restoring the appropriate text should not be that difficult. 

Bruce