WO2009133419A1

WO2009133419A1 - Method, apparatus, and computer program product for providing a group based decentralized authorization mechanism

Info

Publication number: WO2009133419A1
Application number: PCT/IB2008/001044
Authority: WO
Inventors: Sasu Tarkoma; Jilles Van Gurp; Vlad Alexandru Stirbu; Christian Prehofer
Original assignee: Nokia Corporation; Nokia, Inc.
Priority date: 2008-04-28
Filing date: 2008-04-28
Publication date: 2009-11-05

Abstract

An apparatus for enabling group based authorization and service discovery in a decentralized network may include a processor. The processor may be configured to receive a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, and provide the certificate to the device in response to the request. The request may be received from a device in a decentralized network. The certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

Description

PC

METHOD, APPARATUS, AND COMPUTER PROGRAM PRODUCT FOR PROVIDING A GROUP BASED DECENTRALIZED AUTHORIZATION

MECHANISM

TECHNOLOGICAL FIELD

Embodiments of the present invention relate generally to network communication technology and, more particularly, relate to a method, apparatus and computer program product for providing group based authorization and service discovery in a decentralized network.

BACKGROUND

The modern communications era has brought about a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks are experiencing an unprecedented technological expansion, fueled by consumer demand. Wireless and mobile networking technologies have addressed related consumer demands, while providing more flexibility and immediacy of information transfer.

Current and future networking technologies continue to facilitate ease of information transfer and convenience to users. One area in which there is a demand to increase the ease of information transfer and convenience to users relates to provision of information sharing in decentralized networks. A decentralized network may generally be considered a network that operates in a distributed environment rather than a centralized control environment. Thus, network resources such as processors, memory, switching devices, etc., may be distributed throughout the network instead of being centralized at one location (e.g., a server or server bank). As such, for example, various devices may come and go from the network at random times making certain resources and/or services

-1 - AttyDktNo: 042933/343025 available on a somewhat intermittent basis. A peer-to-peer (P2P) network is one example of a decentralized network. P2P networks rely primarily on the computing power and bandwidth of the devices or nodes (i.e., peers) within the network. Accordingly, P2P networks generally do not concentrate computing power and bandwidth within servers.

In a typical decentralized network, a user associated with a device entering the network may wish to make a service supported by the device available via the network. Alternatively, the user may wish to discover services that are available via the network. Services being offered via the network, however, may be associated with protected resources or at least a device offering certain services may have some resources associated therewith for which protected access to those resources may be desired. Accordingly, certain mechanisms have been developed to mediate access to protected resources or provide an open authentication mechanism. OpenID and OAuth are two examples of protocols that have been developed for use in connection with open authentication. These protocols are based on the redirection feature of current web browsers, but do not address authorization.

OpenID is a shared identity service that allows Internet users to log on to different web sites using a single digital identity. Thus, users may not need a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide. OAuth is also an open protocol that allows secure application programming interface (API) authentication. OAuth allows a user to grant access to the user's private resources on one device to another entity, where, in some instances, the device may be associated with on particular entity. OAuth also enables a user to give access to information without necessarily sharing all of that user's identity. However, although these protocols generally work well for authenticating one client with a fixed service, a fixed service is not necessarily available in a decentralized network. Accordingly, conventional authentication protocols may not be serviceable in a decentralized network without an extensive amount of overhead being added to such systems, particularly when authorization of large numbers of service entities are involved.

-2- AttyDktNo: 042933/343025 001044

Given the ubiquitous nature of mobile terminals, such as mobile phones and numerous other mobile electronic devices, distributed networks are becoming more common. In this regard, smart spaces and other out-of-the-box, zero configuration environments are becoming desirable for enhancing user experiences such that users may enter into an environment and join a decentralized network to share or use resources without configuration set up overhead that requires extensive user involvement.

Accordingly, it may be desirable to provide an improved mechanism for enabling authorization and service discovery in a decentralized network.

BRIEF SUMMARY

A method, apparatus and computer program product are therefore provided for enabling group based authorization and service discovery in a decentralized network. Thus, it may be possible to improve security in relation to decentralized network resources, while still providing a positive user experience. As such, for example, users may interact with other entities on a decentralized network in an environment that, although distributed, still affords security and/or privacy and resource protection. Furthermore, group based security may support efficient one- to-many operations in a secure environment. In one exemplary embodiment, a method of enabling group based authorization and service discovery in a decentralized network is provided. The method may include receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, and providing the certificate to a device in response to the request. The request may be received from the device in a decentralized network. The certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

In another exemplary embodiment, an apparatus for enabling group based authorization and service discovery in a decentralized network is provided. The apparatus may include a processor configured to receive a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, and provide the certificate to a device in response to the request. The request may be received from the device in a decentralized network. The

-3- AttyDktNo: 042933/343025 certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

In another exemplary embodiment, a computer program product for enabling group based authorization and service discovery in a decentralized network is provided. The computer program product may include at least one computer-readable storage medium having computer-executable program code portions stored therein. The computer-executable program code portions include first and second program code portions. The first program code portion is for receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier. The second program code portion is for providing the certificate to a device in response to the request. The request may be received from the device in a decentralized network. The certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

In another exemplary embodiment, an apparatus for enabling group based authorization and service discovery in a decentralized network is provided. The apparatus may include means for receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, and means for providing the certificate to a device in response to the request. The request may be received from the device in a decentralized network. The certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

In another exemplary embodiment, a method of utilizing group based authorization and service discovery in a decentralized network is provided. The method may include receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network, providing the certificate to another device in the decentralized network as evidence of membership in the group, receiving an assertion of membership in the group from the other device, and performing mutual authentication and authorization with the other device based on mutual membership in the group.

-4- AttyDktNo: 042933/343025 In another exemplary embodiment, an apparatus for utilizing group based authorization and service discovery in a decentralized network is provided. The apparatus may include a processor configured to receive a certificate indicative of an assertion of membership in a group defined by a resource identifier in which the certificate is received from a third party device in a decentralized network, provide the certificate to another device in the decentralized network as evidence of membership in the group, receive an assertion of membership in the group from the other device, and perform mutual authentication and authorization with the other device based on mutual membership in the group. In another exemplary embodiment, a computer program product for utilizing group based authorization and service discovery in a decentralized network is provided. The computer program product may include at least one computer-readable storage medium having computer-executable program code portions stored therein. The computer-executable program code portions include first, second, third and fourth program code portions. The first program code portion is for receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier. The certificate may be received from a third party device in a decentralized network. The second program code portion is for providing the certificate to another device in the decentralized network as evidence of membership in the group. The third program code portion is for receiving an assertion of membership in the group from the other device. The fourth program code portion is for performing mutual authentication and authorization with the other device based on mutual membership in the group.

In another exemplary embodiment, an apparatus for utilizing group based authorization and service discovery in a decentralized network is provided. The apparatus may include means for receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network, means for providing the certificate to another device in the decentralized network as evidence of membership in the group, means for receiving an assertion of membership in the group from the other device, and means for performing mutual authentication and authorization with the other device based on mutual membership in the group

-5- AttyDktNo: 042933/343025 Embodiments of the present invention may be employed, for example, in mobile terminals or other nodes, or in a network entity, in order to provide improved authentication and authorization capabilities between nodes in a decentralized network.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein: FIG. 1 is a schematic block diagram of a mobile terminal according to an exemplary embodiment of the present invention;

FIG. 2 is a schematic block diagram of a wireless communications system according to an exemplary embodiment of the present invention;

FIG. 3 illustrates a simple decentralized network according to an exemplary embodiment of the present invention;

FIG. 4 is a block diagram of an apparatus for enabling group based authorization and service discovery in a decentralized network according to an exemplary embodiment of the present invention;

FIG. 5 is a block diagram of an apparatus that may request group membership and share or use group resources according to an exemplary embodiment of the present invention;

FIG. 6 provides an example of communications that may occur in accordance with one exemplary embodiment of the present invention;

FIG. 7 provides an example of communications that may occur in accordance with another exemplary embodiment of the present invention in which multiple relying parties are provided;

FIG. 8 illustrates an example of how a uniform resource identifier can be used to define groups and how groups can be based on other groups;

FIG. 9 illustrates a publication of services to decentralized network according to an exemplary embodiment of the present invention;

FIG. 10 illustrates publication of services available to a subgroup of local smart space users according to an exemplary embodiment of the present invention;

-6- AttyDktNo: 042933/343025 FIG. 11 illustrates an example of searching for services available to a subgroup of local smart space users according to an exemplary embodiment of the present invention;

FIG. 12 illustrates an example of searching for services available to a user internet- wide according to an exemplary embodiment of the present invention;

FIG. 13 is a flowchart according to an exemplary method of enabling group based authorization and service discovery in a decentralized network according to one embodiment of the present invention; and

FIG 14 is a flowchart according to an exemplary method of utilizing group based authorization and service discovery in a decentralized network according to one embodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, embodiments of the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout.

FIG. 1, one exemplary embodiment of the invention, illustrates a block diagram of a mobile terminal 10 that would benefit from embodiments of the present invention. It should be understood, however, that a mobile telephone as illustrated and hereinafter described is merely illustrative of one type of mobile terminal that would benefit from embodiments of the present invention and, therefore, should not be taken to limit the scope of embodiments of the present invention. While several embodiments of the mobile terminal 10 may be illustrated and hereinafter described for purposes of example, other types of mobile terminals, such as portable digital assistants (PDAs), pagers, mobile televisions, gaming devices, laptop computers, cameras, video recorders, audio/video player, radio, GPS devices, or any combination of the aforementioned, and other types of voice and text communications systems, can readily employ embodiments of the present invention.

-7- AttyDktNo: 042933/343025 In addition, while several embodiments of the method of the present invention are performed or used by a mobile terminal 10, the method may be employed by other than a mobile terminal. Moreover, the system and method of embodiments of the present invention will be primarily described in conjunction with mobile communications applications. It should be understood, however, that the system and method of embodiments of the present invention can be utilized in conjunction with a variety of other applications, both in the mobile communications industries and outside of the mobile communications industries. The mobile terminal 10 may include an antenna 12 (or multiple antennas) in operable communication with a transmitter 14 and a receiver 16. The mobile terminal 10 may further include an apparatus, such as a controller 20 or other processing element, that provides signals to and receives signals from the transmitter 14 and receiver 16, respectively. The signals include signaling information in accordance with the air interface standard of the applicable cellular system, and also user speech, received data and/or user generated data. In this regard, the mobile terminal 10 is capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. By way of illustration, the mobile terminal 10 is capable of operating in accordance with any of a number of first, second, third and/or fourth-generation communication protocols or the like. For example, the mobile terminal 10 may be capable of operating in accordance with second-generation (2G) wireless communication protocols IS-136 (time division multiple access (TDMA)), GSM (global system for mobile communication), and IS-95 (code division multiple access (CDMA)), or with third-generation (3G) wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), CDMA2000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD- SCDMA), with 3.9G wireless communication protocol such as E-UTRAN, with fourth-generation (4G) wireless communication protocols or the like. As an alternative (or additionally), the mobile terminal 10 may be capable of operating in accordance with non-cellular communication mechanisms. For example, the mobile terminal 10 may be capable of communication in a wireless local area network (WLAN) or other communication networks described below in connection with FIG. 2.

-8- AttyDktNo: 042933/343025 It is understood that the apparatus, such as the controller 20, may include circuitry desirable for implementing audio and logic functions of the mobile terminal 10. For example, the controller 20 may be comprised of a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and other support circuits. Control and signal processing functions of the mobile terminal 10 are allocated between these devices according to their respective capabilities. The controller 20 thus may also include the functionality to convolutionally encode and interleave message and data prior to modulation and transmission. The controller 20 can additionally include an internal voice coder, and may include an internal data modem. Further, the controller 20 may include functionality to operate one or more software programs, which may be stored in memory. For example, the controller 20 may be capable of operating a connectivity program, such as a conventional Web browser. The connectivity program may then allow the mobile terminal 10 to transmit and receive Web content, such as location-based content and/or other web page content, according to a Wireless Application Protocol (WAP), Hypertext Transfer Protocol (HTTP) and/or the like, for example.

The mobile terminal 10 may also comprise a user interface including an output device such as a conventional earphone or speaker 24, a ringer 22, a microphone 26, a display 28, and a user input interface, all of which are coupled to the controller 20. The user input interface, which allows the mobile terminal 10 to receive data, may include any of a number of devices allowing the mobile terminal 10 to receive data, such as a keypad 30, a touch display (not shown) or other input device. In embodiments including the keypad 30, the keypad 30 may include the conventional numeric (0-9) and related keys (#, *), and other hard and soft keys used for operating the mobile terminal 10. Alternatively, the keypad 30 may include a conventional QWERTY keypad arrangement. The keypad 30 may also include various soft keys with associated functions. In addition, or alternatively, the mobile terminal 10 may include an interface device such as a joystick or other user input interface. The mobile terminal 10 further includes a battery 34, such as a vibrating battery pack, for powering various circuits that are required to operate the mobile terminal 10, as well as optionally providing mechanical vibration as a detectable output.

-9- AttyDktNo: 042933/343025 The mobile terminal 10 may further include a user identity module (UIM) 38. The UIM 38 is typically a memory device having a processor built in. The UIM 38 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), etc. The UIM 38 typically stores information elements related to a mobile subscriber. In addition to the UIM 38, the mobile terminal 10 may be equipped with memory. For example, the mobile terminal 10 may include volatile memory 40, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The mobile terminal 10 may also include other non- volatile memory 42, which can be embedded and/or may be removable. The non-volatile memory 42 can additionally or alternatively comprise an electrically erasable programmable read only memory (EEPROM), flash memory or the like, such as that available from the SanDisk Corporation of Sunnyvale, California, or Lexar Media Inc. of Fremont, California. The memories can store any of a number of pieces of information, and data, used by the mobile terminal 10 to implement the functions of the mobile terminal 10. For example, the memories can include an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying the mobile terminal 10. Furthermore, the memories may store instructions for determining cell id information. Specifically, the memories may store an application program for execution by the controller 20, which determines an identity of the current cell, i.e., cell id identity or cell id information, with which the mobile terminal 10 is in communication.

FIG. 2 is a schematic block diagram of a wireless communications system according to an exemplary embodiment of the present invention. Referring now to FIG. 2, an illustration of one type of system that would benefit from embodiments of the present invention is provided. The system includes a plurality of network devices. As shown, one or more mobile terminals 10 may each include an antenna 12 for transmitting signals to and for receiving signals from a base site or base station (BS) 44. The base station 44 may be a part of one or more cellular or mobile networks each of which includes elements required to operate the network, such as a mobile switching center (MSC) 46. As well known to those skilled in the art, the mobile network may also be referred to as a Base

-10- AttyDktNo: 042933/343025 Station/MSC/Interworking function (BMI). In operation, the MSC 46 is capable of routing calls to and from the mobile terminal 10 when the mobile terminal 10 is making and receiving calls. The MSC 46 can also provide a connection to landline trunks when the mobile terminal 10 is involved in a call. In addition, the MSC 46 can be capable of controlling the forwarding of messages to and from the mobile terminal 10, and can also control the forwarding of messages for the mobile terminal 10 to and from a messaging center. It should be noted that although the MSC 46 is shown in the system of FIG. 2, the MSC 46 is merely an exemplary network device and embodiments of the present invention are not limited to use in a network employing an MSC.

The MSC 46 can be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN). The MSC 46 can be directly coupled to the data network. In one typical embodiment, however, the MSC 46 is coupled to a gateway device (GTW) 48, and the GTW 48 is coupled to a WAN, such as the Internet 50. In turn, devices such as processing elements (e.g., personal computers, server computers or the like) can be coupled to the mobile terminal 10 via the Internet 50. For example, as explained below, the processing elements can include one or more processing elements associated with a computing system 52 (two shown in FIG. 2), origin server 54 (one shown in FIG. 2) or the like, as described below.

The BS 44 can also be coupled to a serving GPRS (General Packet Radio Service) support node (SGSN) 56. As known to those skilled in the art, the SGSN 56 is typically capable of performing functions similar to the MSC 46 for packet switched services. The SGSN 56, like the MSC 46, can be coupled to a data network, such as the Internet 50. The SGSN 56 can be directly coupled to the data network. In a more typical embodiment, however, the SGSN 56 is coupled to a packet-switched core network, such as a GPRS core network 58. The packet- switched core network is then coupled to another GTW 48, such as a gateway GPRS support node (GGSN) 60, and the GGSN 60 is coupled to the Internet 50. In addition to the GGSN 60, the packet-switched core network can also be coupled to a GTW 48. Also, the GGSN 60 can be coupled to a messaging center. In this regard, the GGSN 60 and the SGSN 56, like the MSC 46, may be capable of controlling the forwarding of messages, such as MMS messages. The GGSN 60

-1 1- AttyDktNo: 042933/343025 and SGSN 56 may also be capable of controlling the forwarding of messages for the mobile terminal 10 to and from the messaging center.

In addition, by coupling the SGSN 56 to the GPRS core network 58 and the GGSN 60, devices such as a computing system 52 and/or origin server 54 may be coupled to the mobile terminal 10 via the Internet 50, SGSN 56 and GGSN 60. In this regard, devices such as the computing system 52 and/or origin server 54 may communicate with the mobile terminal 10 across the SGSN 56, GPRS core network 58 and the GGSN 60. By directly or indirectly connecting mobile terminals 10 and the other devices (e.g., computing system 52, origin server 54, etc.) to the Internet 50, the mobile terminals 10 may communicate with the other devices and with one another, such as according to the Hypertext Transfer Protocol (HTTP) and/or the like, to thereby carry out various functions of the mobile terminals 10.

Although not every element of every possible mobile network is shown and described herein, it should be appreciated that the mobile terminal 10 may be coupled to one or more of any of a number of different networks through the BS 44. In this regard, the network(s) may be capable of supporting communication in accordance with any one or more of a number of first-generation (IG), second- generation (2G), 2.5G, third-generation (3G), 3.9G, fourth-generation (4G) mobile communication protocols or the like. For example, one or more of the network(s) can be capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, one or more of the network(s) can be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. Further, for example, one or more of the network(s) can be capable of supporting communication in accordance with 3G wireless communication protocols such as a UMTS network employing WCDMA radio access technology. Some narrow-band analog mobile phone service (NAMPS), as well as total access communication system (TACS), network(s) may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones).

-12- AttyDktNo: 042933/343025 The mobile terminal 10 can further be coupled to one or more wireless access points (APs) 62. The APs 62 may comprise access points configured to communicate with the mobile terminal 10 in accordance with techniques such as, for example, radio frequency (RF), infrared (IrDA) or any of a number of different wireless networking techniques, including WLAN techniques such as IEEE 802.11 (e.g., 802.1 Ia, 802.1 Ib, 802.1 Ig, 802.1 In, etc.), world interoperability for microwave access (WiMAX) techniques such as IEEE 802.16, and/or wireless Personal Area Network (WPAN) techniques such as IEEE 802.15, BlueTooth (BT), ultra wideband (UWB) and/or the like. The APs 62 may be coupled to the Internet 50. Like with the MSC 46, the APs 62 can be directly coupled to the

Internet 50. In one embodiment, however, the APs 62 are indirectly coupled to the Internet 50 via a GTW 48. Furthermore, in one embodiment, the BS 44 may be considered as another AP 62. As will be appreciated, by directly or indirectly connecting the mobile terminals 10 and the computing system 52, the origin server 54, and/or any of a number of other devices, to the Internet 50, the mobile terminals 10 can communicate with one another, the computing system, etc., to thereby carry out various functions of the mobile terminals 10, such as to transmit data, content or the like to, and/or receive content, data or the like from, the computing system 52. As used herein, the terms "data," "content," "information" and similar terms may be used interchangeably to refer to data capable of being transmitted, received and/or stored in accordance with embodiments of the present invention. Thus, use of any such terms should not be taken to limit the spirit and scope of embodiments of the present invention.

Although not shown in FIG. 2, in addition to or in lieu of coupling the mobile terminal 10 to computing systems 52 across the Internet 50, the mobile terminal 10 and computing system 52 may be coupled to one another and communicate in accordance with, for example, RF, BT, IrDA or any of a number of different wireline or wireless communication techniques, including LAN, WLAN, WiMAX, UWB techniques and/or the like. One or more of the computing systems 52 can additionally, or alternatively, include a removable memory capable of storing content, which can thereafter be transferred to the mobile terminal 10. Further, the mobile terminal 10 can be coupled to one or more electronic devices, such as printers, digital projectors and/or other multimedia capturing, producing

-13- AttyDktNo: 042933/343025 and/or storing devices (e.g., other terminals). Like with the computing systems 52, the mobile terminal 10 may be configured to communicate with the portable electronic devices in accordance with techniques such as, for example, RF, BT, IrDA or any of a number of different wireline or wireless communication techniques, including universal serial bus (USB), LAN, WLAN, WiMAX, UWB techniques and/or the like.

In an exemplary embodiment, content or data may be communicated over the system of FIG. 2 between a mobile terminal, which may be similar to the mobile terminal 10 of FIG. 1, and a network device of the system of FIG. 2 in order to, for example, execute applications or establish communication (for example, for purposes of content or information sharing) between the mobile terminal 10 and other mobile terminals. As such, it should be understood that the system of FIG. 2 need not be employed for communication between mobile terminals or between a network device and the mobile terminal, but rather FIG. 2 is merely provided for purposes of example. Furthermore, it should be understood that embodiments of the present invention may be resident on a communication device such as the mobile terminal 10, and/or may be resident on a server, personal computer or other device, absent any communication with the system of FIG. 2.

FIG. 3 illustrates a simple decentralized network according to an exemplary embodiment of the present invention. As shown in FIG. 3, the network may include a client device (e.g., client 66), a service provider (e.g., relying party 68), and a group management entity 69. The client 66 may be a client application operating at a fixed or mobile electronic communications device such as, for example, the mobile terminal 10 of FIG. 1. Meanwhile, the relying party 68 may be an application (e.g., a web application) that provides services for clients (e.g., consumers). In some embodiments, the services may be hypertext transfer protocol (HTTP) based services and, as indicated above, the environment in which such services are supplied may be a decentralized network formed of devices communicating via any suitable mechanism including, for example, those discussed above in connection with FIG. 2. The relying party 68 may also be associated with a fixed or mobile electronic communications device such as, for example, the mobile terminal 10 of FIG. 1.

-14- AttyDktNo: 042933/343025 The group management entity 69 may be, for example, a trusted service module running on a device associated with a trusted third party. The group management entity 69 may^* be configured to manage groups and provide a public application programming interface (API) for managing groups for authenticated parties. The group management entity 69 may therefore, in an exemplary embodiment, be an application operating on a fixed or mobile electronic communications device such as, for example, the mobile terminal 10 of FIG. 1. As such, the client 66, the relying party 68 and the group management entity 69 should each be understood to be respective roles that a given device may play in certain scenarios. Thus, it may be possible for a single device to operate in accordance with any of the corresponding roles described above in different scenarios. The client 66, the relying party 68 and the group management entity 69 may, along with other devices, be in communication with each other in a distributed environment to form a decentralized network. An exemplary embodiment of the invention will now be described with reference to FIG. 4, in which certain elements of an apparatus for enabling group based authorization and service discovery in a decentralized network are displayed. In an exemplary embodiment, the apparatus of FIG. 4 may represent one example of a device hosting the group management entity 69. However, the apparatus of FIG. 4 could also host the client 66 or the relying party 68. Thus, the apparatus of FIG. 4 may be embodied as or otherwise employed, for example, on a device such as the mobile terminal of FIG. 1 or a network device of FIG. 2. However, it should be noted that the apparatus of FIG. 4, may also be employed on a variety of other devices, both mobile and fixed, and therefore, embodiments of the present invention should not be limited to application on devices such as mobile terminals or servers. It should also be noted that while FIG. 4 illustrates one example of a configuration of an apparatus for enabling group based authorization and service discovery in a decentralized network, numerous other configurations may also be used to implement embodiments of the present invention. Referring now to FIG. 4, an apparatus for enabling group based authorization and service discovery in a decentralized network is provided. The apparatus may include or otherwise be in communication with a processor 70 (e.g., controller 20), a user interface 72, a communication interface 74 and a memory

-15- AttyDktNo: 042933/343025 device 76. The memory device 76 may include, for example, volatile and/or nonvolatile memory (e.g., volatile memory 40 and/or non-volatile memory 42). The memory device 76 may be configured to store information, data, applications, instructions or the like for enabling the apparatus to carry out various functions in accordance with exemplary embodiments of the present invention. For example, the memory device 76 could be configured to buffer input data for processing by the processor 70. Additionally or alternatively, the memory device 76 could be configured to store instructions for execution by the processor 70. As yet another alternative, the memory device 76 may be one of a plurality of databases that store information and/or media content.

The processor 70 may be embodied in a number of different ways. For example, the processor 70 may be embodied as various processing means such as a processing element, a coprocessor, a controller or various other processing devices including integrated circuits such as, for example, an ASIC (application specific integrated circuit) or an FPGA (field programmable gate array). In an exemplary embodiment, the processor 70 may be configured to execute instructions stored in the memory device 76 or otherwise accessible to the processor 70. Meanwhile, the communication interface 74 may be embodied as any device or means embodied in either hardware, software, or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device or module in communication with the apparatus. In this regard, the communication interface 74 may include, for example, an antenna and supporting hardware and/or software for enabling communications with a wireless communication network. The user interface 72 may be in communication with the processor 70 to receive an indication of a user input at the user interface 72 and/or to provide an audible, visual, mechanical or other output to the user. As such, the user interface 72 may include, for example, a keyboard, a mouse, a joystick, a touch screen display, a conventional display, a microphone, a speaker, or other input/output mechanisms. In an exemplary embodiment in which the apparatus is embodied as a server or some other network devices, the user interface 72 may be limited, or eliminated. However, in an embodiment in which the apparatus is embodied as a mobile terminal (e.g., the mobile terminal 10), the user interface 72 may include,

-16- AttyDktNo: 042933/343025 among other devices or elements, any or all of the speaker 24, the ringer 22, the microphone 26, the display 28, and the keyboard 30.

In an exemplary embodiment, the processor 70 may be embodied as or otherwise control a group manager 78. The group manager 78 may be any means such as a device or circuitry embodied in hardware, software or a combination of hardware and software that is configured to perform the corresponding functions of the group manager 78 as described herein. In this regard, the group manager 78 may be configured to execute group management functions such as group creation and group deletion. As an example, this may be accomplished with the following functions: create group (group URI, expiration time), and delete group (group URI). The group manager 78 may also be configured to execute other management functions such as adding elements (e.g., adding members) or deleting elements from a group (e.g., using functions: add element (group URI, key, expiration time), and delete element (group URI, key)). Group and or element creation may each be performed in combination with the issuance of a corresponding expiration time or date indicating a time at which the group or element may expire. In some embodiments, the group manager 78 may provide verification services related to inquiries regarding a group (e.g., verify(group URI(s), key)) and/or the group manager may provide assertion related information (e.g., get assertion(group URI, key).

Groups may be created as a result of an entity communicating a request to the group manager 78 regarding group creation. In response to authentication of the request, the group manager 78 may create the group by providing a uniform resource identifier (URI) for the group (e.g., a group URI). The entity requesting the creation of the group may be associated with the group as the owner of the group and may have capabilities with respect to the group that other entities may not be afforded. For example, in some cases, only the owner of the group may request deletion of the group or make changes to expiration times. Certain functions performed by the group manager 78 may involve or require the presentation or provision of a key or key value. The key may be, for example, a public key, a hash of a public key or another kind of identifier (e.g., an OpenID identifier). In an exemplary embodiment, each function performed by the group manager 78 may include a group URI to indicate the group with respect to which

-17- AttyDktNo: 042933/343025 the corresponding function is to be performed. Meanwhile, in some examples, keys may only be utilized or required in association with functions such as adding elements, deleting elements, verifying a group, and getting an assertion.

Access control for groups may be, for example, determined by the owner of the group at the time of group creation. However, access control may also be determined based on network rules or other considerations. In an exemplary embodiment, the group manager 78 may also be configured to manage group membership by enabling the addition of members to a particular group. In this regard, for example, after authentication of a perspective member, the group manager 78 may admit the perspective new member to the particular group (e.g., designate the perspective new member as a group member) based on an access class or access rules associated with the group. Once designated a member of the group, the designated member may be given a certificate, token or other indicia that may be used to provide an assertion of group membership to other entities. Group access classes may be either restrictive or relatively open. For example, open groups may admit any perspective new member, while restricted groups may require the owner to provide the perspective new member with permission to join the group upon authentication or a group specific password. Other access classes may have access requirements that are less extreme in relation to requirements (or lack thereof) such as by enabling open access to individuals who complete a computational puzzle or human interactive puzzle or enabling access after authentication of an individual (e.g., via OpenID or the like). The access rules or requirements for an access class may also be based on, for example, the location of a perspective new member (i.e., location based authorization), the date and/or time, aspects of the perspective new member's context (e.g., citizenship, residency, marital status, or the like), or aspects of a device associated with the perspective new member (i.e., current device settings, model number of the device, device communication characteristics, or the like). In some embodiments, the access rules or requirements for an access class may also be based on a perspective new member's memberships in other groups. When considering a perspective new member's memberships in other groups a combination of groups may be considered using, for example, boolean logic. As

-18- AttyDktNo: 042933/343025 such, group management functions may be multi-purpose and need not be tied to any user agent technology.

As indicated above, the group manager 78 may, when membership to a particular group is granted, provide the new group member with a certificate (e.g., a group assertion certificate or token) for use in asserting group membership to other entities. The certificate may include information that can be used by any entity that receives the certificate to determine whether or not the information may be trusted. Thus, if the entity decides to trust the information, the entity can then use the information to authorize any request that may be associated with the certificate. In an exemplary embodiment, the certificate may include information such as, for example, a subject of the assertion (identity, public key and/or URI), a group URI, a group manager public key, a timestamp and validity period, a signature over data included in a message using the group manager public key, or the like. In some embodiments, the group manager 78 itself may issue the certificate to entities seeking membership. However, as an alternative, the group manager 78 may include or otherwise be in communication with a token issuer 80 that may be any means such as a device or circuitry embodied in hardware, software or a combination of hardware and software that is configured to issue the assertion certificate or token to requesting entities as described above. As such, in some embodiments, the token issuer 80 may be included in or controlled by the processor 70 either directly or indirectly (e.g., via the group manager 78).

An entity receiving a group assertion certificate may then test whether or not the certificate is valid. As indicated above, since client, relying party and group manager may be roles that various different devices may play at different times or in different situations, the apparatus of FIG. 4 may also be an entity receiving a group assertion certificate or an entity to which an assertion is made (e.g., the client 66 or the relying party 68). In such situations, the apparatus of FIG. 4 may either further include (or include instead) various other devices or elements as shown, for example, in FIG. 5.

FIG. 5 illustrates a block diagram of an apparatus that may request group membership and share or use group resources according to an exemplary embodiment. In addition to common elements shared with the exemplary

-19- AttyDktNo: 042933/343025 embodiment of FIG. 4, the apparatus of FIG. 5 may include an assertion manager 82. The assertion manager 82 may be any means such as a device or circuitry embodied in hardware, software or a combination of hardware and software that is configured to obtain group membership to receive the above described certificate. The assertion manager 82 may also or alternatively be configured to make requests of other group members by asserting membership using an assertion based on the certificate and/or test the validity of an assertion made by another entity making a request to the assertion manager 82.

In an exemplary embodiment, testing validity of an assertion may include validation via various operations such as:

1. Testing the validity period of the certificate and if the certificate is expired, rejecting the certificate.

2. Reading the group manager public key and checking the validity of the signature. If invalid, the certificate may be rejected. 3. Reading the identity that is the subject of the assertion. If the identity provider is not known, the certificate may be rejected.

4. Any associated request should have a signature or other security information verifying the authenticity of the subject, which may also be tested. Typically this is a signature using the subject's private key that can be validated by the public key. In order to enable an entity to assert membership to a group, the initiator of a request (e.g., the entity asserting group membership) may include an assertion in a message including the request (e.g., via the assertion manager 82 of the initiator).

In one embodiment, the assertion may include the following information:

-Initiator public key, -Identity URI if applicable,

-TTP (Trusted Third Party) URI and TTP public key,

-TTP certificate that asserts the public key (OPTIONAL),

-Group membership claim (a list of URIs of member groups),

-Group membership certificate (OPTIONAL), -Timestamp and nonce (in some embodiments expired messages or seen nonces may silently be dropped), and

-Signature over the data (with initiator public key).

-20- AttyDktNo: 042933/343025 The initiator may also request a group assertion certificate beforehand from the group manager 78. The responder can check (e.g., via the assertion manager 82 of the responder) the membership based on the public key and the group URIs. If there is no prior trust relation with the group manager 78, the group manager public key may not be known. Accordingly, the responder may contact the group manager 78 to verify the group membership claim. The verify function specified in the group manager API may be used to perform this verification.

A service may also be registered with a chosen trust provider and/or with a number of groups as described in greater detail below. A service can obtain a signed group membership assertion that is valid for a specified period of time. If a provider key is not known, the client 66 may contact the provider. It is typically sufficient that a known group ID is found, a group ID is signed using a sender public key, and the group and public key are asserted by a known trust provider. Embodiments of the present invention may be implemented using various technologies such as, for example, web service technologies and basic web technologies. In one exemplary implementation, HTTPS may be used for basic end-to-end security with an identity provider and the group manager 78. User authentication can be performed using OpenID, and OpenID identity URIs can be used to define group members. The group management API may, in some exemplary embodiments, be implemented using representational state transfer (REST) or SOAP (formerly short for 'Simple Object Access Protocol')/Web services interfaces. In some embodiments, a browser-extension or AJAX (Asynchronous JavaScript and XML) client may be employed to enable invocation of the group manager API from the browser. Embodiments of the present invention may be practiced in combination with the OAuth protocol and/or OpenID in some cases.

FIG. 6 provides an example of communications that may occur in accordance with one exemplary embodiment of the present invention. According to an exemplary embodiment, the client 66 and the relying party 68 may be considered roles played by examples of the apparatus of FIG. 5, whereas the group management entity (GME) 69 may be considered to be a role played by an example of the apparatus of FIG. 4. In some embodiments, an identity provider 71 may also be employed as an authentication server on which the relying party 68

-21- AttyDktNo: 042933/343025 may rely for an assertion that an end user has or controls an identifier (e.g., an HTTP, HTTPS URI or other scheme and resolution protocol for abstract identifiers, such as an extensible resource indicator (XRI)). The GME 69 may be playing a group management role (e.g., employing the group manager 78) on a trusted third party device capable of asserting the identity of the relying party 68 to the identity provider 71. The relying party 68 may therefore be a service that may not have direct knowledge of user identity. A message can be received using different patterns, such as push or pull, or combinations of push and pull. An example of a push message may be a broadcast message or SMS, while web browsing may be an example of pull-style communications.

The following phases may further illustrate the mechanism of enabling mutual authentication of the client 66 and the relying party 68 according to an exemplary embodiment. In this regard, as shown in FIG. 6, the relying party 68 may obtain a certificate (e.g. an assertion certificate) for a particular group by communicating a message to the GME 69 at operation 100. The GME 69 may, subject to access class restrictions associated with the particular group, issue the certificate to the relying party 68 at operation 102. The issued certificate or token may include an assertion that the relying party belongs to the particular group (e.g., a group defined by a corresponding URI that may have arbitrary semantics). The URI may be resolved to determine characteristics or constraints of the group (e.g., group contents and/or a description of the group that may be machine readable). In an exemplary embodiment, after operation 100, a potential user interaction may occur before operation 102 at operation 101 (e.g., an OpenID interaction). At another time, the client 66 may obtain a certificate (e.g. an assertion certificate) for a particular group by communicating a message to the GME 69 at operation 104. The GME 69 may, subject again to access class restrictions associated with the particular group, issue the certificate to the client 66 at operation 106. Similarly, after operation 104, a potential user interaction may occur before operation 106 at operation 105. At some point thereafter, the client 66 and the relying party 68 may engage in some interaction (e.g., the client 66 may request a service from the relying party 68 or the relying party may send a message to the client 66) at operation 108. In either instance, the entity initiating the interaction may provide an assertion of

-22- AttyDktNo: 042933/343025 group membership to the other entity. The assertion may include the certificate or at least portions of the certificate that may indicate the initiating party's assertion of group membership. The other party may then check whether the assertion is valid and assess whether the initiating party is a member of the group based on the validity of the assertion at operation 112. If the assertion is valid, the message may be processed. If the assertion is invalid, the message may be ignored. The initiating party may also check the validity of the other party's assertion of group membership when a request is received from the other party at operation 114. As such, both parties may, for example, check the validity of a token or certificate or other indicia of group membership provided by communications received by each party to perform a mutual authentication as indicated at operation 120. Thus by using a call back mechanism, the client 66 and the relying party 68 can do mutual authentication by validating each others membership claims with the trusted party (e.g., the GME 69). FIG. 7 provides an example of communications that may occur in accordance with another exemplary embodiment of the present invention in which multiple relying parties are provided. As such, multiple parties can mutually authenticate and authorize each other using token or certificate management techniques. In some cases, transport layer security (TLS) and public key based certificates or tokens may be used to provide such security.

FIG. 8 illustrates an example of how a URI can be used to define groups and how groups can be based on other groups (e.g., nested groups). As indicated above, groups may be defined by a unique resource identifier or URI. In an exemplary embodiment, the URI may include two parts. For example, a URI 130 may include a group manager identifier portion 132 and a group identifier portion 134. A group may include anywhere from zero to a plurality of members in which each member is identified by a unique key that can be a public key or a URI (such as an OpenID identifier). As such, for example, OpenID may be utilized to authenticate group management operations. OAuth may also be integrated in several ways such as by allowing a group token or certificate to be used as an access token. Thus, user interaction, which is typically considerable in the OAuth protocol, may be skipped.

-23- AttyDktNo: 042933/343025 As shown in FIG. 8, after the URI 130 is provided, the presence of an identity bearing token (e.g., a cookie) may be checked at 140. If an identity bearing token is presented, authentication of the user may be skipped as in operation 142. However, if no identity bearing token is presented, as in operation 144, authentication of the user may be required. After the user is authenticated, an assertion certificate may be granted to the user to verify that the user is a member of the two groups (e.g., the user is a customer and a friend of Alice) at operation 150.

Embodiments of the present invention may be utilized in various different scenarios. For example, in a localized environment, a mobile server can accept requests from entities that are members of authorized groups, such as user owned services, members of social networks, etc. In a smart space, a group manager can be a locally discoverable entity. As such, the group manager may be a dynamically resolved or determined entity. Each entity joining the local group may register their public key or OpenID identifier. Each entity may then obtain an assertion with respect to membership to the local group. Subsequently, basic authentication can be based on this group membership. If an entity has a group membership, the identity of the entity may have been checked at the time of joining the group. Embodiments may also be used to allow relatively seamless authentication and authorization of members in a presence or buddy list.

Embodiments of the present invention may support decentralized operation in the sense that a trusted third party (e.g., the group manager) and groups may be dynamically resolved. The groups may have expressive semantics, because they are based on URIs that are resolved to determine group structure. Embodiments, may also decouple user identity management from group management and provide support for relatively low-overhead, secure one-to-many operations with relatively low (if any) user interaction. Embodiments may also be usable with existing security measures and may provide a group manager for registering public keys to allow strong security through public key cryptography in which the group manager may be, for example, embodied as one or more entities in a hierarchical network, such as a network of group manager servers.

In some cases, in addition to providing for an ability for entities to mutually authorize and authenticate each other, embodiments of the present invention may

-24- AttyDktNo: 042933/343025 further provide for the performance of service discovery in a decentralized environment. In this regard, for example, since a decentralized environment may include users and corresponding services or resources that come and leave without notice, a user entering the environment may desire to determine and possibly engage with available services. Moreover, the user may wish to be able to engage such services by provisioning configuration data for the service end point without substantial user interaction or overhead.

Current service discovery mechanisms typically do not include a security mechanism. Rather, it is typically assumed for most conventional smart space service discovery applications that all devices in the network can access all resources. Embodiments of the present invention may further enable the provision of security with respect to service discovery in a decentralized environment. As such, embodiments of the present invention may extend the decentralized secure group membership mechanism described above in reference to FIGS. 4-8 by expanding the concept of group membership to services. In this regard, for example, services can become group members by adding themselves as a group element. Group membership for a service may therefore provide that all group members are authorized to access the member service. Accordingly, a consumer that is a group member may be enabled to search for service endpoints of interest belonging to a particular group of which the consumer is a member.

Accordingly, for example, embodiments of the present invention may allow the configuration data specific to service providers to be provisioned only to the consumers that are authorized to interact with the service end point. The decision to reveal the configuration data specific to service providers may be made based on group assertions. In other words, configuration data for a particular service may only be provided to entities that are members of a group in which the particular service is also a member.

A consequence of allowing services to be group members may be that groups (the group identifier may be seen as a service end-point) can become members of other groups, thus enabling complex group operations (e.g. unions, intersections, recursive operations) with little to no increase in overhead. Furthermore, a group management service end-point can be protected with group management.

-25- AttyDktNo: 042933/343025 Enabling services to become group members may be accomplished in various ways. In one embodiment, a protocol may be provided including at least two parts such as a service registration part and a service end point discovery part. The service registration part may define procedures for managing service registration to groups. The service end point discovery part may describe how consumers discover services of interest.

Service registration may assume that a group management infrastructure is already setup. As indicated above, services added to a group may be available to all group members. Functions used for service registration may be similar to the functions described above in reference to the addition or removal of group elements. Thus, for example, the add element function may be used to add a service to a group by providing a group URI, a key, an expiration time, and a service type or classification of the service. Deletion of an element may merely require the group URI and the key. Each request for service registration may be authenticated and the requester may be the owner of the service. The key may be a service end point URI or a URI/XRI that points to an XRDS (extensible resource descriptor sequence) document. The service classification may be a space- separated list of service types supported at the service end point.

Verifying that a service is a group element may also be performed, for example, with the following function: Verify(group URI, key | service type).

Accordingly, group members can verify if a service end point is available for them by using the verification function. Although non-group members (e.g. an external group manager) may not be provided with visibility with respect to the key, non- group members may still verify that a service end point providing the service type is available for the group members at a group URI in some cases.

Service discovery may be performed, according to one exemplary embodiment, in a two operation process in which a consumer may first discover the group manager service end-point and then, by requesting from a group manager, discover service end-points for service classifications of interest. Service end-point discovery at the group manager level may be accomplished using the following function: Search(group URI, service type). A response to the function above may include a list of services of the given classification that are visible to the requester. The visibility may be determined by the group membership of the

-26- AttyDktNo: 042933/343025 requester, which may be determined from the assertion included in the request. If no group URI was provided in the request, a default group may be assumed. As such, for example, if a particular service is available to all members of a group and a member of the group (as indicated by the group URI provided with the search function request) requests service discovery, the member may receive a listing of services available to the group including the particular service.

Exemplary scenarios are provided below in reference to FIGS. 9-12. In a smart space scenario (e.g., an environment in which devices may be connected and integrated into a decentralized network with little user interaction either wirelessly or otherwise), discovering the group manager service end point may be accomplished using multicast requests. The multicast requests may be performed via any of the established multicast discovery protocols, e.g., mDNS/DNS-SD or SSDP, as long as both the consumer and the group manager are using the same protocol. In an internet scenario, discovering the group manager service end point may be accomplished using a discovery protocol (e.g., the Yadis discovery protocol). As shown in FIG. 9, which illustrates publication of services to a smart space or decentralized network according to an exemplary embodiment, there may be a local group management entity (GME) 200 configured to publish all local discoverable services (e.g., via the group manager 78). It may be assumed that all entities that joined the smart space have registered to the GME 200 and that the entities have an assertion certificate for membership to the local group. Following a local discovery operation at operation 202, the relying party may attempt to obtain a token or assertion certificate at operation 204 and an assertion certificate may be provided by the GME 200 at operation 206. The relying party 68 may then be enabled to add an element as an authenticated group member to indicate the service classification or type at operation 208.

FIG. 10 illustrates publication of services available to a subgroup of local smart space users. When making a service available to a restricted set of users of a smart space, the relying party 68 (which may be a mobile terminal or a server associated with a service provider) may make available to the local users, only the information that will enable the local users to discover the existence of a service, but not discover where the service (e.g. the service end point) is located. When the relying party 68 publishes the service in the local GME 200, it must also provide

-27- AttyDktNo: 042933/343025 info on how to reach a remote group manager (e.g., internet GM 210) for the restricted set of users. The local GME 200 may provide notice that the provided group URI (e.g. IntemetGroupURI) does not point to any local managed groups and also the service end point is missing. These may be indications for the local GME 200 that the corresponding service is not generally available. The key used for registering the services locally (e.g. OwnerKey(Local)) may be different than the key used in the context of the remote GM (e.g. OwnerKey in previous XML snippet). Using different keys may be the default behaviour if the local GM is not trusted. As shown in FIG. 10, the relying party 68 may publish a service to the remote or Internet GM 210 by adding an element identifying a group URI and the service endpoint along with the service classification or type. If the relying party 68 also attempts to publish the same group to the local GME 200, the local GME 200 may, recognizing that no service endpoint has been provided verify the group via the Internet GM 210. Accordingly, service discovery made at the local GME 200 may only indicate the availability of the service without identifying the service endpoint to an entity performing a search for the service later on.

FIG. 11 illustrates an example of searching for services available to a subgroup of local smart space users according to an exemplary embodiment. In this regard, if the client 66 desires to interact with a specific service type, the client 66 may search the local GME 200 and find out that there is a service of a particular type or classification that is restricted to the users indicated by the group URI as shown at sequence 230. The client may then, based on knowing that the client is a member of the group that the service is associated with, search the Internet GM 210 (or other remote GM if a network other than the Internet is involved) for the service end point as indicated in operation 232. The Internet GM may then return information identifying the service endpoint after checking the group membership assertion at operation 234.

FIG. 12 illustrates an example of searching for services available to a user internet- wide according to an exemplary embodiment. In this regard, if the client 66 desires to interact with specific service classifications or types available somewhere in the Internet, the client can start to find out about them by performing a discovery operation 250 (e.g., a Yadis discovery) with respect to a particular URI

-28- AttyDktNo: 042933/343025 252. The result of the discovery may be, for example, an XRDS document that includes, among others, the URI of a group manager (e.g., the Internet GM 210). Thus, for example, the URI on which the Yadis discovery is done could be a blog address, such as a blog URI, of a user. In some instances, the blog address or blog URI may indicative of a location of a website for commentary or collections of related contact. Such a scenario may enable the user to move its group management provider without the need to configure its devices. The user just needs to configure the client 66 once to the blog URJ (which may also be playing the role of the user's identity (e.g., OpenID identity)). Further, in some embodiments, the results of searching for services associated with FIG. 12 may indicate preferred services which an OAuth authorized service can then discover and be authorized for the preferred service.

In another example, the URI can be the front page of a service provider platform. Such a scenario may enable a developer to hard-code a configuration URI for applications that are specific to that service provider. These applications may then be discoverable at the group manager of that service provider without further configurations and no user interaction may be required.

Embodiments of the present invention may therefore provide decentralised operation in the sense that relying party service end points can be published to any groups, even several groups at the same time, and the groups do not need to belong to the same hierarchy. Service management in the group context (e.g. adding, updating, removing) may also be performed only by parties authorized to alter information regarding service end-points. Moreover, in some embodiments, service end points and configuration data may only be provisioned to group members, thus assuring a level of privacy for services. Embodiments of the present invention may also provide relatively robust group operations with relatively low overhead and semantics that may be determined at runtime. As such, no extra APIs may be required compared to basic decentralized group management. Accordingly, Internet-wide service discovery may be performed with relatively little (if any) user interaction. Some exemplary embodiments may also enable the use of arbitrary local discovery mechanisms (e.g. Bonjour or UPnP SSDP), even simultaneously. Furthermore, some exemplary embodiments may support provisioning of OAuth configurations, thus eliminating the need to run

-29- AttyDktNo: 042933/343025 O Auth Discovery. If such a policy is activated, the number of roundtrips and overall latency of communication may be reduced.

FIGS. 13 and 14 are flowcharts of a system, method and program product according to exemplary embodiments of the invention. It will be understood that each block or step of the flowcharts, and combinations of blocks in the flowcharts, can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions. For example, one or more of the procedures described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures described above may be stored by a memory device of the mobile terminal and executed by a processor in the mobile terminal. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (i.e., hardware) to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowcharts block(s) or step(s). These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowcharts block(s) or step(s). The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowcharts block(s) or step(s).

Accordingly, blocks or steps of the flowcharts support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that one or more blocks or steps of the flowcharts, and combinations of blocks or steps in the flowcharts, can be implemented by special purpose hardware-based computer systems which perform

-30- AttyDktNo: 042933/343025 the specified functions or steps, or combinations of special purpose hardware and computer instructions.

In this regard, one embodiment of a method of enabling group based authorization and service discovery in a decentralized network, as shown in FIG. 13, may include receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier at operation 310. The request may be received from a device in a decentralized network. The method may further include providing the certificate to the device in response to the request at operation 320. The certificate may enable the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

In some exemplary embodiments additional operations that may be optional may also be provided. Such operations are indicated in dashed boxes in FIG. 13. In this regard, in one exemplary embodiment, the method may further include enabling group management with regard to modification of group characteristics at operation 330. In some cases, enabling group management may include providing management function capabilities based on a group class defining access related characteristics of a respective class or an initial operation of enabling creation of the group based on receiving a request to create the group. In an exemplary embodiment, the method may further include enabling association of a service with the group at operation 340. Still further, the method may include receiving a search request for services associated with the group at operation 350 and, in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the group at operation 360. In some cases, enabling association of a service with the group further may include associating a service of a particular class with a corresponding class within the group, and operations 350 and 360 may then further include receiving a search request for a class of services associated with the group and, in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the class of services requested.

In another exemplary embodiment, the method may further include enabling a search for services associated with the group and only publishing services associated with the group to the members of the group at operation 370.

-31- AttyDktNo: 042933/343025 In such an embodiment, a further operation of providing an indication of services available within the group, but not providing an identity of a service endpoint providing the service may also be provided at operation 380.

In another exemplary embodiment, a method of utilizing group based authorization and service discovery in a decentralized network, as shown in FIG. 14, may include receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier at operation 400. The certificate may be received from a third party device in a decentralized network. The method may further include providing the certificate to another device in the decentralized network as evidence of membership in the group at operation 410, receiving an assertion of membership in the group from the other device at operation 420, and performing mutual authentication and authorization with the other device based on mutual membership in the group at operation 430.

In some exemplary embodiments additional operations that may be optional may also be provided. Such operations are indicated in dashed boxes in FIG. 14. In this regard, in one exemplary embodiment, the method may further include communicating with a management device to initiate a modification of characteristics of the group at operation 440, and communicating with the management device to initiate a search for a particular class of service associated with the group at operation 450.

Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe exemplary embodiments in the context of certain exemplary combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described

-32- AttyDktNo: 042933/343025 above are also contemplated as may be set forth in some of the appended claims.Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

-33- AttyDktNo: 042933/343025

Claims

WHAT IS CLAIMED IS: 1. A method comprising: receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, the request being received from a device in a decentralized network; and providing the certificate to the device in response to the request, the certificate enabling the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

2. The method of claim 1, further comprising enabling group management with regard to modification of group characteristics.

3. The method of claim 2, wherein enabling group management comprises providing management function capabilities based on a group class defining access related characteristics of a respective class.

4. The method of claim 2, wherein enabling group management comprises an initial operation of enabling creation of the group based on receiving a request to create the group.

5. The method of claim 1, further comprising enabling association of a service with the group.

6. The method of claim 5, further comprising: receiving a search request for services associated with the group, and in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the group.

7. The method of claim 5, wherein enabling association of a service with the group further comprises associating a service of a particular class with a corresponding class within the group, and wherein the method further comprises: receiving a search request for a class of services associated with the group, and

-34- AttyDktNo: 042933/343025 in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the class of services requested.

8. The method of claim 1, further comprising enabling a search for services associated with the group and only publishing services associated with the group to the members of the group.

9. The method of claim 8, further comprising providing an indication of services available within the group, but not providing an identity of a service endpoint providing the service.

10. An apparatus comprising a processor configured to: receive a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, the request being received from a device in a decentralized network; and provide the certificate to the device in response to the request, the certificate enabling the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

11. The apparatus of claim 10, wherein the processor is further configured to enable group management with regard to modification of group characteristics.

12. The apparatus of claim 11, wherein the processor is further configured to enable group management by providing management function capabilities based on a group class defining access related characteristics of a respective class.

13. The apparatus of claim 11 , wherein the processor is further configured to enable group management by an initial operation of enabling creation of the group based on receiving a request to create the group.

-35- AttyDktNo: 042933/343025

14. The apparatus of claim 10, wherein the processor is further configured to enable association of a service with the group.

15. The apparatus of claim 14, wherein the processor is further configured to: receive a search request for services associated with the group, and in response to receipt of the search request, provide a reply to the request in which the reply indicates at least one service associated with the group.

16. The apparatus of claim 14, wherein the processor is further configured to associate a service with the group further by associating a service of a particular class with a corresponding class within the group, and wherein the processor is further configured to: receive a search request for a class of services associated with the group, and in response to receipt of the search request, provide a reply to the request in which the reply indicates at least one service associated with the class of services requested.

17. The apparatus of claim 10, wherein the processor is further configured to enable a search for services associated with the group and only publish services associated with the group to the members of the group.

18. The apparatus of claim 17, wherein the processor is further configured to provide an indication of services available within the group, but not provide an identity of a service endpoint providing the service.

19. A computer program product comprising at least one computer- readable storage medium having computer-executable program code portions stored therein, the computer-executable program code portions comprising: a first program code portion for receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, the request being received from a device in a decentralized network; and

-36- AttyDktNo: 042933/343025 a second program code portion for providing the certificate to the device in response to the request, the certificate enabling the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

20. The computer program product of claim 19, further comprising a third program code portion for enabling group management with regard to modification of group characteristics.

21. The computer program product of claim 20, wherein the third program code portion includes instructions for providing management function capabilities based on a group class defining access related characteristics of a respective class.

22. The computer program product of claim 20, wherein the third program code portion includes instructions for an initial operation of enabling creation of the group based on receiving a request to create the group.

23. The computer program product of claim 19, further comprising a third program code portion for enabling association of a service with the group.

24. The computer program product of claim 23, further comprising: a fourth program code portion for receiving a search request for services associated with the group, and a fifth program code portion for, in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the group.

25. The computer program product of claim 23, wherein the third program code portion includes instructions for associating a service of a particular class with a corresponding class within the group, and wherein the computer program product further comprises:

-37- AttyDktNo: 042933/343025 a fourth program code portion for receiving a search request for a class of services associated with the group, and a fifth program code portion for, in response to receipt of the search request, providing a reply to the request in which the reply indicates at least one service associated with the class of services requested.

26. The computer program product of claim 19, further comprising a third program code portion for enabling a search for services associated with the group and only publishing services associated with the group to the members of the group.

27. The computer program product of claim 26, further comprising a fourth program code portion for providing an indication of services available within the group, but not providing an identity of a service endpoint providing the service.

28. A method comprising: receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network; providing the certificate to another device in the decentralized network as evidence of membership in the group; receiving an assertion of membership in the group from the other device; and performing mutual authentication and authorization with the other device based on mutual membership in the group.

29. The method of claim 28, further comprising communicating with a management device to initiate a modification of characteristics of the group.

30. The method of claim 28, further comprising communicating with a management device to initiate a search for a particular class of service associated with the group.

-38- AttyDktNo: 042933/343025

31. An apparatus comprising a processor configured to: receive a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network; provide the certificate to another device in the decentralized network as evidence of membership in the group; receive an assertion of membership in the group from the other device; and perform mutual authentication and authorization with the other device based on mutual membership in the group.

32. The apparatus of claim 28, wherein the processor is further configured to communicate with a management device to initiate a modification of characteristics of the group.

33. The method of claim 28, wherein the processor is further configured to communicate with a management device to initiate a search for a particular class of service associated with the group.

34. A computer program product comprising at least one computer- readable storage medium having computer-executable program code portions stored therein, the computer-executable program code portions comprising: a first program code portion for receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network; a second program code portion for providing the certificate to another device in the decentralized network as evidence of membership in the group; a third program code portion for receiving an assertion of membership in the group from the other device; and a fourth program code portion for performing mutual authentication and authorization with the other device based on mutual membership in the group.

35. The method of claim 28, further comprising:

-39- AttyDktNo: 042933/343025 a fifth program code portion for communicating with a management device to initiate a modification of characteristics of the group; and a sixth program code portion for communicating with the management device to initiate a search for a particular class of service associated with the group.

36. An apparatus comprising: means for receiving a request for a certificate indicative of an assertion of membership in a group defined by a resource identifier, the request being received from a device in a decentralized network; and means for providing the certificate to the device in response to the request, the certificate enabling the device to perform mutual authentication and authorization with another device that is a member of the group based on the assertion.

37. An apparatus comprising: means for receiving a certificate indicative of an assertion of membership in a group defined by a resource identifier, the certificate being received from a third party device in a decentralized network; means for providing the certificate to another device in the decentralized network as evidence of membership in the group; means for receiving an assertion of membership in the group from the other device; and means for performing mutual authentication and authorization with the other device based on mutual membership in the group.

-40- AttyDktNo: 042933/343025