A Roaming Consortium Identifier (RCOI) based system for handling identity requirements

Abstract

A roaming consortium identifier (RCOI) based identity requirement process may be provided. First, an access device may advertise an identifier. The identifier may identify an identity type used by a roaming consortium and a service provider to provide services through the access device. Next, a request may be received from a user device to associate with the access device. The request may conform to the identity type advertised in the identifier. The user device may then be associated with the access device in response to receiving the request.

Description

[0001] Related Applications

[0002] This application is a PCT international patent application filed on November 14, 2019, and claims priority to U.S. Provisional Patent Application Serial No. 62 / 770,553 filed on November 21, 2018, and U.S. Non-Provisional Patent Application Serial No. 16 / 511,879 filed on July 15, 2019, the entire contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates generally to roaming consortiums and automatic onboarding in WiFi. Background Art

[0004] In computer networking, a wireless access point (AP) is a network hardware device that allows Wi-Fi compliant client devices to connect to a wired network. An AP is usually connected to a router as a standalone device (either directly or indirectly via a wired network), but it can also be an integral part of the router itself. Several APs can also work together, either through direct wired or wireless connections or through a central system, often called a wireless local area network (WLAN) controller. An AP is different from a hotspot, which is a physical location at which Wi-Fi access to a WLAN is available.

[0005] Before the advent of wireless networking, setting up a computer network in a business, home, or school often required running many cables through walls and ceilings to provide network access to all network-enabled devices in the building. With the creation of wireless APs, network users were able to add devices that could access the network using few or no cables. The AP typically connects directly to a wired Ethernet connection, and the AP then uses a radio frequency link to provide wireless connectivity for other devices to utilize that wired connection. Most APs support connecting multiple wireless devices to one wired connection. APs are built to support standards for using these radio frequencies to send and receive data. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The accompanying drawings, which are included in and constitute a part of this disclosure, illustrate various embodiments of the present disclosure. In the drawings:

[0007] Figure 1 is a block diagram of an operating environment for identity requirement processing based on a Roaming Consortium Identifier (RCOI);

[0008] Figure 2is a flow chart of a method for providing identity claim processing based on a Roaming Consortium Identifier (RCOI); and

[0009] Figure 3 is a block diagram of a computing device. DETAILED DESCRIPTION

[0010] Overview

[0011] Identity requirement handling based on a roaming consortium identifier (RCOI) may be provided. First, an access device may advertise an identifier. The identifier may identify an identity type used by a roaming federation and a service provider to provide services through the access device. Next, a request to associate with the access device may be received from a user device. The request may conform to the identity type advertised in the identifier. The user device may then be associated with the access device in response to receiving the request.

[0012] Example Embodiments

[0013] The following detailed description refers to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar elements. Although embodiments of the present disclosure may be described, modifications, adaptations, and other implementations are possible. For example, the elements shown in the drawings may be replaced, added, or modified, and the methods described herein may be modified by replacing, reordering, or adding stages to the disclosed methods. Therefore, the following detailed description does not limit the present disclosure. Alternatively, the proper scope of the present disclosure is defined by the appended claims.

[0014] An open roaming federation may be formed based on common criteria and requirements that may require members to adhere to common terms of service or policy. A Wi-Fi open roaming federation may be automatically signed in by the local access service provider, while a neutral federation may relay the authentication task to one of many possible identity providers. In defining such a roaming federation, it may be desirable to be as inclusive as possible to ensure that the federation is deployed as widely as possible, while also accepting that there may be some key differences associated with the concepts of identity and authentication.

[0015] Example identity types may include public and private and weak and strong identities. For public and private, enterprise IT operations (e.g., within a company) may have outstanding requirements to uniquely identify visitors roaming to a local (e.g., corporate Internet) Wi-Fi system. Before the advent of roaming federation, this was achieved using portal redirection and credentials generated by a known identity (i.e., company staff). For roaming federation, this identification may need to be implemented in a federated automatic roaming environment. However, roaming federated identity providers and / or users may wish to prohibit operations in certain environments such as the following: in these environments, their actual real identities are exposed to untrusted service providers. These two requirements (i.e., the service provider requires visitor identification, and the identity provider or user does not want their actual real identity to be exposed to some service providers) may not be contradictory, because there is always one requirement that may be location-related (e.g., accessing a company guest network may require exposing the user's actual real identity, but may not be required in a shopping mall). However, there may be no process for transmitting location-specific requirements to user devices.

[0016] Authentication through a local access provider using weak and strong identities may utilize multiple possible identities present in a user's device (e.g., based on the International Mobile Equipment Identity (IMEI), based on the operating system (OS), or available in applications such as social media applications and other applications). However, not all available identities are the same. For example, for some roaming federations, a user may be able to obtain roaming federation credentials through a simplified registration process (in which case the identity is considered weak). In addition, some access providers only want to deal with traditional service providers associated with billing relationships, rather than those associated with webscale providers who have lower trust root requirements. In other environments, lightweight identification is sufficient or desirable (e.g., for privacy protection or to limit the chain of responsibility). Therefore, it may be necessary to address the issue of defining a common roaming federation that can handle and communicate different identity characteristics and requirements.

[0017] A roaming consortium may not deal with traditional identities, but there may be no other choice (e.g., one consortium, one set of identities, which are statically associated to the consortium). A federation may open up this limitation by allowing several identity providers (and thus several possible identities) to access the same network. However, the question may become which identity is acceptable to which access provider at which location. For example, two locations (e.g., a shopping mall and a courthouse) may both have a public access network and be part of the same overall consortium, but may have different rules about what types of credentials are allowed (e.g., anonymous vs. clear user identification). Embodiments of the present disclosure may enable association between a roaming consortium identifier (RCOI) and identity characteristics, which may then enable multiple different types of identities to be used within a single consortium while still complying with the identity constraints of each local access provider.

[0018] In addition, embodiments of the present disclosure may map tags to a specific set of identity characteristics and thus automate the association (and notification) of local access provider requirements with the identity type configured in each user device. Embodiments of the present disclosure may automate this mapping, allowing the user device to automatically pick the "best" identity possible (the best compromise between the local access provider requirements and the credential types available on the user device). RCOI tags may be one way to achieve this within the standard notification.

[0019] Figure 1 1 is a block diagram of an operating environment 100 for roaming consortium identifier (RCOI) based identity claim processing consistent with an embodiment of the present disclosure. Figure 1 As shown, operating environment 100 may include access device 105, network 110, and user device 115 operated by user 120. Open roaming federation may link enterprises, service providers, and identity providers to provide a seamless onboarding process across participating Service Set Identifiers (SSIDs) using a Roaming Consortium Identifier (RCOI) indicating open roaming.

[0020] In some embodiments of the present disclosure, access device 105 may include a Wi-Fi access point (AP) configured to support a Wi-Fi hotspot. A Wi-Fi hotspot may include a physical location where a user 120 operating a user device 115 may use Wi-Fi technology to gain access to network 110 (e.g., Internet access) via a wireless local area network (WLAN) using a router connected to a service provider.

[0021] In other embodiments of the present disclosure, the access device 105 may include a device that can be connected to a cellular network that can communicate directly and wirelessly with an end user device (e.g., a user device 115 operated by a user 120) to provide access to the network 110 (e.g., Internet access). For example, the access device 105 may include, but is not limited to, an eNodeB (eNB) or a gNodeB (gNB). The cellular network may include, but is not limited to, a long-term evolution (LTE) broadband cellular network, a fourth generation (4G) broadband cellular network, or a fifth generation (5G) broadband cellular network operated by a service provider.

[0022] User device 115 may include, but is not limited to, a smartphone, a tablet device, a personal computer, a mobile device, a cellular base station, a phone, a remote control device, a set-top box, a digital video recorder, a cable modem, a network computer, a mainframe, a router, or other similar microcomputer-based device capable of accessing and using a Wi-Fi network or a cellular network. Network 110 may include, for example, the Internet.

[0023] The above-mentioned elements of the operating environment 100 (e.g., the access device 105 and the user device 115) can be implemented in hardware and / or software (including firmware, resident software, microcode, etc.) or any other circuit or system. The elements of the operating environment 100 can be implemented in an electronic circuit including discrete electronic components, a packaged or integrated electronic chip containing logic gates, a circuit using a microprocessor, or on a single chip containing electronic components or a microprocessor. In addition, the elements of the operating environment 100 can also be implemented using other technologies capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. As described below with reference to Figure 3 As described in greater detail, elements of operating environment 100 may be implemented in computing device 300 .

[0024] Figure 2 2 is a flow chart illustrating the general stages involved in a method 200 for providing RCOI-based identity claim processing consistent with an embodiment of the present disclosure. The method 200 may be implemented as described above with respect to Figure 1 The access device 105 described in more detail is implemented. The manner for implementing each stage of the method 200 will be described in more detail below.

[0025] Method 200 may start at start block 205 and proceed to stage 210, in which the access device 105 may advertise an identifier. The identifier may identify an open roaming federation and the type of identity used by the service provider to provide services through the access device 105. For example, the identifier may include a roaming consortium identifier (RCOI). Embodiments of the present disclosure may also use multiple RCOIs within the same open roaming federation. For example, instead of advertising a single RCOI to represent an open roaming federation, embodiments of the present disclosure may define a single open roaming federation that includes, for example, the following four RCOIs. Instead of separate open roaming federations, each of the four RCOIs in this example may be a string that not only identifies the open roaming federation in general terms, but also identifies the type of identity used by the local access provider operating the access device 105. The four example RCOIs may include, but are not limited to:

[0026] RCOI #1: Public / Weak

[0027] RCOI #2: Public / Strong

[0028] RCOI #3: Anonymous / Weak

[0029] RCOI #4: Anonymous / Strong

[0030] Other examples may use the "EAP-UNAUTH-TLS" option in the Extensible Authentication Protocol (EAP) authorization protocol, which may use only server-side certificates, in which case **** / None may be additionally added to the above list to define a total of eight RCOIs in this example. In addition, the RCOI may represent more than the above four examples, and may also be associated with, for example, Quality of Service (QoS), access condition values, or other parameters that may define not only identity requirements, but also other access conditions for the network.

[0031] A traditional RCOI may be a single value representing a set of identity providers (IdPs). Embodiments of the present disclosure may extend the RCOI count and also use the RCOI in a manner that represents quality rather than just identity (i.e., the strength of authentication allowed on the service provider's local network, instead of a simple IdP identifier). The quality represented by embodiments of the present disclosure may be about credential strength and the requirement to disclose the actual real identity of the user (e.g., user 120), but any other type of quality representation may be used according to the same principles, resulting in a process of representing the quality associated with a network through identity exchange.

[0032] Additionally, embodiments of the present disclosure may be used to resolve incompatibilities between identity types. Thus, an additional RCOI may be advertised to indicate a whitelist or blacklist. Thus, a first service provider controlling a shopping mall may accept public / strong, but may blacklist an untrusted second service provider IdP, despite its claimed type being strong (an additional RCOI may then be used to indicate the blacklist). The same process may also be used to indicate a whitelist instead.

[0033] For example, usage of such a differentiated RCOI may be as follows. When a service provider (i.e., access provider) joins an open roaming federation, it may declare its identity policy requirements. Appropriate RCOI(s) may then be configured in the service provider's network to identify not only the open roaming federation, but also the type of identity that the client is required to use. When an identity provider joins an open roaming federation, it may declare its identity policy. Appropriate RCOIs may then be configured in a profile of a device (e.g., user device 115) of an identity provider user (e.g., user 120).

[0034] If the identity provider or its users 120 do not agree to make their actual real identity available to the service provider, only the anonymous / RCOI in the above example may be configured in the profile of the user device 115. If the identity provider or its users 120 do agree to make their actual real identity available to the service provider, both the public / and anonymous / RCOI in the above example may be configured in the profile of the user device 115. If the identity provider uses a "weak" form of attestation in their identity management, the / weak RCOI in the above example may be configured in the profile of the user device 115. If the identity provider uses a "strong" form of attestation in their identity management, both the / weak and / strong RCOI in the above example may be configured in the profile of the user device 115.

[0035] The terms "weak" and "strong" can be defined in a variety of ways. In one embodiment, the identity provider can provide a definition that the legitimate identity of the user 120 is required and verified to be considered a strong identity, and a voluntary registration without strict verification can be considered a weak identity. In another embodiment, the identity provider identity strength can be reviewed by a third party (e.g., Open Roaming Federation or other entities such as a secure identity alliance).

[0036] Embodiments of the present disclosure may include an explicit association of identity strength with a profile configured on the client device 115. When multiple profiles are configured, each profile may be associated with a tag representing the profile identity strength level based on the identity provider type. Embodiments of the present disclosure may also include that each service provider network that uses a specific subset (or set of subsets) of the open roaming federated RCOI identifier may be able to express identity strength requirements to be authorized to automatically access the local guest network.

[0037] Using the process described in the above example, a profile from an identity provider with anonymous and weak policies can be configured with the following RCOI: Anonymous / Weak. Similarly, a profile from an identity provider with public and weak and strong policies can be configured with the following RCOI: Public / Weak, Public / Strong, Anonymous / Weak, and Anonymous / Strong.

[0038] From stage 210, in which the access device 105 advertises an identifier that identifies a roaming association and an identity type used by the service provider to provide services through the access device 105, the method 200 may proceed to stage 220, in which the access device 105 may receive a request from the user device 115 to associate with the access device 105, wherein the request conforms to the identity type advertised in the identifier. For example, the access device 105 may advertise one or more RCOIs that reflect the identity requirements of its service provider, and the user device 115 may be configured with the policy of its identity provider. After receiving the one or more RCOIs from the access device 105, the user device 115 may search for a profile previously configured on the user device 115, and the user device 115 may only associate to and attempt to authenticate to the access device 105 if the policy used by the access device 105 satisfies (i.e., conforms to) the identity policy previously configured with the user device 115.

[0039] Once the access device 105 receives a request from the user device 115 to associate with the access device 105, when the request complies with the identity type announced in the identifier in stage 220, the method 200 can proceed to stage 230, in which, in response to receiving the request, the access device 105 can associate the user device 115 with the access device 105. For example, the service provider can declare a public / strong identity type policy in the announced identifier. A client (e.g., user device 115) that accepts the identity type policy (because the identity type policy complies with the client's configuration) can automatically associate with the access device 105, and can only use a device identity marked as strong (e.g., based on IMEI), and can display its actual real identity in the request. In the client (e.g., user device 115), multiple credentials (OS, multiple emails, company identity, service provider identity) can be configured or installed. Through embodiments of the present disclosure, the client (e.g., user device 115) can know which subset of credentials can be accepted to connect to the access device 105, thereby automatically discarding credentials that may not match the requirements of the service provider. The client (e.g., user device 115) may also know that any set of credentials matching the type(s) advertised by the service provider through access device 105 may be sufficient to gain access, thereby eliminating the need for manual selection. In addition, the user 120, the service provider, or the enterprise providing the user device 115 may rank the profiles present on the user device 115 by preference, resulting in (when more than one profile is configured) a possible preference for one public / strong profile over another, thereby increasing the dimensionality of the possibility matrix.

[0040] In contrast, a service provider may declare an anonymous / weak identity type in the advertised identifier. The client (e.g., user device 115) may accept the identity type (because it is consistent with the client's configuration) and may automatically associate with the access device 105 using any identity (e.g., a social media app ID) and may not expose its actual real identity in the portion of the request visible to the service provider. The client (e.g., user device 115) may automatically use credentials that maximize user privacy while complying with local service provider constraints. By associating an identity strength label to a user profile configured on the user device 115, embodiments of the present disclosure may eliminate the burden of the user 120 manually selecting a set of credentials or having to evaluate which set of credentials may provide the best privacy protection.

[0041] Similarly, the service provider can declare anonymous / weak and anonymous / strong identity types in the advertised identifier. Clients (e.g., user devices 115) that accept these identity types (because these identity types conform to the client's configuration) can be automatically associated with the access device 105. In one embodiment, the client (e.g., user device 115) can use any identity (e.g., social media app ID). In another embodiment, the client (e.g., user device 115) can always prefer one of the identities (e.g., always prefer strong when available, or always prefer weak when available). In both cases, the client (e.g., user device 115) may not expose its actual real identity in the portion of the request visible to the service provider. Local regulation, service provider or user initial device configuration can provide additional flexibility or constraints in the credential selection logic (always choose the strongest, or always choose the weakest, etc.).

[0042] In contrast, a service provider may declare a public / strong identity type in the advertised identifier, and the client (e.g., user device 115) accepts anonymous / weak and anonymous / strong. Such a client may not accept a public / strong identity type that must expose the client's identity. The client may not automatically associate. There may be an embodiment in which the user 120 may be required to override the process, thereby providing an opt-in for informed consent to share its actual real identity. This may result in manual user interaction only when manual user interaction is required for association, thereby suppressing automation when "high-level requirements" require the user 120 to make conscious decisions that automation should not make. After the access device 105 associates the user device 115 with the access device 105 in response to receiving the request (in stage 230), the method 200 may then end at stage 240.

[0043] Figure 3 A computing device 300 is shown. Figure 3 As shown, computing device 300 may include processing unit 310 and memory unit 315. Memory unit 315 may include software module 320 and database 325. When executed on processing unit 310, software module 320 may perform, for example, providing the above-mentioned Figure 2 The described process of RCOI-based identity claim handling. For example, computing device 300 may provide an operating environment for access device 105 or user device 115. Access device 105 and user device 115 may operate in other environments and are not limited to computing device 300.

[0044] The computing device 300 can be implemented using the following items: wireless fidelity (Wi-Fi) access points, cellular base stations, tablet devices, mobile devices, smart phones, phones, remote control devices, set-top boxes, digital video recorders, cable modems, personal computers, network computers, mainframes, routers, switches, server clusters, devices similar to smart TVs, network storage devices, network relay devices, or other similar microcomputer-based devices. The computing device 300 may include any computer operating environment, for example, a handheld device, a multiprocessor system, a microprocessor-based or programmable transmitter electronic device, a minicomputer, a mainframe computer, etc. The computing device 300 may also be practiced in a distributed computing environment where tasks are performed by a remote processing device. The aforementioned systems and devices are examples and the computing device 300 may include other systems or devices.

[0045] For example, the embodiments of the present disclosure may be implemented as a computer process (method), a computing system or a manufactured product, such as a computer program product or a computer-readable medium. A computer program product may be a computer storage medium that is readable by a computer system and encodes computer program instructions for executing a computer process. A computer program product may also be a signal propagated on a carrier that is readable by a computing system and encodes computer program instructions for executing a computer process. Therefore, the present disclosure may be implemented in hardware and / or software (including firmware, resident software, microcode, etc.). In other words, the embodiments of the present disclosure may take the form of a computer program product on a computer-usable or computer-readable storage medium, wherein the computer-usable or computer-readable storage medium has a computer-usable or computer-readable program code embodied in the medium for use by or in combination with an instruction execution system. A computer-usable or computer-readable medium may be any medium that can contain, store, transmit, propagate or transmit a program for use by or in combination with an instruction execution system, device or equipment.

[0046] A computer usable or computer readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples of computer readable media (a non-exhaustive list) may include the following: an electrical connection having one or more wires, a portable computer disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fibers, and a portable compact disk read-only memory (CD-ROM). Note that a computer usable or computer readable medium may even be paper or another suitable medium on which the program is printed, as the program may be captured electronically, for example, by optically scanning the paper or other medium, and then compiled, interpreted, or otherwise processed in a suitable manner (if necessary), and then stored in a computer memory.

[0047] Although certain embodiments of the present disclosure have been described, other embodiments may exist. In addition, although embodiments of the present disclosure have been described as being associated with data stored in memory and other storage media, data may also be stored on or read from other types of computer-readable media, such as auxiliary storage devices such as hard disks, floppy disks, or CD-ROMs, carrier waves from the Internet, or other forms of RAM or ROM. In addition, the stages of the disclosed method may be modified in any manner, including by reordering stages and / or inserting or deleting stages, without departing from the present disclosure.

[0048] In addition, embodiments of the present disclosure may be implemented in electronic circuits including discrete electronic components, packaged or integrated electronic chips including logic gates, circuits utilizing microprocessors, or on a single chip including electronic components or microprocessors. Embodiments of the present disclosure may also be implemented using other technologies capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. In addition, embodiments of the present disclosure may be implemented in a general-purpose computer or in any other circuit or system.

[0049] The embodiments of the present disclosure may be implemented via a system on a chip (SOC), wherein Figure 1 Each one or more of the elements shown in can be integrated into a single integrated circuit. Such a SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which can be integrated (or "burned") into a chip substrate as a single integrated circuit. When operated via a SOC, the functions described herein regarding the embodiments of the present disclosure can be performed via dedicated logic integrated with other components of the computing device 300 on a single integrated circuit (chip).

[0050] For example, the block diagrams and / or operational diagrams of the methods, systems, and computer program products according to the embodiments of the present disclosure are described above with reference to the embodiments of the present disclosure. The functions / actions noted in the blocks may not occur in the order shown in any flow chart. For example, depending on the functions / actions involved, two blocks shown in succession may actually be executed substantially simultaneously, or blocks may sometimes be executed in reverse order.

[0051] Although the specification includes examples, the scope of the present disclosure is indicated by the following claims. In addition, although the specification has been described in language specific to structural features and / or method actions, the claims are not limited to the above features or actions. Instead, the above specific features and actions are disclosed as examples of embodiments of the present disclosure.

Claims

1. A method for a computer network, comprising: an identifier announced by an access device, wherein the identifier identifies a roaming association and an identity type used by a service provider to provide services through the access device, wherein the identifier includes a plurality of roaming consortium identifiers RCOIs, and each of the plurality of RCOIs is a character string identifying the roaming association and the identity type; receiving, from a user device, a request to associate with the access device, wherein the request conforms to the identity type advertised in the identifier; and associating the user equipment with the access device in response to receiving the request, The identity types include: Public identity type, where the identity data required in the request must actually identify the user; and An anonymous identity type, where the identity data required in the request does not necessarily actually identify the user.

2. The method according to claim 1, wherein: The notification by the access device includes notification by the following access device: the access device includes one of the following items: eNodeB and gNodeB.

3. The method according to claim 1, wherein: The notification by the access device includes notification by the following access device: the access device includes a Wi-Fi access point (AP).

4. The method according to any one of claims 1 to 3, wherein: Notifying the identifier includes notifying the identifier wherein the identity type includes a strong identity type, wherein the identity data required in the request must be strong identity data.

5. The method according to any one of claims 1 to 3, wherein: Announcing the identifier includes announcing the identifier wherein the identity type includes a weak identity type, wherein the identity data required in the request can be weak identity data.

6. The method according to any one of claims 1 to 3, further comprising: Receiving, by the user equipment, the identifier from the access device; Determining, by the user equipment, that the user equipment is configured with the identifier; as well as In response to determining that the user equipment is configured with the identifier, the request to associate with the access device is sent by the user equipment to the access device.

7. The method according to claim 6, further comprising: The user equipment is configured with the identifier.

8. The method according to any one of claims 1 to 3, further comprising: Receiving, by the user equipment, the identifier from the access device; Determining, by the user equipment, that the user equipment is not configured with the identifier; Receiving, by the user equipment, an instruction associated with the access device; as well as In response to receiving the instruction to associate with the access device, the user device sends the request to associate with the access device to the access device.

9. The method according to claim 8, further comprising: The user equipment is configured with the identifier.

10. A method for a computer network, comprising: announcing, by an access device, a plurality of identifiers, wherein each of the plurality of identifiers identifies a roaming association and an identity type used by a service provider to provide services through the access device, wherein the identifiers include a plurality of roaming consortium identifiers RCOIs, and each of the plurality of RCOIs is a string identifying the roaming association and the identity type; receiving, from a user device, a request to associate with the access device, wherein the request conforms to the identity type advertised in one of the plurality of identifiers; and associating the user equipment with the access device in response to receiving the request, The identity types include: Public identity type, where the identity data required in the request must actually identify the user; and An anonymous identity type, in which the identity data required in the request does not necessarily actually identify the user.

11. The method according to claim 10, further comprising: Receiving, by the user equipment, the plurality of identifiers from the access device; Determining, by the user equipment, that the user equipment is configured with at least two identifiers of the plurality of identifiers; selecting a first identifier of the at least two identifiers of the plurality of identifiers that provides the greatest privacy protection; as well as The request for association with the access device is sent by the user equipment to the access device, wherein the request corresponds to the first identifier of the at least two identifiers of the plurality of identifiers.

12. The method according to claim 11, further comprising: The user equipment is configured with the plurality of identifiers.

13. A system for a computer network, comprising: Memory storage device; as well as a processing unit coupled to the memory storage device, wherein the processing unit is configured to: causing the system to be provided with an identifier, wherein the identifier identifies a roaming association and an identity type used to receive services from an access device, wherein the identifier comprises a plurality of roaming consortium identifiers RCOIs, and each of the plurality of RCOIs is a string identifying the roaming association and the identity type; receiving the identifier from the access device; determining that the system is configured with the identifier; and In response to determining that the system is configured with the identifier, sending a request to the access device for association with the access device, wherein the request conforms to the identifier, The identity types include: Public identity type, where the identity data required in the request must actually identify the user; and An anonymous identity type, in which the identity data required in the request does not necessarily actually identify the user.

14. The system according to claim 13, wherein: The identity type comprises a weak identity type, wherein the identity data required in the request can be weak identity data.

15. A computer readable medium carrying computer program instructions for causing the method according to any one of claims 1 to 12 to be executed.

Images