I don't have a strong opinion one way or another, but I think 
the point is that we decide, and document it.

It's not clear to me why the first method (3rd party authentication) is
"a bad idea" and the second one (3rd party registration) is a good one.
Can you clarify why it's bad?

I *think* (I could be wrong) the 3rd party authentication would be supported
by any UA today that supports a separate "Authorization name" (or "realm auth" 
or
whatever it is called). In contast, I haven't seen many UAs supporting 3rd 
party registration.

Furthermore, in 3261, your would assume that the username in the credentials
be the same as the userinfo part of the To header (3261/26.3.2.1). In what you 
are
describing here for 3rd party registration, in contast, you are using for the 
username, 
the userinfo of the From header. 

In other words, any way we choose to go, we are changing the way you'd normally 
expect 
authentication to work.

Anyways, to summarize: I don't have a strong opinion. Just pick one, and 
document
it in the draft. I think leaving it open to interpretation will cause 
interoperability
issues.

----

PS:

Finally, for the last case in your email, i.e., From/To/Http-digest-credentials 
= HelpDesk,
we are in 100% agreement. That's also what we have done. We should describe it 
in the text.



> -----Original Message-----
> From: Alan Johnston [mailto:[email protected]] 
> Sent: Thursday, July 16, 2009 11:48
> To: Audet, Francois (SC100:3055)
> Cc: Venkatesh; Hutton, Andrew; [email protected]
> Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances: 
> Provisioningconsiderations
> 
> So you are proposing that Bob would register like this:
> 
> REGISTER
> To: <sip:[email protected]>
> From: <sip:[email protected]>
> 
> but when challenged, provide the credentials for user Bob 
> instead of the HelpDesk?  This seems like a bad idea to me.  
> Why isn't this 3rd party
> registration:
> 
> REGISTER
> To: <sip:[email protected]>
> From: <sip:[email protected]>
> 
> And when challenged, Bob provides his credentials.  The 
> Registrar is provisioned to allow Bob to register against 
> HelpDesk and everything works.  Alternatively, you could have 
> Bob register using:
> 
> REGISTER
> To: <sip:[email protected]>
> From: <sip:[email protected]>
> 
> But he will need to have the credentials for HelpDesk when challenged.
> 
> Anyway, we and other vendors already implement this feature 
> this way, so the draft must support it.  A given system can 
> choose not to use it.
> 
> Thanks,
> Alan
> 
> Francois Audet wrote:
> > Well, yes.
> >  
> > However, as per my email, that's not the only alternative.
> >  
> > You could use "user=alice" for authentication in HTTP 
> digest if, for 
> > whatever reason, you prefer to have users authenticating as 
> themselves 
> > instead of using the shared appearance. That advantage is 
> that users 
> > don't need to know 2 username/passwords. The disadvantage 
> is that you 
> > need more infrastructure in the back-end to allow Alice to 
> log in as 
> > Boss with her own credential.
> >  
> > I was thinking that both model should be allowed. Like in most SIP 
> > client today, you can put a different HTTP credential (if required).
> > Otherwise, it would default to the one used for registering 
> (i.e., the 
> > From).
> >  
> > So in both cases, there is no 3rd party registration per se (as per 
> > the definition in 3261).
> >  
> > That was my thought
> >
> >     
> --------------------------------------------------------------
> ----------
> >     *From:* Venkatesh [mailto:[email protected]]
> >     *Sent:* Wednesday, July 15, 2009 09:36
> >     *To:* Audet, Francois (SC100:3055)
> >     *Cc:* Hutton, Andrew; Alan Johnston; [email protected]
> >     *Subject:* Re: [BLISS] draft-ietf-bliss-shared-appearances:
> >     Provisioningconsiderations
> >
> >     Sure, but it means the secretary is now using HelpDesk 
> (or "boss"
> >     in the example) credentials to register if you didn't have 3rd
> >     party registration semantics?
> >
> >     Venkatesh
> >
> >     On Wed, Jul 15, 2009 at 9:29 AM, Francois Audet 
> <[email protected]
> >     <mailto:[email protected]>> wrote:
> >
> >         Yes, of course HelpDesk could be the Boss instead.
> >
> >             
> --------------------------------------------------------------
> ----------
> >             *From:* Venkatesh [mailto:[email protected]
> >             <mailto:[email protected]>]
> >             *Sent:* Wednesday, July 15, 2009 08:46
> >             *To:* Hutton, Andrew
> >             *Cc:* Audet, Francois (SC100:3055); Alan Johnston;
> >             [email protected] <mailto:[email protected]>
> >             *Subject:* Re: [BLISS]
> >             draft-ietf-bliss-shared-appearances:
> >             Provisioningconsiderations
> >
> >             Andrew:
> >
> >             Thanks for pointing it out. I missed the change as well.
> >             Honestly, one of the main use cases for BLA/SLA was to
> >             address a boss/secretary scenario. In these cases, the
> >             secretary is really monitoring a "Boss" 
> extension; so from
> >             a "ownership" purpose, the AoR is really that 
> of the boss
> >             and not a "common" address.
> >
> >             Venkatesh
> >
> >             On Wed, Jul 15, 2009 at 3:53 AM, Hutton, Andrew
> >             <[email protected]
> >             <mailto:[email protected]>> wrote:
> >
> >
> >                 Indeed this getting interesting.
> >
> >                 In version -02 the REGISTER in section 10.1 showed a
> >                 normal 1st party
> >                 registration by alice but -03 shows a third party
> >                 registration which is
> >                 a significant change.
> >
> >                 I must admit I missed the text in -02 which stated
> >                 "Bob and Alice are in
> >                 an appearance group identified by Alice's AOR. Bob
> >                 REGISTERs using
> >                 contact sip:[email protected]
> >                 <mailto:sip%[email protected]>" and I 
> should have
> >                 commented on that
> >                 earlier.
> >
> >                 As the draft is about sharing appearances 
> of a single
> >                 AOR then surely
> >                 third party registration is not necessary 
> as it could
> >                 be that there is
> >                 simply two helpdesk phones using a single AOR and
> >                 there is no "alice" or
> >                 "bob" AOR's. So in the simplest case the REGISTER
> >                 would be:
> >
> >                   REGISTER sip:registrar.example.com
> >                 <http://registrar.example.com> SIP/2.0
> >                   Via: SIP/2.0/UDP ua1.example.com
> >                 
> <http://ua1.example.com>;branch=z9hG4bK527b54da8ACC7B09
> >                   From: <sip:[email protected]
> >                 
> <mailto:sip%[email protected]>>;tag=CDF9A668-909E2BDD
> >                   To: <sip:[email protected]
> >                 <mailto:sip%[email protected]>>
> >                   CSeq: 2 REGISTER
> >                   Call-ID: d3281184-518783de-cc23d6bb
> >                   Contact: <sip:[email protected]
> >                 <mailto:sip%[email protected]>>
> >
> >                 Regards
> >                 Andy
> >
> >
> >                 >-----Original Message-----
> >                 >From: [email protected]
> >                 <mailto:[email protected]>
> >                 [mailto:[email protected]
> >                 <mailto:[email protected]>]
> >                 >On Behalf Of Francois Audet
> >                 >Sent: 14 July 2009 23:30
> >                 >To: Alan Johnston
> >                 >Cc: [email protected] <mailto:[email protected]>
> >                 >Subject: [BLISS] 
> draft-ietf-bliss-shared-appearances:
> >                 >Provisioningconsiderations
> >                 >
> >                 >
> >                 >> > Section 9:
> >                 >> >
> >                 >> > Delete first paragraph.
> >                 >> >
> >                 >> > Clarify the UA also REGISTERs to the 
> AOR. Discuss the
> >                 >> security implications, i.e.,
> >                 >> > you either use the same shared 
> username/password,
> >                 or you
> >                 >> use a different username/password
> >                 >> > for HTTP digest, per user. Perhaps the security
> >                 >> considerations can be described in section 15.
> >                 >> >
> >                 >> >
> >                 >>
> >                 >> I added text about authorization for third party
> >                 registrations and
> >                 >> publication.  A little more text on this would be
> >                 helpful.
> >                 >
> >                 >Ah-ah... Now we are getting down to business.
> >                 >
> >                 >I am now looking at new section 10.1 on 
> registration,
> >                 and I see that
> >                 >you are using indeed third-party registration (with
> >                 To=HelpDesk,
> >                 >From=Alice).
> >                 >
> >                 >So, this would be one way to to it.
> >                 >
> >                 >Another way would be to NOT use third-party
> >                 registration at all. In
> >                 >other words, Alice would send a first party
> >                 registration on behalf
> >                 >of HelpDesk (ie.., To=HelpDesk, From=Alice).
> >                 >
> >                 >Wouldn't that work?
> >                 >
> >                 >Then there is the whole issue of 
> authentication with
> >                 HTTP-Digest.
> >                 >I guess one could use username="HelpDesk". In this
> >                 case, the
> >                 >idea is that
> >                 >Alice would need to know the credentials 
> for HelpDesk.
> >                 >Another way would be to use 
> username="alice" instead
> >                 (i.e.,
> >                 >her own credentials).
> >                 >The decisions on which authentication you use would
> >                 depend on
> >                 >need of the
> >                 >administrator.
> >                 >
> >                 >Have you tought about this? Am I off based?
> >                 >_______________________________________________
> >                 >BLISS mailing list
> >                 >[email protected] <mailto:[email protected]>
> >                 >https://www.ietf.org/mailman/listinfo/bliss
> >                 >
> >                 _______________________________________________
> >                 BLISS mailing list
> >                 [email protected] <mailto:[email protected]>
> >                 https://www.ietf.org/mailman/listinfo/bliss
> >
> >
> >
> 
> 
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss

Reply via email to