[OpenSIPS-Devel] Add X-XCAP-Preferred-Identity header to XCAP clients

[Thiago Rondon]

Iñaki,

In this scenario that you said, alice could fetch bob's icon store in 
the XCAP server by authentication as alice, how the security roles works?

For example, if you can just give access to alice to see bob's icon if 
alice in the 'whitelist' of presence-rules.xml ?

Thanks!
-Thiago Rondon

Iñaki Baz Castillo escreveu:
> Hi, authorization in IETF's pure XCAP is not defined. This is: a XCAP request 
> doesn't identify the originator but just the requested user's document.
>
> A too much simplistic workaround is requiring authentication for all the 
> requests and just allow the request if the credentials username matches the 
> request XUI.
>
> However this is not valid for some cool XCAP applications as fetching users' 
> icon (alice couldn't fetch bob's icon stored in the XCAP server as alice 
> cannot authenticate as bob).
>
> As I sad above, IETF didn't manage it. Instead there are some solutions born 
> in OMA, 3GPP and so...
>
> The solution is adding an identity header in the client request identifying 
> the desired identity (SIP or TEL URI), so the server would ask authentication 
> based on  the identity rather than on the XUI. This would allow the server to 
> authorize alice (after authentication) to access bob's icon.
>
> This header can be:
>
>   X-XCAP-Preferred-Identity
>     and/or
>   X-3GPP-Preferred-Identity
>
> In OMA architecture, where there is an aggregation proxy in front of the XCAP 
> servers, the proxy authenticates the client and asserts its identity by adding 
> "X-XCAP/3GPP-Asserted-Identity" (some mechanism as in pure SIP protocol).
>
> I've already implemented it in my Ruby XCAP client library (version 1.2):
>   http://dev.sipdoc.net/projects/ruby-xcapclient/news
>
> I suggest to include it in other XCAP clients (AG's Python xcapclient, 
> sipsimpleclient, Blink...).
>
> Regards.
>
>  
>
>