Subject: RE: [Sip] Event Lists: Back-End Credentials

From: [email-masked]
Date: Thu, 28 Oct 2004 17:35:25 +0300

I didn't know that communication with IESG is one way only. Can the IESG member who is blocking this explain why this cannot be outside the scope of this document?

Anyway, so how about an XCAP usage document that is carried signed and encrypted to the server using HTTP. That xcap usage document can include realm, username and password for realms that the user knows will be needed by the RLS.

Note that this is useful not just for backend subscriptions, but also for any list usage we can think for that will result in backend requests being sent on behalf of a client.

A server needing a secret key to use on behave of a user can look in the XCAP document of that user.

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: 28.October.2004 17:16
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Sip] Event Lists: Back-End Credentials
> 
> 
> [email-masked] wrote:
> 
> > Why isn't it enough to say that the way an watcher passes 
> the key to 
> > the RLS is outside the scope of this document?
> 
> 
> Because that's exactly what the document says right now, and the IESG 
> won't let it pass as a result.
> 
> 
> /a
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David R Oran <[email-masked]>
Date: Thu, 28 Oct 2004 11:16:45 -0400

On Oct 28, 2004, at 10:35 AM, [email-masked] wrote:

> I didn't know that communication with IESG is one way only. Can the 
> IESG member who is blocking this explain why this cannot be outside 
> the scope of this document?
>
> Anyway, so how about an XCAP usage document that is carried signed and 
> encrypted to the server using HTTP. That xcap usage document can 
> include realm, username and password for realms that the user knows 
> will be needed by the RLS.
>
That's precisely the problem. Now the RLS can impersonate the user and 
do anything the user could.

> Note that this is useful not just for backend subscriptions, but also 
> for any list usage we can think for that will result in backend 
> requests being sent on behalf of a client.
>
Can I be your RLS server? Please? Pretty please?

Dave.

>> won't let it pass as a result.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]