Re: [Simple] Authorization Rules for groups

["Noga Tor" <[e-mail]>]

I have no problem with this approach. It seems very logical to me the
Presence XDMS will not have any knowledge of groups (RLS XDMS).

However, I have bumped into an OMA test fest use case, which implies that
such a connection should exist. I will append the text of the use case and
let me know what u think...

Presence-1.0-int-0123 Authorization management for groups

Test Case Id

Presence-1.0-int-0123

Test Object

UEs with Presence Source, Presence Watcher and XDMC functionality, Presence
Server, and Shared XDMS.

Test Case Description

Verify that a Presence Server can handle the Presence Rules document for
groups of watchers stored in the Shared XDMS.

*TEST CASE GOAL: *Verify that a UE, acting as a XDMC, can modify his
permissions for groups of watcher stored in the Shared XDMS, and the PS
handles these permissions properly.

Specification Reference

Refer to Appendix A

SCR Reference

Refer to Appendix A

Tool

N/A

Test Code

N/A

Preconditions

·         Equipment:

o        2 UEs (with User1, User2 credentials)

o        Presence Server

o        Presence XDMS

o        Shared XDMS

·         Prerequisite for this test:

o        In the Presence XDMS, the Presence Authorization Rules document
contains information that Group A is authorized to see any of the presence
information belonging to User1.

o        User2 is a member of Group A as defined by User1

o        UE2 capable of displaying presence information.

o        User1 and User2 will have a set of commonly supported Presence
elements.

o        User1 has no active publications.

o        User1 has the ability of changing the content of its Presence
Authorization Rules Document.

o        User2 has no active subscriptions.

Test Procedure

1.        User1 publishes presence information for all commonly supported
mandatory Presence elements.

2.        User2 subscribe to presence information from User1.

3.        User1 updates the Authorization Rules Document in PS XDMS to block
Group A to see his presence.

4.        User1 modifies the active presence information that has been
published.

Pass-Criteria

2.        UE2 display the presence information from User1.

4.        UE2 does not display any presence information from User1.

Thanks
Noga

On 8/22/06, Tschofenig, Hannes <[e-mail]> wrote:

> Hi Noga,
>
> we discussed the aspect of groups some time back.
>
> I recall that the conclusion was the following:
> (without searching through my mails)
>
> If you have a list of friends in your group then you would replace every
> entity in the group with the specific instance of the group.
>
> Here is an example: You have a group sip:[e-mail] that
> contains
> sip:[e-mail], sip:[e-mail] and sip:[e-mail]
>
> The rule set would contain these three identities rather than some
> identity for the entire group.
>
> You might argue about the performance improvement if you could just
> convey a single rule instead of multiple onces. Given that you might not
> update your rules every few seconds and that you might not have too many
> groups with the same authorization right it might not be so dramatic at
> the end.
>
> Do you see a problem with this approach?
>
> Ciao
> Hannes
> ________________________________
>
>        Von: Noga Tor [mailto:[e-mail]]
>        Gesendet: Dienstag, 22. August 2006 14:38
>        An: [e-mail]
>        Betreff: [Simple] Authorization Rules for groups
>
>
>        Hi
>
>        I was wondering if there is any way to define an authorization
> rule that will apply to (RLS) contact list groups?
>
>        For example:
>        Presentity Alice (sip:[e-mail]) has defined an RLS
> contact list called Alice-friends (sip:[e-mail] ).
>        Is it possible for Alice to define a policy sinlge rule that
> will apply to all members of group "Alice-friends"?
>
>        I have looked at the draft document detailing the presence
> policy rules
> (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-11
> .txt
> <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-11
> .txt> ).
>        I have found no evidence that such an action is possible. the
> rule allows only the "one" or "many" options. Neither of these options,
> (to my understanding) can be applied to such an RLS group and the only
> option is to define each and every presentity in its own "one" tag.
>
>
>        I would appreciate your prompt respnose.
>
>
>        Thanks a lot
>        Noga
>
>

_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple