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

[[e-mail]]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On 
> Behalf Of ext
> Adam Roach
> Sent: 26.October.2004 09:06
> To: [e-mail]
> Cc: Jonathan Rosenberg
> Subject: [Sip] Event Lists: Back-End Credentials
> 
> 
> After a discussion with Dean about some of the issues surrounding the 
> back-end credential issue that I raised earlier on the list, I struck 
> upon a solution that might get us past this logjam.
> 
> The lynch pin to this solution is that the RLS does not ever 
> pretend to 
> be the user. Instead, it always subscribes as its own 
> identity. It can 
> present credentials as necessary to authenticate itself, but only as 
> itself, not as its subscribers.
> 
> A consequence of this is that, lacking any other mechanism, the 
> resources in a resource list for which the RLS is not 
> authoritative will 
> contain only the information that their notifier is willing 
> to reveal to 
> the RLS -- which is generally the same information they would 
> render to 
> unauthenticated users. In some cases, this might result in no useful 
> information being transferred.

This limitation by itself kills the idea, IMO. Most presence lists will rely on the event list, and if its gonna mean that no useful information will come to the watcher, then the whole mecahnism is useless.

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? We have certainly made such assumptions in the past.

We can suggest HTML. We can suggest an email being sent to the administrator. We can even suggest an XCAP usage document, but I don't understand why the draft needs to define that explicitly.

/Hisham

> 
> Of course, the resource would still be present in the RLMI document; 
> this gives the subscriber the *option* to directly subscribe to any 
> resources for which the RLS is not authoritative. To facilitate the 
> client's ability to perform such subscriptions, the RLMI 
> documents would 
> be enhanced with a flag which indicates whether the RLS is 
> authoritative 
> for the resource.
> 
> Finally, we would mention in the document that future work 
> may define a 
> mechanism by which the subscriber can pass the RLS an authorization 
> token; the RLS could include this token in requests to show 
> that it has 
> been authorized by the user to send SUBSCRIBE messages for arbitrary 
> resources on the user's behalf (mostly likely for a limited 
> time period).
> 
> Of the solutions we've seen so far, I think this one is the cleanest 
> from a security perspective. Further, it will almost 
> certainly allow us 
> to progress the draft now, and separate the delegation 
> problem so that 
> it can be solved in a way that works well with the other identity and 
> authentication work currently underway (and might even be reusable in 
> other applications, such as dial-out conference bridges).
> 
> Thoughts?
> 
> /a
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

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