icon application

[adigeo]

Allow end-users to store their photo in the xcap server. The photo can then be referred in an icon element of a pidf.

Example:

 http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/icon.png

• Any filename is possible.
• The format must be png at 256x256 pixels.

Public access: Anyone can do GET without being challenged with 401.

Write access: PUT is 401-ed, only the owner can write it.

Use  http://tools.ietf.org/html/rfc4482 to publish the link to it.

[ibc]

The format must be png at 256x256 pixels.

Note that RFC 4482 says:

3.4.  Icon Element

   The <icon> element provides a URI pointing to an image (icon)
   representing the tuple or person.  The watcher can use this
   information to represent the tuple or person in a graphical user
   interface.  Presentities SHOULD provide images of sizes and aspect
   ratios that are appropriate for rendering as an icon.  Support for
   JPEG, PNG, and GIF formats is REQUIRED.

Example:  http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/icon.png

Public access: Anyone can do GET without being challenged with 401.

At least, the file name could be modified by OpenXCAP when it's received by the client. It could be a random name (qjewgiuasdiqwekjhasd.png) so just the allowed subscribers could get it. If not, anyone could get an user icon by accessing to:

 http://xcap.example.com/xcap-root/icon/users/sip:user@domain.com/icon.png

[adigeo]

Inaki,

I believe that it is up to the client to randomize the filename part so that the picture file name is not easy to guess. If the server changes the filename without client consent, the client does not know anymore what to put in the icon element because is the client who builds the URL not the server. If the server changes the URL, the client has no way to find out what the new name is.

So if I am client that desires privacy I should generate:

/RandomString.png and put that on the server and the <icon> element

What is wrong with this?

[ibc]

Yes, I understand. However, perhaps is not so easy to get the file name randomized from the client. What about if the server stores the original filename and lets, *just to the authenticated or IP trusted user*, access to it by using it (instead of the modified name)?

[adigeo]

How come is not easy to get a filename randomized by a client? It takes half a line of code to do that.

Do you have a feasible alternative?

Can you expand on how an XCAP could on its own determine who is allowed to perform a HTTP GET URL from the Internet because it received via SIP NOTIFY a PIDF body with <icon> element set to that URL? How do you authenticate such requests or who provisions per icon file a floating IP that can change per HTTP request?

[ibc]

How come is not easy to get a filename randomized by a client? It takes half a line of code to do that.

Yes, you are right. Since there are not implementations yet doint it, it could be easy to recommend new implementatioins to randomize the image name.

Can you expand on how an XCAP could on its own determine who is allowed to perform a HTTP GET URL from the Internet because it received via SIP NOTIFY a PIDF body with <icon> element set to that URL? How do you authenticate such requests or who provisions per icon file a floating IP that can change per HTTP request?

My fault. The GET request is exactly the same when comming from the owner of the image or from anyone in Internet. Sorry, I'm too used to SIP and forget that HTTP doesn't use "From" header XD

[ibc]

Hi, here there is how OMA has specified such XCAP application:

"Presence Content XDM Specification":  http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf

[adigeo]

Thanks for the pointer.

[adigeo]

Regarding the authorization part, this is where OMA, again made the step to the abyss of infinite complexity for solving little with infinite cost.

In the OMA document it seems that the XDM server is suppose to perform authorization for fetching the icon document based on a X-3GPP-Intended-Identity: "sip:ronald.underwood@example.com" header present in the GET request. As this request and its headers are generated by a remote client, potentially in a foreign domain upon which the XCAP server has no control, I do not see how this be reliable performed over the public internet as that header can be simply be generated by the client.

This could work only in a walled garden when all XCAP clients and their behaviour are under the control of the operator. Probably in the architecture of the authors, the xcap client is a closed solution controlled directly by operator X, all requests go via his HTTP proxy, which is re-writing the XCAP request by inserting a new header and forwards it to the foreign domain. Plenty of space for 'rich-presence' enabled SBCs in the middle OMG.

[ibc]

I do not see how this be reliable performed over the public internet as that header can be simply be generated by the client.

Well, if this specification would be written by IETF it would say "authorizing the user is out of the scope of this specification". X-D

For sure, using a random filename (chosen by the client) is a much better and reliable solution, and it would work out of the scope of operator's private IP network.

[saul]

Implemented icon application. A testing script can be found on the sipsimple client:  http://sipsimpleclient.com

[tpatja]

Hello,

Is OMA content-XDM 1.0 spec compliant content-XDM support done or on the roadmap ? With a recent version of OpenXCAP, an xcap-caps query does not list pres-content or org.mobilealliance.pres-content in the auids list.

Thanks in advance, teemu