WO2016084822A1 - 複数のサービスシステムを制御するサーバシステム及び方法 - Google Patents

複数のサービスシステムを制御するサーバシステム及び方法 Download PDF

Info

Publication number
WO2016084822A1
WO2016084822A1 PCT/JP2015/082991 JP2015082991W WO2016084822A1 WO 2016084822 A1 WO2016084822 A1 WO 2016084822A1 JP 2015082991 W JP2015082991 W JP 2015082991W WO 2016084822 A1 WO2016084822 A1 WO 2016084822A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
identification code
information
service system
received
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2015/082991
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
多田　充
正幸 糸井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chiba University NUC
Safety Angle Inc
Original Assignee
Chiba University NUC
Safety Angle Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Chiba University NUC, Safety Angle Inc filed Critical Chiba University NUC
Priority to US15/531,003 priority Critical patent/US20180052987A1/en
Priority to JP2016561901A priority patent/JP6199506B2/ja
Publication of WO2016084822A1 publication Critical patent/WO2016084822A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the present invention generally relates to control of service systems.
  • the user in order to provide information to the first service system, the user must acquire the information from the second service system and provide the acquired information to the first service system. It can be annoying.
  • a server system (one or more computers) capable of communicating with a plurality of user terminals and a plurality of service systems is constructed.
  • a server system (for example, a control center) holds management information including one or more information element groups for each user.
  • Each of the one or more information element groups includes an ID (mID) that is shared between the server system and the service system and is different for each user.
  • a server system receives a request from a user terminal. Based on the request, the server system specifies one or more mIDs respectively corresponding to one or more service systems from the management information for the user of the user terminal.
  • the server system transmits, to each of the one or more service systems, a request in which mIDs corresponding to the service system among the specified one or more mIDs are associated with the control contents for the service system.
  • FIG. 1 shows an outline of an authentication process according to a first embodiment. It shows an example of the configuration of U M. It shows an example of the configuration of U P.
  • a configuration example of S i (j) (S 1 (1) ) is shown.
  • a configuration example of C (j) (C (1) ) is shown.
  • a configuration example of uList i (j) (uList 1 (1) ) is shown.
  • a configuration example of aList (j) (aList (1) ) is shown.
  • the structural example of pList is shown.
  • a configuration example of sList (j) (sList (1) ) is shown.
  • a configuration example of cList (j) (cList (1) ) is shown.
  • C Indicates tpw provided by (1) .
  • An example of the initial registration flow is shown.
  • Example 7 The structural example of aList (j) which concerns on Example 7 is shown.
  • 18 shows an example of an authentication / cooperation flow according to an eighth embodiment.
  • summary of identification code management is shown.
  • the structural example of a shutter system is shown.
  • An example of each flow of the authentication registration procedure 1, the registration procedure 2, and the authentication shutter operation procedure is shown.
  • An example of the flow of the login procedure is shown.
  • An example of screen transition is shown.
  • 18 shows an example of a registration flow according to an eighth embodiment.
  • a password is taken as an example as an identification code common to a plurality of service systems.
  • the common password is associated with a restriction such as at least one of an expiration date and the number of times of use.
  • the common password is taken as an example of a one-time password that can be used without limitation for the day when the password is issued (in the embodiment, “one-time” means that the period of use is temporary and the number of times of use is Meaning at least the former of a one-time use).
  • such a password may be referred to as a “common 1-day password”.
  • the password may not be tpw (common 1-day password).
  • the password may be a temporary password of a type different from tpw (eg, a one-time password) or a general fixed password that can only be used in one service system.
  • AAA list information may be described using the expression “AAA list”, but the information may be expressed in any data structure. That is, the “AAA list” can be referred to as “AAA information” to indicate that the information does not depend on the data structure.
  • the configuration of the list (table or a database including the table) is an example, and two or more lists may be combined into one list, or one list may be divided into a plurality of lists.
  • the “storage unit” may be one or more storage devices including a memory.
  • the storage unit may be at least a main storage device of a main storage device (typically a volatile memory) and an auxiliary storage device (typically a nonvolatile storage device).
  • the auxiliary storage device may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).
  • U M there are two user terminals per user (or more), but there may be one user terminal per user.
  • U M may serve as the second user terminal and the first user terminal.
  • reqPw, APP, or pList there may be one reqPw, APP, or pList regardless of whether C (j) is one or plural, and reqPw, APP, or pList for each C (j). May be present. In the following description, it is assumed that reqPw, APP, and pList are all one regardless of the number of C (j) .
  • Example 1 will be described below.
  • the user (U) enters reqPw (for example, the value “xxxx”) on the screen displayed by the APP executed by the U M owned by the user (U), and U M (APP) is input based on the input reqPw.
  • tReqPw (1) is generated, and a tpw issue request is transmitted to C (1) (step 50).
  • the tpw issuance request is associated with (included ) the generated tReqPw (1) and Pass 1 (1) issued by C (1) and stored in U M in the pre-registration.
  • S 1 (1) specifies U corresponding to mID 1 (1) received from C (1) . Then, S 1 (1) is, uID 1 (1) is input, adapted to uID 1 (1) which is registered in advance, and, entered tpw is the tpw received from C (1) It is determined whether or not they match (step 57). If the determination result is affirmative, S 1 (1) provides service to U.
  • Figure 2 shows an example of the configuration of U M.
  • the UM is a mobile terminal, for example, a smartphone.
  • a smartphone is a type of smart device.
  • a smart device is a multifunctional device that can be used not only for calculation processing but also for various applications, and is typically a smartphone or a tablet PC.
  • the UM includes a touch panel display 211, a storage unit 213, an I / F (communication interface device) 214, and a processor 212 connected thereto.
  • the touch panel display 211 is an example of an input device and a display device, and is a device in which the input device and the display device are integrated.
  • the storage unit 213 stores programs such as APP and information such as pList.
  • the processor 212 executes APP.
  • Figure 3 shows an example of the configuration of U P.
  • FIG. 6 shows a configuration example of uList i (j) (uList 1 (1) ).
  • the names of information elements in the list are written in upper case letters.
  • one line (record) in the list is referred to as “account”.
  • FIG. 8 shows a configuration example of pList.
  • FIG. 10 shows a configuration example of cList (j) (cList (1) ).
  • FIG. 11 shows tpw provision by C (1) .
  • C (1) When C (1) receives a tpw issuance request for one S i (1 ) from U (U M ), all of the S i (j) (aList (1 ) to S i (1)) respectively corresponding to all sysID i identified (1) from performing provide tpw (for example, a value "1234") (and mID i (1)).
  • S i (1) with which the user has a contract is S 1 (1) , S 2 (1), and S 3 (1) .
  • C (1) is, to the tpw to tpw without inquiry from S i (1) may be provided to the S i (1), the tpw in response to tpw inquiry from S i (1) S i ( 1) may be provided.
  • U (U P ) is the same tpw until the deadline indicated by tpwInfo i (1) associated with tpw (for example, one day of the day (not necessarily 24 hours, 23:59 of the day (00:00 of the next day) You can log in to any Si (1) you subscribe to.
  • tpwInfo i (1) may be different for each S i (1), tpwInfo i (1) may be the same in a plurality of S i (1).
  • FIG. 12 shows an example of the initial registration flow.
  • the initial registration is pre-registration for using S i (1) for U that is not registered in C (1) .
  • Initial registration involves two steps. The first stage is a procedure performed between U and S i (1), and the second stage is a procedure performed between U and C (1) .
  • Step 1201 U (U P ) transmits a use application to S 1 (1) . At that time, U (U P ) determines uID 1 (1) to be used in S 1 (1) .
  • Step 1202 S 1 (1) receives a use application from U (U P ), responds to the application, determines suKey 1 (1) with U, and assigns an account to uList 1 (1). to add. S 1 (1) registers the determined uID 1 (1) as the UID in the added account, and registers the determined suKey 1 (1) as the SUKEY.
  • Step 1203 S 1 (1) transmits a user addition request associated with sysID 1 (1) to C (1) .
  • Step 1204 C (1) receives the user addition request, and determines mID 1 (1) corresponding to both sysID 1 (1) and U to be added in response to the request, and aList ( Add an account to 1) .
  • C (1) registers the determined sn (for example, the serial number of the account) as the SN in the added account, registers sysID 1 (1) associated with the user addition request as the SYSID, and sets it as the MID. Then, the determined mID 1 (1) is registered.
  • the determined sn may be referred to as “sn1”.
  • Step 1205 C (1) generates a registration ticket (hereinafter referred to as Ticket), and transmits the generated Ticket and mID 1 (1) determined in Step 1204 to S 1 (1) .
  • the ticket is based on the first electronic signature (hereinafter referred to as Sign1), cID (1), and the registered sn1 and sysID 1 (1) .
  • Sign1 is based on cID (1) and the registered sn1 and sysID 1 (1) .
  • sn is an information element (for example, a serial number) used by C (1) to identify a user.
  • cID (1) is an information element used by APP to specify which C (j) should be registered (cID (j) is the information required for communication with C (j). The information necessary for communication with C (j) and cID (j) may be associated with each other in APP in some way).
  • the ticket may not have sysID 1 (1) .
  • aux may include some information element (for example, at least part of OTHERS ) in uList 1 (1) . Sign1 may not have aux.
  • Step 1206 S 1 (1) receives Ticket and mID 1 (1) from C (1) .
  • S 1 (1) associates uID 1 (1) registered in step 1202 with the received mID 1 (1) .
  • S 1 (1) registers the received mID 1 (1) as an MID in the account having uID 1 (1) registered in step 1202.
  • Step 1207 S 1 (1) includes a Ticket received, the Sukey 1 (1) and registered in step 1202, and transmits to the U (U P).
  • the second stage (procedure performed between U and C (1) ) is step 1208 to step 1211 below.
  • Step 1208 U determines reqPw, and inputs the determined reqPw and Ticket and suKey 1 (1) received by U P to U M.
  • APP of U M determines a random number (Rand), generates a tReqPw (1).
  • tReqPw (1) is based on the determined Rand and the input reqPw (hereinafter, the determined Rand may be referred to as “Rand1”).
  • tReqPw (j) plays the role of a password, but reqPw is encrypted indecipherably by a collision-resistant one-way function or the like, so the confidentiality of reqPw can be maintained.
  • the function h for generating tReqPw may be different for each control center as indicated by h j . Thereby, U can register different tReqPw for each control center only by memorizing one reqPw.
  • U M (APP) transmits Ticket and tReqPw (1) to C (1) specified from cID (1) in the Ticket.
  • U M sends (Rand and reqPw to C (1) , and C (1) generates tReqPw (1) using Rand1 and reqPw from U M.
  • Rand may be omitted, but the presence of Rand can prevent tReqPw (1) from having the same value for the same U in aList (1) of C (1) .
  • C (1) receives Ticket and tReqPw (1) from U M (APP).
  • C (1) determines whether the Ticket is correct by determining whether the Sign1 in the received Ticket is correct. When the determination result is affirmative, C (1) specifies from aList (1) an account including an SN that matches sn in the Ticket.
  • C (1) generates aID (1) for APP (U M ) that is the sender of Ticket, registers the generated aID (1) as AID in the specified account, and receives tReqPw as TREQPW Register (1) .
  • tReqPw (j) plays the role of a password, but reqPw is encrypted indecipherably by a hard collision one-way function etc., so even if tReqPw (j) leaks from aList ( 1) , Confidentiality can be maintained.
  • Step 1210 C (1) generates a Pass 1 (1), and transmits the generated Pass 1 (1) to the U M (APP).
  • Pass 1 (1) includes a aList (1) to the already registered sn1, cID (1) and sysID 1 (1), and aID (1) registered in step 1209, the second electronic signature (hereinafter, Sign2) and based.
  • Sign2 the second electronic signature
  • AID of Pass 1 (1) in (1) after use in order to identify all (or part) S i (1) on which to issue the tpw when receiving the tpw request request from U M is an information element that is (aList (more sysID i (1) are associated with the same aID (1) in 1)).
  • U M (APP) receives Pass 1 (1) from C (1) and adds an account to pList.
  • U M (APP) registers sysID 1 (1) in Pass 1 (1) (or Ticket) as the SYSID in the added account, and cID in Pass 1 (1) (or Ticket) as the CID. (1) to register, as RAND, registers Rand1 determined in step 1208, as AID, as registered aID 1 (1) of Pass 1 (1) in PASS, registers the Pass 1 (1) received Then, suKey 1 (1) input in step 1208 is registered as SUKEY.
  • the account pList e.g.
  • information U M is stored (e.g., the individual identification information and the future, It may be encrypted using at least one of my number (and at least one of the information accompanying it) and information stored in U (for example, reqPw) as an encryption key (cID (1) and sysID 1 (1) is an open information element and may not be encrypted).
  • FIG. 13 shows an example of the registration flow for the second and subsequent times.
  • aID (1) obtained at the time of initial registration can be used.
  • the first stage is the same as the first stage of the initial registration (steps 1301 to 1307 are the same as steps 1201 to 1207, respectively).
  • the second stage (procedure performed between U and C (1) ) is as follows. Mainly, the differences from the second stage of the initial registration are described, and the explanation of the common points with the second stage of the initial registration is omitted or simplified.
  • Step 1308 U inputs reqPw (information stored by U) used by U for the initial registration and Ticket and suKey 2 (1) received by U P to U M.
  • U M (APP) displays pList on the touch panel display 211 and receives an account to be used from U.
  • U M (APP) acquires Rand1, cID (1) , sysID 1 (1) , aID (1), and Pass 1 (1) from the account selected by U.
  • U M (APP) determines whether the cID (1) in the input ticket is the same as the cID (1) acquired from the selected account. If this determination is negative, U M (APP) may be stopped as a registration failure.
  • C (1) receives Ticket, Pass 1 (1) and tReqPw (1) from U M (APP).
  • C (1) determines whether the ticket is correct by verifying Sign1 in the received ticket. If the determination result is affirmative, C (1) specifies an account including SN that matches sn (hereinafter referred to as sn2) in Ticket from aList (1), and from received Pass 1 (1). Get aID (1) .
  • C (1) registers sn2 in the Ticket as the SN in the identified account, registers the acquired aID (1) as the AID, and registers the received tReqPw (1) as the TREQPW.
  • U M (APP) receives Pass 2 (1) from C (1) and adds an account to pList.
  • U M (APP) registers sysID 2 (1) in Pass 2 (1) (or Ticket) as the SYSID in the added account, and cID in Pass 2 (1) (or Ticket) as the CID.
  • (1) (or cID (1) acquired in step 1308) is registered, Rand1 acquired in step 1308 is registered as RAND, received Pass 2 (1) is registered as PASS, and SUKEY is registered as The suKey 2 (1) input in step 1308 is registered.
  • the pre-registration includes the first registration and the second and subsequent registrations.
  • U may clearly indicate to U M (APP) whether it is the first registration or the second and subsequent registrations.
  • a screen for example, a GUI (Graphical User Interface) having an initial registration button and a second and subsequent registration button
  • U can select either of the processes after the initial registration for C (1) .
  • the first registration may be selected, in which case a plurality of different aIDs (1) for the same U will be registered in C (1) . whether the either second or subsequent registration with, is whether associate aID (1) identical to the plurality of different S i (1).
  • FIG. 14 illustrates an example of a tpw issue flow according to the first embodiment.
  • a group of a plurality of SYSIDs (here, all SYSIDs registered in the pList) is expressed as “SYSIDGroup”.
  • the Pass SYSIDPart for SYSIDPart ⁇ SYSIDGroup is set to ⁇ Pass i (1) ⁇ K.
  • K is sysID i (1) ⁇ SYSIDPart.
  • Pass SYSIDPart is a set of Pass i (1) respectively corresponding to sysID i (1) constituting SYSIDPart.
  • the flow of issuing tpw that U can use for all of SYSIDPart ⁇ SYSIDGroup is as follows.
  • U M (APP) displays at least a part of information of pList, for example, and receives from U the selection of SYSIDPart in SYSIDGroup of pList and the input of reqPw.
  • U M (APP) selects one Pass i (1) from Pass SYSIDPart .
  • U M (APP) acquires Rand from the account in which the selected Pass i (1) is registered, and generates tReqPw (1) using the acquired Rand and the input reqPw.
  • U M (APP) corresponds to the selected Pass i (1) for the tpw issue request that associates the SYSIDPart selected by U, the generated tReqPw (1), and the selected Pass i (1) . and transmits the C (1) identified from cID (1) it was.
  • the selection of SYSIDPart may be performed by U M (APP) instead of U.
  • Step 1402 C (1) receives a tpw issuance request from U M (APP), and in response to the request, CRe (1) determines whether or not tReqPw (1) associated with the request is correct. A determination is made and a second determination is made as to whether Pass i (1) associated with the request is correct. First determination, for example, a TREQPW in the account (account in aList (1)) which holds the sn consistent with sn in the Pass i (1), and tReqPw that with relation to the request (1) Is a determination as to whether or not.
  • Pass i (1) in an account holding the sn consistent with sn (aList (1) in an account) information element in the (CID, SYSID, AID) and, Pass i (1) in The information elements (cID (1) , sysID 1 (1) , aID (1) ) are used to determine whether Sign2 in Pass i (1) is correct.
  • C (1) may stop the process. If both the result of the first determination and the result of the second determination are affirmative, C (1) performs Step 1403.
  • C (1) determines tpw.
  • tpw may be a random value, for example.
  • C (1) does the following for each sysID i (1) ( ⁇ SYSIDPart): In the description of steps 1404 to 1407, one sysID i (1) is taken as an example.
  • C (1) is in S i (1) corresponding to the sysID i (1), and transmits the mID i (1) corresponding to the S i (1), determined the tpw (mID i ( A tpw registration request that associates 1) with tpw is sent to S i (1) ).
  • C (1) transmits tpw without a query from S i (1), but as described above, tpw is transmitted in response to a query from S i (1). Also good.
  • S i (1) receives a mID i (1) corresponding to the S i (1), and a tpw determined from C (1).
  • S i (1) identifies from uList i (1) the account in which the MID that matches the received mID i (1) is registered.
  • S i (1) registers the received tpw as the TPW in the specified account.
  • S i (1) determines tpwInfo i (1) for the tpw, and registers the determined tpwInfo i (1) as TPWINFO in the account.
  • the tpwInfo i (1) may include information indicating the tpw limit such as the expiration date and the number of times that the tpw can be used.
  • tpw means a common 1-day password, and therefore, as usage restrictions, the usage period “until just before 00:00 on the tpw issue date” and the usage count “unlimited” Contains tpwInfo i (j) .
  • Step 1406 S i (1) acquires SUKEY (suKey i (1) ) from the account specified in Step 1405.
  • S i (1) encrypts information mes i (j) (mes i (1) ) including the registered tpwInfo i (1 ) with the acquired suKey i (1) .
  • eMes i (1) Encrypted information of mes i (1)
  • Enc SUKEY (mes i (1) )
  • S i (1) transmits the obtained eMes i (1) to C (1) .
  • mes i (j) may include information related to S i (1) in addition to tpwInfo i (1) .
  • the information related to S i (1) may include U's uID i (1) (UID acquired from the account identified in step 1405).
  • the encryption function (Enc) may be, for example, a predetermined common key encryption method.
  • eMes i (1) is information that reaches U M (APP) through C (1) , as will be described later. Then, eMes i (1), due U M (APP), is decrypted using the same and Sukey was used to encrypt i (1) suKey i (1 ). That is, mes i (j) is obtained.
  • U M (APP) displays at least part of the information in the obtained mes i (j) (for example, uID i (1) ) on the touch panel display 211.
  • U M (APP) receives ⁇ eMes i (1) ⁇ M and tpw from C (1) .
  • U M (APP) performs the following for each eMes i (1) included in ⁇ eMes i (1) ⁇ M : Take one eMes i (1) as an example.
  • U M (APP) specifies an account corresponding to eMes i (1) from pList.
  • U M (APP) acquires SUKEY from the specified account (suKey i (1)), using the obtained suKey i (1)), to decrypt the eMes i (1). Thereby, mes i (1) is obtained.
  • U M (APP) displays and registers at least one of the information elements in the obtained mes i (1) with the specified account.
  • U M (APP) may also register the received tpw in that account.
  • U M (APP) may display the received tpw on the touch panel display 211.
  • the flow is the same as the flow described with reference to FIG. Specifically, for example, Hereinafter, takes one S i (1) in Example (In the use phase of S i (1), already in ulist i (j) of the S i (1), setting tpw provided to U Have been).
  • U is the U P, enter a tpw and uID i (1).
  • S i (1) receives a service provision request from U ( UP ).
  • the service providing request, uID i (1) and tpw input to U P is attached related.
  • S i (1) verifies its uID i (1) and tpw.
  • S i (1) determines whether there is an account in uList i (1) in which UID and TPW that respectively match uID i (1) and tpw are registered. If the determination result is affirmative, S i (1) provides a service to U (U P ) (for example, login is permitted).
  • the tpw expiration date (the expiration date represented by tpwInfo i (1) associated with tpw) does not necessarily have to be 24 hours or 23:59 of the day.
  • the number of times of use (N times (N is an arbitrary value of an integer equal to or greater than 1)) may be defined as the limit of tpw.
  • tpwInfo i (j) may be different for each S i (j) .
  • U M (APP) can display uID i (1) used by all (or a part) of S i (1) used by U.
  • U M (APP) may issue a user ID query to C (1) in response to a request from U.
  • the flow from issuance of a user ID inquiry to a response may be the same as the flow from issuance of a tpw issuance request to a response.
  • S i (1) from C (1) encrypted user ID through (encrypted with Sukey i (1) the uID i (1)) may be included.
  • the response may include one or more encrypted user IDs corresponding to all (or a part) used by U.
  • U M (APP) may decrypt the encrypted user ID using suKey i (1) and display the decrypted user ID.
  • C (1) may hold at least one S i (1) , instead of sending tpw without a query from S i (1) (for example, C (1) itself ) , Tpw may be registered in the account corresponding to S i (1) ( account in aList (1) ).
  • S i (1) receives a service provision request from U (U P )
  • it sends a tpw query that associates mID i (1) for U to C (1).
  • Good When C (1) receives the tpw query, C (1) identifies the tpw corresponding to mID i (1) associated with the tpw query, and identifies the identified tpw as the source S i (1) of the tpw query. May be sent to
  • U is freed from the hassle of managing IDs and passwords. If you obtain tpw (common 1-day password) once a day, you can log in to all (or part of) S i (1) used by U using the same tpw on that day. become. This frees you from the hassle of management. Further, even forget uID i (1), uID i (1) is displayed on the U M. This point also contributes to the release of management annoyance.
  • tpw common 1-day password
  • tpw cannot be used in one day (the expiration date indicated by tpwInfo i (1)) . For this reason, even if tpw is stolen, it cannot be used the next day. Therefore, safety is increased. In addition to the expiration date of tpw, it is expected that the safety can be further improved by limiting the number of usable times. Further, from a user terminal other than U M used in pre-registration can not acquire tpw. Because the user terminal other than U M, is because the pList the information elements acquired when the pre-registration has been registered is not present. This also contributes to the improvement of safety. Also, even if U M is picked up by another person, reqPw stored in U is required when making a tpw issuance request, so if reqPw is not known to others, tpw may be acquired by others. No.
  • Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.
  • Example 2 there are two or more C (j) .
  • C (1) and C (2) exist.
  • the C (1), S 1 ( 1) and S 2 (1) is registered, in C (2), and S 1 (2) and S 2 (2) are registered.
  • U has registered in these four service systems (S 1 (1) , S 2 (1) , S 1 (2), and S 2 (2) ).
  • U uses the information registered in pList when registering S 1 (1) for registration of S 2 (1) , and U for registration of S 1 (2) for registration of S 2 (2) .
  • the information registered in pList is not used.
  • initial registration is performed for both S 1 (2) and S 2 (2) .
  • AID is the same value
  • RAND is also the same value.
  • CID is also the same value.
  • the pList is as shown in FIG. That is, the AID associated with S 2 (1) is the same as aID (1) , that is, the AID associated with S 1 (1) .
  • the AID associated with S 2 (2) is different from aID (2 ′) , that is, the AID associated with S 2 (1) .
  • U M (APP) may perform the tpw issue flow according to the first embodiment for each C (j) . However, in this case, tpw differs for each C (j) , which is not convenient for U.
  • tpw can be shared by two or more C (j) .
  • FIG. 17 shows an example of a tpw issue flow according to the second embodiment.
  • the tpw issuance flow according to the first embodiment is performed between U M (APP) and C (1) (the transmission destination of the first tpw issuance request on that day).
  • U M (APP) receives tpw from C (1) .
  • the U M (APP) that has received tpw performs the following processing with each of the other C (J) (where J is an integer of 2 or more ) where U is registered.
  • U M (APP) transmits a tpw issue request that associates the tpw received from C (1) to C (J) .
  • C (J) receives a tpw issue request associated with tpw.
  • C (J) does not issue tpw, but transmits tpw associated with the received tpw issue request to each S i (j) registered in C (J) .
  • C (J) receives a response including eMes i (J) from each S i (J) .
  • U M (APP) is (sends tpw issued request that associates tpw) notifies the tpw to each of C (1) All C (j) other than, C (1) all but A response containing ⁇ eMes i (J) ⁇ M is received from each of C (j) (ie, from each C (J) ).
  • U uses the same tpw on the first day of the day, and any S i ( where j is an integer of 1 or more) registered in any C (j) You can also log in to j) (you can receive services). If an error occurs in communication with any C (j) other than C (1) among the control centers where U is registered, tpw issuance flow between U M (APP) and C (1) The processing may be restarted.
  • Example 3 will be described. At that time, the differences from the first and second embodiments will be mainly described, and the description of the common points with the first and second embodiments will be omitted or simplified.
  • the number of communications performed by U M (APP) can be reduced by exchanging information with C (j) (for example, U M (APP) is 2 or more C (j). Communication with C (1) only.
  • -SYSIDGroup (j) SYSIDPart, aID In pList, a set consisting of all sysID x (j) ( ⁇ SYSIDPart) where AID is aID (x means any value of i) AID SYSIDPart : A set of AIDs for each sysID x (x) ⁇ SYSIDPart ⁇ SYSIDGroup in pList ( subscript x means any value of i, superscript x means j value But that means it ’s okay) ⁇ Pass SYSIDPart, aID : A set consisting of PASS for all accounts where SYSID is the origin of SYSIDPart and AID is aID.
  • FIG. 18 shows an example of a tpw issue flow according to the third embodiment.
  • Step 1801 U selects SYSIDPart ( ⁇ SYSIDGroup), and inputs reqPw and SYSIDPart to U M (APP). At this time, it is assumed that AID SYSIDPart is ⁇ aID1, ..., aIDN ⁇ . Hereinafter, one aIDW is taken as an example (1 ⁇ W ⁇ N). It is assumed that j corresponding to aIDW is “JW”.
  • Step 1802 C (J1) determines whether or not PassW is correct.
  • Step 1803 If the judgment result in Step 1802 is affirmative, C (J1) refers to aList (J1) , holds the same AID as aID1 included in Pass1, and SYSID (sysID i (J1) ) Get the MID (mID i (J1) ) for each account that is the origin of SYSIDPart. If the determination result in step 1802 is negative, C (J1) sets the value of the state st i (J1) to “false” for all sysID i (J1) ⁇ SYSIDGroup (J1) SYSIDPart, aID1 . C (J1) manages st i (J1) for each S i (j) . st i (J1) means whether tpw registration is successful (true) or not (false).
  • Step 1804 C (J1) issues a tpw, each S i (J1) which is identified if the determination result in step 1802 is affirmative, transmits tpw and mID i a (J1).
  • Step 1805) tpw and mID i (J1) has been received
  • S i (J1) identifies an account mID i (J1) is registered from ulist i (J1), defines tpwInfo i (J1), generating a mes i (J1) which includes the TpwInfo i a (J1).
  • S i (J1) registers the received tpw as the TPW in the specified account and registers the defined tpwInfo i (J1) as the TPWINFO.
  • S i (J1) sets the value of st i (J1) to “true”. If the U in S i (J1) does not exist, the value of st i (J1) is set to “false”.
  • C (J1) has received the value of st x (x) and mes x (x) from all S i (J1) ( ⁇ SYSIDPart) registered in C (J1) .
  • C (J1) performs the following for 2 ⁇ W ⁇ N.
  • JW ⁇ J1 for each W ( ⁇ 1).
  • Step 1807) C (J1) transmits SYSIDGroup (JW) SYSIDPart, aIDJW , tReqPwW, and PassW to C (JW) .
  • C (JW) sends token i (JW) , st i (JW) , and mID i (JW) to C (J1) (token i (JW) is st i (JW) , mID i (JW) may be included).
  • Step 1811 Each S i (JW) that has received mID i (JW) , tpw, and token i (JW) determines whether token i (JW) is correct. If the judgment result is affirmative, S i (JW) identifies an account mID i (JW) is registered from uList i (JW), defined TpwInfo i a (JW), the tpwInfo i (JW) Generate mes i (JW) containing. S i (JW) registers the received tpw as the TPW in the specified account, and registers the defined tpwInfo i (JW) as the TPWINFO.
  • S i (JW) sets the value of st i (JW) to “true”.
  • S i (JW) returns st i (JW) and eMes i (JW) to C (J1) . If token i (JW) is incorrect, S i (JW) may set the value of st i (JW) to “false” and return the st i (JW) to C (J1) .
  • Step 1812 C (J1) receives a response including st i (JW) and eMes i (JW) from S i (JW) .
  • Step 1813 C (J1) receives a response including st i (JW) and eMes i (JW) from each S i (JW) ⁇ SYSIDGroup (JW) aIDw (2 ⁇ w ⁇ N) In this case, tpw issued in step 1804 and all (st i (JW) , eMes i (JW) ) are returned to U M (APP).
  • U M (APP) decrypts each eMes i (JW) , so U is sent from all S i (JW) ⁇ SYSIDPart and each S i (JW) ⁇ SYSIDPart tpwInfo i (JW) (information including tpw expiration date) can be obtained.
  • C (J1) is C (1)
  • C (JW) is C (2) .
  • Example 4 will be described. At that time, differences from the first to third embodiments will be mainly described, and description of common points with the first to third embodiments will be omitted or simplified.
  • Example 4 relates to the issuance of a common password (tpw) to a plurality of registered in the plurality of C (JW) S i (JW ), C (J1) is registered in another C (JW) The registration process for the existing S i (JW) is left to the C (JW) .
  • tpw common password
  • FIG. 20 illustrates an example of a tpw issue flow according to the fourth embodiment. Differences from FIG. 19 will be mainly described. At this time, C (J1) is C (1), and C (JW) is C (2) .
  • C (1) sends tpw to C (2) in addition to sysID 2 (2) , tReqPw (2) and Pass 2 (2) (step 2007), and C (2) sends tpw, sysID 2 ( 2) tReqPw (2) and Pass 2 (2) are received from C (1), and it is determined whether Pass 2 (2) is correct (step 2008). If the determination result is affirmative, C (2) transmits tpw and mID 2 (2) to S 2 (2) (step 2009). S 2 (2) registers tpw and tpwInfo 2 (2) in uList 2 (2) (step 2010), and returns st 2 (2) and eMes 2 (2) to C (2) (step 2011). .
  • C (2) transmits st 2 (2) and eMes 2 (2) to C (1) (step 2012). That is, st 2 (2) and eMes 2 (2) are sent from S 2 (2) to C (1) through C ( 2) . Thereafter, C (1) includes a tpw, respectively received from S 1 (1) and S 2 (2) (st 1 (1), eMes 1 (1)) and (st 2 (2), eMes 2 ( 2) ) is returned to U M (APP) (step 2013).
  • an access token (token i (JW) ) that allows C (JW) to register tpw with S i (JW) registered in its own sList i (JW ). Is transmitted to C (J1) together with mID i (JW) in S i (JW) . Since the secret key ckey i (JW) is shared between C (JW) and each S i (JW) , mID i (JW) can be encrypted and transmitted to C (J1) .
  • token i (JW) may be a one-time-use signature, but token i (JW) expiration date, authority restrictions, etc. may be associated with token i (JW) , in which case C (J1) is the first You can use sysID i (JW) , mID i (JW) , and token i (JW) received in the next time. For this reason, communication between C (J1) and C (JW) and communication between C (JW) and S x (JW) can be omitted.
  • FIG. 21 shows an example of the tpw issue flow according to the fifth embodiment. Differences from FIG. 19 will be mainly described.
  • S 2 (2) determines whether or not the assertion is correct by the policy execution point 2100 (step 2110). If the determination result is affirmative, S 2 (2) may notify C (1) of the determination result (OK), or keep the determination result without notifying C (1) . May be.
  • S 2 (2) returns st 2 (2) and eMes 2 (2) to C (1) (step 2113).
  • C (1) is received from tpw and S 1 (1) and S 2 (2) , respectively (st 1 (1) , eMes 1 (1) ) and (st 2 (2) , eMes 2 (2) ) Is returned to U M (APP) (step 2113).
  • Example 6 will be described. At that time, the differences from the first to fifth embodiments will be mainly described, and the description of the common points with the first to fifth embodiments will be omitted or simplified.
  • tpw is issued.
  • other types of control regarding tpw for example, tpw change, tpw deletion, and the like are performed.
  • a tpw issue request is an example of a tpw control request.
  • An example of tpw control is tpw issuance, and an example of a control center (identification code control device or identification code control system) is a control center.
  • the information element associated with the tpw control request may be the same as the information element associated with the tpw issue request.
  • APP is also used for tpw control other than tpw issuance.
  • tpw control will be described by taking tpw deletion as an example.
  • delete tpw means “to disable tpw authentication and prevent anyone including U from logging in until the next tpw issuance request”.
  • FIG. 6 shows an example of a tpw deletion flow according to the sixth embodiment.
  • Step 2201 U M (APP) performs the same processing as Step 1401 of FIG. However, in this embodiment, a tpw deletion request is transmitted instead of the tpw issue request.
  • Step 2202 C (1) receives a tpw deletion request from U M (APP) and determines whether Pass i (1) associated with the request is correct in response to the request. .
  • Step 2203 C (1), if the determination result is affirmative in step 2202, it has the AID that reference to aList (1), consistent with the right and the determined Pass i (1) in the aID (1) And identify all accounts having SYSIDs that match any of the sysID i (1) in the SYSIDPart associated with the tpw delete request.
  • C (1) acquires MID (mID i (1) ) from all the specified accounts.
  • Step 2204 C (1) performs the following for each sysID i (1) ( ⁇ SYSIDPart).
  • ⁇ SYSIDPart ⁇ SYSIDPart
  • one sysID i (1) is taken as an example.
  • C (1) is in S i (1) corresponding to the sysID i (1), and transmits the tpw removal request that associates mID i (1) corresponding to the S i (1).
  • S i (1) receives a tpw deletion request mID i (1) is equipped with relevant from C (1).
  • S i (1) specifies from uList i (1) an account in which an MID that matches mID i (1) associated with the received request is registered.
  • S i (1) deletes the authentication factors tpw and tpwInfo on the specified account.
  • Step 2206 S i (1) transmits a deletion completion response to C (1) .
  • Step 2207 When C (1) receives responses from all S i (1) respectively corresponding to sysID i (1) ( ⁇ SYSIDPart), C (1) returns a response to the tpw deletion request as U M (APP) Send to. U M (APP) receives the response from C (1) .
  • tpw Can be controlled.
  • the deletion of tpw is effective when a password with no limitation on the expiration date and the number of times of use is adopted as the common password instead of tpw (that is, in the embodiment, the adopted password is:
  • the adopted password is:
  • it is a common 1-day password it is not limited to such a restricted password, and a password with no restrictions such as expiration date and number of times of use may be adopted.
  • Example 7 will be described. At that time, differences from the first to sixth embodiments will be mainly described, and description of common points with the first to sixth embodiments will be omitted or simplified.
  • At least one S i (j) transmits Info i (j) to a specific control center.
  • the “specific control center” is, for example, a control center in which S i (j) is registered, a control center that is a transmission source of a predetermined type of information element (for example, tpw or mID i (j) ), or U M
  • Info i (j) is, Info i issuing S i (j) is information output from the information including the S i (j) other than or information published on the service system (j) (The information included in Info i (j) may be information permitted to be disclosed by U).
  • Info i (j) may be included in a response from S i (j) in pre-registration (for example, a response in step 1203 in FIG. 12, a response in step 1303 in FIG. 13), In the control, a response from S i (j) (for example, a response in step 1406 in FIG. 14, a response in step 1812 in FIG. 18, a response in at least one of steps 2011 and 2012 in FIG. 20, step 2113 in FIG. ).
  • the Info i ulist i of (j) issuing the S i (j) (j), the issued Info i (j) is registered (INFO).
  • Info i (j) gathers at a specific control center, and as shown in FIG.
  • Info i (j) is registered in aList (j) of the control center.
  • Info i (j) is information related to the information permitted to be disclosed, information related to the permitted service system (for example, sysID i (j) , the name of the company providing the service system), and the period for which information is disclosed. Etc. may be included.
  • the specific control center (or S i (j) that has received the application ) is registered. to C (j)), queries the predetermined type of information (e.g., mID i (j corresponding to the application source U) may send inquiry) the associated (the query, the query S i C (j) received from (j) may be transferred to the specific control center).
  • the control center that received the inquiry sends information (for example, resume, resident's card) that is information in Info i (j) corresponding to mID i (j) and that is permitted to be released. , May be sent to the inquiry source S i (j) .
  • Example 8 will be described. At that time, differences from the first to seventh embodiments will be mainly described, and description of common points with the first to seventh embodiments will be omitted or simplified.
  • the eighth embodiment may be a modified example or a specific example of the seventh embodiment.
  • Each service system where U is registered manages U's personal information (for example, graduation certificate, qualification certificate, resume, medical record, my number (and associated information), etc.). If U's personal information is linked between service systems, at least within the scope permitted by U, the convenience is expected to improve.
  • U personal information instead of or in addition to U personal information, other types of information related to U can be considered as information to be linked, but at least part of the information to be linked depends on at least the type of information to be linked, It must not be browsed by unspecified persons (for example, persons other than those authorized by U and U (for example, cooperation source and cooperation destination)).
  • Example 8 the information can be linked between service systems without the information being viewed by unspecified persons.
  • U in the registration flow, U can know that information has been registered in S i (j) .
  • an existing specification relating to delegation of authorization information such as OAuth, can be applied to C (j) and S i (j) .
  • FIG. 31 illustrates an example of a registration flow according to the eighth embodiment.
  • C (1) exists as C (j) (FIG. 31 shows only S 1 (1) among a plurality of S i (1). ).
  • the information elements described below are stored in the U M.
  • the following information elements are registered in pList. Further, at least one of the information elements described below, may be stored after being encrypted information including the U M-specific information as a key.
  • Pass i (1) Information requesting approval of a request to be sent to C (1) (request request pass).
  • SuKey i (1) A shared key necessary for communication with S i (1) .
  • the following information elements are stored in S i (1) .
  • the following information elements are registered in uList i (1) .
  • At least one of the following information elements may be encrypted and stored.
  • ⁇ UID i (1) information shared between the S is a user ID for the use of i (1) U and S i (1).
  • AuthInfo i (1) U authentication information (for example, password other than TempPw (for example, fixed password)).
  • VerAuthInfo i (1) Information for verifying authInfo i (1) .
  • ⁇ MID i (1) S is a management ID of i (1), (different for each U) information shared between C (1) and S i (1). When information is linked, mID i (1) of the link source or link destination is stored.
  • SuKey i (1) A shared key required for communication with U M.
  • VerRegToken Information for verifying the registration completion check token (regToken).
  • TempPw Temporary password (eg tpw).
  • TempPwInfo Information related to the TempPw restriction, including, for example, at least one of an expiration date (period), the number of times of use (TempPwTimes), and the number of times of use (TempPwTimesMax).
  • SID cooperation ID. This is an ID used for information cooperation, and is an ID for uniquely identifying cooperation.
  • AttList i (1) A list of information attributes (att) (details will be described later).
  • the following information elements are stored in C (1) .
  • the following information elements are registered in at least aList (1) of aList (1) , sList (1), and cList (1) .
  • At least one of the following information elements may be encrypted and stored.
  • VerTicket Information necessary for verifying the registration ticket (ticket) for the account of aList (1) .
  • AID (1) ID of APP. As described above, there may be a plurality of different aIDs (1) for one C (j) and one APP.
  • VerPass i (1) information required for verification (device authentication of U M) of Pass i (1).
  • SID cooperation ID.
  • SysID i (1) Service system ID of S i (1) .
  • Att information attribute (eg name, email address, etc.). As att, available att and acceptable att are stored. Information including one or more att values (values according to att) is cooperation target information (Info).
  • EInfo Encrypted cooperation target information (Info).
  • AccessToken OAuth access token used for communication between C (1) and S i (1) .
  • the registration flow according to Example 8 is as follows as shown in FIG.
  • the registration flow includes a first registration procedure that is a procedure between U and S i (1) , and a second registration procedure that is a procedure between U and C (1) .
  • the first registration procedure includes the following (R1) to (R6)
  • the second registration procedure includes the following (R7) to (R10).
  • R1 U M (e.g. APP) sends the user information according to the policy of S i (1) to S i (1), uID i (1) for logging into S i (1) and authInfo i ( Define 1) .
  • (R2) S i (1) converts and stores the user information received in (R1) as necessary.
  • R3 S i (1) sends an account addition request associated with sysID i (1) and the registration password (rpw) to C (1) .
  • rpw may be information determined by U itself and notified to S i (1) by U M (or U P ), or may be information determined by S i (1) .
  • C (1) receives an account addition request associated with sysID i (1) and rpw.
  • R4 C (1) performs the following processing in response to the account addition request. That, C (1) is created by one account (add the account, for example aList (1)), with respect to that account, assign mID i (1) (registers). Further, C (1) generates a registration ticket (ticket) for the account. Thereafter, C (1) sends the assigned mID i (1) , the received sysID i (1) , and verTicket (information necessary to verify the validity of the registration ticket) to its own database (eg, aList (1) Register in). The ticket contains information identifying the corresponding account. C (1) transmits the assigned mID i (1) and the generated ticket to S i (1) . S i (1) receives mID i (1) and ticket.
  • S i (1) adds a single account (add the account one to ulist i (1)), determine the key Sukey i (1) required to encrypt communications with the U M, uID i (1) , mID i (1) and suKey i (1) are registered in the account. Further, S i (1) generates a registration completion check token (regToken) and registers information (verRegToken) necessary for verifying it in the account.
  • RegToken registration completion check token
  • verRegToken registers information
  • (R7) U M sends a registration request associating ticket, suKey i (1) , rpw, regToken, and reqPw to C (1) .
  • C (1) receives a registration request associated with ticket, suKey i (1) , rpw, regToken, and reqPw.
  • the ticket, suKey i (1) , rpw, and regToken may be information received from S i (1) or may be information input by U.
  • reqPw may be information determined by U or APP.
  • C (1) performs the following processing in response to the registration request. That is, C (1) verifies the validity of the ticket using verTicket (and rpw). If the ticket is correct, C (1) identifies an account from the ticket and creates and registers aID (1) and Pass i (1) for the identified account. In addition, C (1) is information (verTReqPw (information necessary for tReqPw verification) and verPass i necessary for verification of aID (1) and Pass i (1) and reqPw associated with the registration request.
  • (R9) C (1) transmits mID i (1) and regToken to S i (1) .
  • S i (1) receives mID i (1) and regToken, and verifies regToken by using verRegToken in the account where the received mID i (1) is registered. If regToken is valid, S i (1) recognizes that the account is ready for three-way authentication.
  • (R10) C (1) transmits Pass i (1) to U M.
  • U M receives the Pass i (1), stores the Pass i (1) and suKey i (1).
  • the registration flow according to the eighth embodiment is the description of the registration flow according to the eighth embodiment.
  • the registration flow in another embodiment may be applied instead of the registration flow described with reference to FIG.
  • the registration flow according to the eighth embodiment may be applied in other embodiments.
  • OAtuth may be applied to another embodiment instead of or in addition to the eighth embodiment, but at least OAtuth is not essential to the present invention.
  • FIG. 25 illustrates an example of an authentication / cooperation flow according to the eighth embodiment.
  • S i (1) including S 1 (1) and S 2 (1) as S i (j) .
  • S 1 (1) is the cooperation source service system
  • S 1 (1) is the cooperation destination service system.
  • the process having “(authentication)” at the beginning is a process executed only when TempPw is issued such as tpw.
  • the process having “(cooperation)” at the beginning is a process executed only in the case of information cooperation.
  • a process without “(authentication)” or “(cooperation)” at the beginning is a process executed in both cases of issuing TempPw and information cooperation.
  • U M (APP) receives the selection of op from U.
  • “Op” is the operation type to be requested, specifically, for example, authentication, information linkage, or both.
  • authentication processing with “(authentication)” at the beginning is performed thereafter.
  • information cooperation processing with “(cooperation)” at the beginning is performed thereafter.
  • Both the process with “(authentication)” at the beginning and the process with “(cooperation)” are performed.
  • the process with “(authentication)” at the beginning and the process with “(cooperation)” at the beginning are performed in one process, they may not be performed in the other process. .
  • U M (APP) displays a list of sysID i (1) specified from all Pass i (1) stored in U M.
  • U M (APP) receives selection of aID (1) A (or sysID 1 (1) ) from the displayed list.
  • aID (1) A is, U is S 1 and login destination (1) aID in (service A) sysID 1 (1) has been registered account of (1).
  • U M (APP) receives selection of aID (1) A (or sysID 1 (1) ) and aID (1) B (or sysID 2 (1) ) from the displayed list.
  • aID (1) A is aID (1) in an account in which sysID 1 (1) of information linkage destination S 1 (1) is registered.
  • aID (1) B is aID (1) in the account in which sysID 2 (1) of information linkage source S 2 (1) is registered.
  • U M (APP) sends a request that associates the selected op with the Pass (at least Pass 1 (1) of Pass 1 (1) and Pass 2 (1) ) for the selected account and tReqPw. , Send to C (1) .
  • tReqPw is reqPw input from U in (P1) or information based thereon.
  • C (1) receives a request associated with op, Pass and tReqPw.
  • C (1) performs the following processing in response to the received request. That is, C (1) verifies the validity of tReqPw and Pass using verPass and verTReqPw in the account in which the received Pass and tReqPw are registered (hereinafter, the target account). If they are valid, C (1) accounts for mID 1 (1) (and mID 2 (1) ) corresponding to aID (1) A (and aID (1) B ) specified based on Pass. (E.g. aList (1) ).
  • C (1) is an acceptable information attribute (att) list (AttList 1 (1) ) for S 1 (1) corresponding to aID (1) A (mID 1 (1) ) ) And an attribute list (AttList 2 (1) ) of information attributes that can be provided to S 2 (1) corresponding to aID (1) B (mID 2 (1) ).
  • AttList i (1) is a list of information attributes (att), and includes at least one of an acceptable att and an att that can be provided. AttList i (1) contains both an acceptable att and an att that can be provided, and can be provided with an acceptable att when provided in response to a query from C (1) It may be narrowed down to one of the atts. AttList i (1) may be a list registered in advance from S i (1) , in which case the inquiry procedure may be omitted. As described above, S i (1) stores an att that can be provided and an acceptable att in advance.
  • C (1) transmits a common part of ATTLIST 1 (1) and AttList 2 (1) (att) to U M, U M displays the common part (att).
  • U M receives from U the selection of the linked information attribute att among the common parts, and transmits the selected att to C (1) .
  • C (1) receives the selected att.
  • (P4) (Authentication): C (1) generates tpw for the target account.
  • tpw is generated, but TempPw of a type other than tpw may be generated.
  • C (1) has associated sID generated in (P4), mID 2 (1) , att received in (P3), and sysID 1 (1) of cooperation destination S 1 (1)
  • a request (information provision request) is sent to the cooperation source S 2 (1) .
  • C (1) may also send the OAuth AccessToken to the cooperation source S 2 (1) .
  • the OAuth of AccessToken, authInfo 1 (1) cooperation destination S 1 (1) is transmitted to which may be information attribute (att) may have been written without.
  • the cooperation source S 2 (1) receives a request associated with sID, mID 2 (1) , att, and sysID 1 (1) (and AccessToken).
  • Coordination source S 2 (1) performs the following process in response to the request. That is, collaboration source S 2 (1) is, att values for U corresponding to mID 2 (1) coordination object information Info that contains (a value according to the received att), cooperator S 1 (1) which can be decoded Encrypt with key.
  • collaboration source S 2 (1) is, att values for U corresponding to mID 2 (1) coordination object information Info that contains (a value according to the received att), cooperator S 1 (1) which can be decoded Encrypt with key.
  • InfoB is written as “InfoB”
  • encrypted InfoB is linked to service A (S 1 (1) ). It is written as “eInfoBA”.
  • Cooperation source S 2 (1) encrypts InfoB with suKey 2 (1) .
  • the encrypted InfoB is expressed as “eInfoUB” in the sense that it is encrypted with a key shared with U.
  • S 2 (1) sends sID, eInfoBA, and eInfoUB to C (1) .
  • C (1) receives sID, eInfoBA, and eInfoUB.
  • C (1) may store the received sID, eInfoBA, and eInfoUB in the storage unit 511.
  • C (1) sends a request associating mID 1 (1) and tpw to S 1 (1) .
  • S 1 (1) receives the request associated with mID 1 (1) and tpw.
  • C (1) transmits a request that associates mID 1 (1) and sID to cooperation destination S 1 (1) .
  • C (1) may also send an OAuth AccessToken to the cooperation destination S 1 (1) .
  • the cooperation destination S 1 (1) receives the request associated with mID 1 (1) and sID (and AccessToken).
  • (P8) Authentication: S 1 (1) registers tpw and tpwInfo (for example, period, tpwTimesMax) for the tpw in the account corresponding to mID 1 (1) , and stores information including tpw and tpwInfo. Encrypt with suKey 1 (1) , and return eTpwInfo, which is the encrypted information, to C (1) .
  • U M is the information received in (P9) (eTpwInfo and at least one of EInfoUB), and decoded using the suKey 2 (1), and displays the decoded information.
  • U M (APP) may accept an answer to approve (OK) or cancel (NG) cooperation of the information to be linked, and notify C (1) of the accepted answer.
  • U may reply “NG” when at least a part of the information to be linked is incorrect or when it is no longer desired to link.
  • the answer means “NG” (cancel) C (1) cancels the cooperation, that is, the cooperation target information cannot be acquired by the cooperation destination S 1 (1) .
  • U P accesses the S 1 (1), eg for login, enter uID 1 (1) and authInfo 1 a (1) to S 1 (1). (Authentication): U P further inputs the tpw to S 1 (1).
  • S 1 (1) transmits to sID ( C ) (1) the sID for cooperation processing addressed to mID 1 (1) registered in S 1 (1) .
  • C (1) transmits eInfo (eg, eInfoBA) associated with the sID to S 1 (1) .
  • S 1 (1) receives and decodes the eInfo (eg, eInfoBA) (this gives InfoB).
  • the information to be linked is stored in the storage unit 511 managed by a person other than the cooperation source and the cooperation destination in an encrypted state, and the information is stored at the cooperation destination. Decoded by some S 2 (1) . For this reason, it can prevent that the information of cooperation object is browsed by an unspecified person.
  • C (1) may store in the storage unit 511 a certificate that the eInfoBA is information from service B (S 2 (1) ). . Alternatively or additionally, C (1) also sends a certificate that eInfoBA is information from service B (S 2 (1) ) to S 1 (1) in addition to eInfoBA. Also good.
  • the access key to the information link destination of the service system may be used.
  • the link may also be at least a part of the displayed information.
  • cooperation source and the cooperation destination are not limited to 1: 1 as in the above example, but may be 1: N (N is an integer of 2 or more) or M: 1 (M is an integer of 2 or more).
  • eInfo is sent from S 2 (1) to S 1 (1) via C (1) (storage unit 511), but instead, one of the following (a) to (c) May be adopted.
  • C (1) requests S 2 (1) to send InfoB to service A (S 1 (1) ).
  • S 2 (1) sends eInfo (or InfoB (unencrypted cooperation target information)) to S 1 (1) .
  • B) C (1) requests S 1 (1) to obtain Info from service B (S 2 (1) ).
  • S 1 (1) acquires eInfoBA (or InfoB) from S 2 (1) .
  • S 2 (1) sends to C (1) a link representing the location of eInfoBA (or InfoB) ( a storage device in or outside S 2 (1)) .
  • C (1) follows the link and obtains eInfoBA (or InfoB) and sends the eInfoBA (or InfoB) to S 1 (1) , or C (1) sends the link to S 1 (1 ) And S 1 (1) obtains eInfoBA (or InfoB) according to the link.
  • Example 8 Information linkage related to Example 8 is for U certification documents (for example, graduation certificate, qualification certificate, tax payment certificate, real estate register, etc.) from the university or organization that manages the certification material to companies, etc. It can be expected to be applied to various cases such as submitting, handing medical charts, etc. between hospitals, and passing my number (and information accompanying it) between companies.
  • U certification documents for example, graduation certificate, qualification certificate, tax payment certificate, real estate register, etc.
  • At least part of the cooperation target information may not be encrypted. Whether to encrypt at least a part of the cooperation target information may be selected by the user (for example, in step 2501, the user may specify whether to encrypt each piece of cooperation target information). However, whether or not encryption is performed by the cooperation source service system may be controlled according to the importance or type of the cooperation target information.
  • Link target information EK 1 (1) may be the public key of S 1 (1)
  • link target information DK 1 (1) (decryption key) is S 1 (1)
  • a private key is sufficient.
  • the encryption key / decryption key may be another type of key such as a common key instead of the public key / secret key.
  • the key may be passed between S 1 (1) and S 2 (1) via a user terminal (specifically, for example, transmitted from S 2 (1) to C (1).
  • C (1) checks whether the cooperation target information is harmless (for example, whether it can be displayed), that is, The presence or absence of malware (for example, a virus or a remote operation program) may be checked.
  • the tpw issue request can also serve as an information linkage request (a request for sharing information between service systems), but the information linkage request may be independent of the tpw issue request.
  • U M is a different timing from the issuance of tpw issued request
  • information sharing request eg, service A (S 1 (1)) from the service C (S 2 (1)) in that the linking information Request
  • the above-described information cooperation may be performed in response to the information cooperation request.
  • both the cooperation source and the cooperation destination are selected by U, but at least one of the cooperation source and the cooperation destination is all service systems that C can use (C (1) is about U all service systems that can be identified from aList (1) .
  • S i (j) when S i (j) receives mID i (j) and tpw from C (j) , it can accept a service request (for example, a login request) from U.
  • a service request for example, a login request
  • the former state is a state where the authentication shutter is open, and the latter state is a state where the authentication shutter is closed.
  • An “authentication shutter” is a logical shutter for controlling acceptance of an authentication request.
  • S i (j) if the authentication shutter is open, when receiving the authentication request with uID i (j) and tpw, its uID i (j) and tpw is correct is determined whether the (authentication) Do. On the other hand, if the authentication shutter is closed, S i (j) rejects the authentication request without determining whether uID i (j) and tpw are correct.
  • the fact that the expiration date of tpw has passed means that the state of the authentication shutter has changed from open to closed, but the change from open to closed of the authentication shutter may be performed in response to a request from U.
  • FIG. 26 shows an example of the outline of identification code management.
  • TemporPw means a temporary password as described above, and is a concept including not only tpw but also general otp (one-time password).
  • FIG. 26 shows the relationship between TempPw and the control method.
  • TempPw In the case where TempPw is required, is the TempPw usable period (period until the expiration date) short (for example, several minutes) or long (for example, longer than the period corresponding to “short”), or is the number of times TempPw can be used fixed?
  • the type of TempPw used depends on whether it is unlimited. Specifically, for example, when the usable period of TempPw is “short” and the usable number of TempPw is “fixed”, TempPw used is a general otp (for example, the usable number of times is one). Limited otp).
  • TempPw to be used is tpw described above.
  • TempPw is not always necessary. There are cases where TempPw is not required. In that case, only the control using the authentication shutter described above may be used. A combination of certified shutter and TempPw is also possible.
  • S i (1) includes a shutter management server 2701-i that controls the opening and closing of the authentication shutter, and a service providing server 2702 that provides a service when authentication is successful. i and an authentication server 2703-i for performing authentication. That is, S 1 (1) has a shutter management server 2701-1, a service providing server 2702-1, and an authentication server 2703-1, and S 2 (1) has a shutter management server 2701-2, a service providing A server 2702-2 and an authentication server 2703-2.
  • both the shutter management server and the authentication server 2703-i may be shared by a plurality of S i (1). it can.
  • the authentication server 2703 exists outside S 1 (1) and S 2 (1) , and the authentication server 2703 is S 1 (1) and S 2 (1) may be shared. Further, as indicated by reference numeral 2700-3 in FIG. 27, the shutter management server 2701 is also present outside S 1 (1) and S 2 (1) , and the shutter management server 2701 has S 1 (1 ) And S 2 (1) .
  • S 1 (1) is taken as an example of S 1 (1) and S 2 (1) .
  • registration procedure 1 In authentication shutter control, registration procedure 1, registration procedure 2, authentication shutter operation procedure, and login procedure are performed.
  • U P is a request (Req_S), to the service providing server 2702-1 (Step 2801).
  • the service providing server 2702-1 transmits a user addition request associated with sysID 1 (1) to C (1) (step 2802).
  • C (1) generates a unique mID (mID 1 (1) ) and information about sysID 1 (1) and the account (U's account) (for example, account creation date and time, invariant information about the account)
  • an electronic signature Sign (information stored in the list held by C (1) )
  • C (1) generates a key and encrypts Pass using the key.
  • the encrypted Pass is called E (Pass).
  • C (1) encrypts Pass once, and it is C (1) itself that decrypts Pass, and Pass itself is not so large.
  • the key may be a Vernam cipher as a disposable key.
  • C (1) sets the value of ust (U state) to “halfway” (registering) for the account.
  • ust (state of U) may be included in OTHERS of aList (1) , for example.
  • C (1) holds mID, key, and ust in association with sn, for example, in aList (1) .
  • C (1) sends sn, mID, and E (Pass) to the service providing server 2702-1 (step 2803).
  • the service providing server 2702-1 is the ulist 1 (1), to register the uID 1 (1) and mID, the value of sst (authentication shutter state) and "closed” (a value meaning the closed state), The value of period (the time when the authentication shutter is in the closed state) is “Undefined”. The sst and period are included in at least one of TPWINFO and OTHERS of uList 1 (1) . Then, the service providing server 2702-1 sends sn and E a (Pass) in U P (step 2804).
  • U P received sn and E (Pass) is the U, is input to the U M.
  • the input to U M information U P is received, to two-dimensional bar code or the like may be used, the input of the manual may be utilized.
  • Sn and E (Pass) is input, for example, APP of U M.
  • the U, the U M, the authentication shutter control password (reqPw) is input.
  • C control center
  • tReqPw reqPw.
  • U M transmits sn, ReqPw and E a (Pass) in C (1) (step 2811).
  • C (1) specifies an account from sn, and only when “ust” registered as the account information is “halfway”, decrypts E (Pass) using the key of the account and obtains Pass. After that, C (1) verifies the validity of the Pass.
  • hreqPw is set to “h (reqPw)” (value obtained by performing irreversible transformation processing on reqPw), and the value of ust is set. “Active” (value indicating registered) is set (step 2812).
  • hreqPw may also be included in OTHERS of aList (1) , for example. If ust is already “active” or if Pass is not correct, C (1) may stop the procedure at that point as a registration failure.
  • C (1) transmits the Pass to U M (Step 2813).
  • U M is the Pass received, U M-specific information (eg, MAC address, UUID, etc.) to store on encrypted as a key (step 2814).
  • U M-specific information eg, MAC address, UUID, etc.
  • U M using the U M-specific information, decodes the information that has been encrypted, such Pass.
  • U M is (system ID of the service system for operating the authentication shutter (S 1 (1))) sysID 1 (1), the operation content (open or close (O / C)) and received from the U input ReqPw, The information and Pass are transmitted to C (1) (step 2821).
  • C (1) identifies the account from the mID included in the Pass, and verifies the correctness of the Pass and reqPw. If it is correct, C (1) transmits mID and the operation content (O / C) to the shutter management server 2701-1 (step 2822).
  • the shutter management server 2701-1 determines the time t at which the authentication shutter is closed, and sets the value of the period (period specified with mID as a key) corresponding to U to “t”. Since the timing for opening the authentication shutter is considered to be when U intends to use S 1 (1) from now on, “t” may be a time several minutes after the operation content is received. If the operation content is close, the shutter management server 2701-1 sets the value of the period corresponding to U to “Undefined”.
  • the shutter management server 2701-1 updates the sst and period corresponding to U, and returns the period to C (1) (step 2823).
  • C (1) transmits the period to U M (step 2824).
  • U P transmits uID 1 (1) and pw to service providing server 2702-1 (step 2901).
  • pw may be a fixed password or TempPw.
  • the service providing server 2702-1 transmits an inquiry (inquiry of the authentication shutter state for U ) associated with uID 1 (1 ) to the shutter management server 2701-1 (step 2902).
  • the shutter management server 2701-1 identifies sst and period using uID 1 (1) as a key. If the time has not passed the period, the shutter management server 2701-1 returns the value of sst (“open” or “closed”) to the service providing server 2702-1 (step 2903). If the time has passed the period, the shutter management server 2701-1 returns “closed” to the service providing server 2702-1 as the value of sst. If uID 1 (1) does not exist or if the value of period is “Undefined”, the shutter management server 2701-1 sets “closed” as the value of sst as the service providing server 2702-1. Return to.
  • the service providing server 2702-1 queries the authentication server 2703-1 for (uID 1 (1) , pw) (step 2904).
  • the service providing server 2702-1 may terminate the procedure as login authentication failure.
  • the authentication server 2703-1 returns Yes or No to the service providing server 2702-1 in accordance with (uID 1 (1) , pw) (step 2905).
  • the service providing server 2702-1 only when Yes is returned, (for example, login authentication succeeds) to provide services to U P.
  • Figure 30 shows an example of screen transition in U M or U P.
  • Reference numeral 3000-1 is an example of a screen transition in a case where the tpw usable period is short and the usable number of times is fixed. In this case, as described above, a general otp can be used. For this reason, for example, if U inputs tReqPw (1) (exactly reqPw (1) ) and the desired service system (service A) on the screen of U M , C (1) gives service A An OTP “1234” that can only be used is issued, and the OTP is displayed in U M.
  • Reference numeral 3000-2 is an example of a screen transition in a case where the tpw usable period is long and the usable number is unlimited. In this case, as described above, a common tpw is used, but reference numeral 3000-2 shows an example in which a different password is issued for each service.
  • U is on the screen of the U M, by entering the TReqPw (1) and the desired one or more of the service system (service A and service C), the C (1), respectively corresponding to the service A and the service C Passwords “1234” and “5678” are issued, and those passwords are displayed in U M.
  • Reference numeral 3000-3 is an example of a screen transition in a case where the tpw usable period is long and the usable number is unlimited.
  • pw is used as described above. For example, if U inputs one or more desired service systems (service A and service C) that share tReqPw (1) and tpw on the screen of U M , service A and service C will be executed according to C (1). Common tpw “1234” is issued, and the tpw is displayed in U M. At this time, as shown in the figure, the expiration date indicated by the period included in tpwInfo associated with tpw and the uID included in the tpwInfo (uID for each service system selected by U) may be displayed.
  • Reference numeral 3000-4 is an example of screen transition in the case of opening / closing the authentication shutter.
  • U is on the screen of the U M
  • the input operation contents e.g. Close
  • the desired one or more of the service system service A and service C
  • the C (1) each of the service A and the service C state of the authentication shutter (sst) is in the state of the operation content as the U, and the result is displayed on the U M.
  • tpwInfo including the uID for each service system selected by the user in addition to the period is sent to the U M, and the uID included in the tpwInfo (the uID for each service system selected by the U) is also May be displayed.
  • Reference numeral 3000-5 is an example of authentication / cooperation screen transition.
  • U is on the screen of the U M
  • collaboration source service system (the From) (e.g. Figure 25 of the S 2 (1))
  • the cooperation destination service system (the To) (e.g. FIG. 25 ( S 1 (1) )
  • cooperation target information (for example, “X certificate”)
  • the “X certificate” is also information to be linked, and is also an att value in information linkage. That is, in the example of this figure, the cooperation target information is one att value.
  • a desired att may be designated by U, and it may be checked whether the att can be provided or accepted.
  • U M (APP) displays uID, at least a part of cooperation target information, and an answer button (OK button and NG button).
  • the key may also be displayed by U M (APP). If the OK button is pressed, U, using the U P, may access the collaboration destination service system.
  • biometric authentication U M e.g., fingerprint authentication or an iris authentication
  • biometric information of U e.g., fingerprint information, or Iris information
  • U biometric information may be used instead of or in addition to reqPw.
  • Biometric information utilized may be a information detected by the U M, may be information which is previously registered in the U M.
  • TpwInfo i (j) is an electronic identification object that is displayed on the screen that S i (j) provides to U (for example, an application reception screen such as a login screen, an input reception screen such as a bank account number). (Eg, text or images).
  • the identification object in tpwInfo i (j) may be displayed on the display 211 by U M (APP).
  • U enters the identification object on the screen and the identification code (tpwInfo i (j ) displayed on display 211 by U M (APP) before inputting information on the screen provided by S i (j). ) (Identification object in parenthesis ) . If they match, it can be seen that the screen provided to U is certainly the screen provided from S i (j) . As a result, it is possible to avoid U from providing information to an unauthorized system (for example, suitable for phishing damage).
  • sysID i (j) associated with tpw control request such as tpw issue request is registered in pList instead of sysID i (j) of the service system manually selected by U, and U M (APP) All (or part) of sysID i (j) automatically selected by
  • At least one of the tpw restrictions may be determined by a control center that issues tpw instead of the service system.
  • the expiration date of tpw is as follows. That is, the expiration date of tpw is determined by the control center, and the expiration date determined by the control center is transmitted to the service system via another control center or not.
  • C (1) determines the expiration date of tpw for each sysID i (j) in SYSIDPart (for example, in any one of steps 1402 to 1404).
  • S i (j) registers the received tpw expiration date (Period i (j) ) in uList i (j) as at least part of tpwInfo i (j) (eg, step 1405).
  • the above processing may be applied to restrictions other than the expiration date of tpw (for example, the number of times of use).
  • At least one of the tpw restrictions may be determined by the user instead of the service system.
  • the expiration date of tpw is input to U M (APP) by U, sent from U M (APP) to the control center, and sent from the control center to the service system via another control center or not.
  • U M (APP) receives an input of a tpw expiration date (Period i (j) ) from U for each sysID i (j) in SYSIDPart (for example, step 1401).
  • the expiration date may be the same for all sysID i (j) in SYSIDPart, or may differ for each sysID i (j) in SYSIDPart.
  • the tpw expiration date (Period i (j) ) of each sysID i (j) in SYSIDPart is transmitted from U M (APP) to C (1) (for example, step 1401). Then, for example, the tpw expiration date (Period 1 (1) ) corresponding to S 1 (1) under C (1) that received the tpw expiration date from U M is from C (1) to S 1 (1 ) .
  • C (1) tpw expiration date corresponding to the S 1 (2) located under the separate control center, C (2) and the (Period 1 (2)) is, C (2 from C (1) ) Is sent to S 1 (2 ) via or not.
  • S i (j) registers the received tpw expiration date (Period i (j) ) in uList i (j) as at least part of tpwInfo i (j) (eg, step 1405).
  • the above processing may be applied to restrictions other than the expiration date of tpw (for example, the number of times of use).
  • C (j), S i (j), at least some of the processes described above performed by each of the U P and U M, as described above, is performed by a computer program processor executes.
  • the “server” described above may be a physical server machine instead of a function (for example, a virtual server) executed in a computer system.
  • C (j) and S i (j) are typically owned or managed by different persons (entities), but may be owned or managed by the same person.
  • the exchange between U and S i (j) is not limited to the web base, and may be performed on a paper basis.
  • a record (account) is added to the table, and U M to C (j) Information is registered in the record by a table operation in processing performed in response to the request.
  • a key for integrating a plurality of service systems such as aID (j) may be held in at least one of U M and C (j) .
  • aID (j) is not essential.
  • mID i (j) Since different in different S i (j) is U be the same, mID i (j) may be used as aID (j).
  • the number of S i (j) where U is utilized often it is possible to associate the same aID (j) into two or more S i where U is utilized (j), the presence of aID (j) Efficiency can be expected.
  • tpwInfo i (j) received by U M is sent to the service system for each service system (for example, for each service system to which tpw is issued or for each cooperation destination service system of cooperation target information).
  • Link for example, URL
  • U M (or U P ) may access the service system by specifying a link in tpwInfo i (j) .
  • the link (URL) included in tpwInfo i (j) may include information for identifying the user.
  • a service system accessed from U M (or U P ) by specifying the link provides a screen with information (for example, uID and authentication information) entered in the input field to the access source U M (or U P ). You can do it.
  • a request (for example, a login request) transmitted from U P (or U M ) to S i (j) includes its S i (j ) May be a unique password.
  • the electronic signature is not essential.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
PCT/JP2015/082991 2014-11-27 2015-11-25 複数のサービスシステムを制御するサーバシステム及び方法 Ceased WO2016084822A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/531,003 US20180052987A1 (en) 2014-11-27 2015-11-25 Server system and method for controlling multiple service systems
JP2016561901A JP6199506B2 (ja) 2014-11-27 2015-11-25 複数のサービスシステムを制御するサーバシステム及び方法

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP2014240462 2014-11-27
JP2014-240462 2014-11-27
JP2015-006662 2015-01-16
JP2015006662 2015-01-16
JP2015033330 2015-02-23
JP2015-033330 2015-02-23
JP2015187644 2015-09-25
JP2015-187644 2015-09-25

Publications (1)

Publication Number Publication Date
WO2016084822A1 true WO2016084822A1 (ja) 2016-06-02

Family

ID=56074374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/082991 Ceased WO2016084822A1 (ja) 2014-11-27 2015-11-25 複数のサービスシステムを制御するサーバシステム及び方法

Country Status (3)

Country Link
US (1) US20180052987A1 (enExample)
JP (2) JP6199506B2 (enExample)
WO (1) WO2016084822A1 (enExample)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11252250B1 (en) * 2017-09-22 2022-02-15 Amdocs Development Limited System, method, and computer program for managing a plurality of heterogeneous services and/or a plurality of heterogeneous devices linked to at least one customer
US10136320B1 (en) * 2017-11-22 2018-11-20 International Business Machines Corporation Authentication of users at multiple terminals
JP7716216B2 (ja) 2021-04-05 2025-07-31 キヤノン株式会社 情報処理システム及び方法
CN119095056A (zh) * 2023-06-05 2024-12-06 华为技术有限公司 通信方法和通信装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08221364A (ja) * 1995-02-15 1996-08-30 Hitachi Ltd ユーザ登録簿の分散管理方法
JP2002236663A (ja) * 2001-02-07 2002-08-23 Ntt Docomo Inc 情報管理システム、端末、通信装置、通信方法、プログラムおよび記録媒体
US20030149781A1 (en) * 2001-12-04 2003-08-07 Peter Yared Distributed network identity
JP2004070814A (ja) * 2002-08-08 2004-03-04 Nec Corp サーバセキュリティ管理方法及び装置並びにプログラム
JP5380583B1 (ja) * 2012-06-25 2014-01-08 国立大学法人 千葉大学 デバイス認証方法及びシステム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623600A (en) * 1995-09-26 1997-04-22 Trend Micro, Incorporated Virus detection and removal apparatus for computer networks
JP5117177B2 (ja) * 2007-12-13 2013-01-09 日本電信電話株式会社 属性情報流通制御システムおよび属性情報流通制御方法
JP4764451B2 (ja) * 2008-01-25 2011-09-07 日本電信電話株式会社 属性情報開示システム、属性情報開示方法および属性情報開示処理プログラム
JP5076955B2 (ja) * 2008-02-20 2012-11-21 日本電気株式会社 通信システム、通信装置、通信方法
WO2011129380A1 (ja) * 2010-04-13 2011-10-20 日本電気株式会社 属性情報仲介システム、仲介装置、属性情報仲介方法および属性情報仲介プログラム
JP5439443B2 (ja) * 2011-07-26 2014-03-12 日本電信電話株式会社 情報管理システムとそのデータ連携操作方法、プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08221364A (ja) * 1995-02-15 1996-08-30 Hitachi Ltd ユーザ登録簿の分散管理方法
JP2002236663A (ja) * 2001-02-07 2002-08-23 Ntt Docomo Inc 情報管理システム、端末、通信装置、通信方法、プログラムおよび記録媒体
US20030149781A1 (en) * 2001-12-04 2003-08-07 Peter Yared Distributed network identity
JP2004070814A (ja) * 2002-08-08 2004-03-04 Nec Corp サーバセキュリティ管理方法及び装置並びにプログラム
JP5380583B1 (ja) * 2012-06-25 2014-01-08 国立大学法人 千葉大学 デバイス認証方法及びシステム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MASATAKA KAKINOUCHI ET AL.: "Privacy o Koryo shita One-time Password Ninsho System no Jisso", 2012 NEN SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY KOEN RONBUNSHU, 30 January 2012 (2012-01-30), pages 1 - 6 *
NORIHO SASAKI ET AL.: "Hakko Center o Kaishita One-time Password Ninsho System no Anzensei ni Kansuru Kosatsu", 2014 NEN SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY KOEN RONBUNSHU, 21 January 2014 (2014-01-21), pages 1 - 6 *
TETSUJI TAKADA: "Authentication Shutter: an Alternative Measure against Mass Attack with Leaked Account List", COMPUTER SECURITY SYMPOSIUM 2014 RONBUNSHU, 15 October 2014 (2014-10-15), pages 883 - 890 *

Also Published As

Publication number Publication date
US20180052987A1 (en) 2018-02-22
JP2018022501A (ja) 2018-02-08
JPWO2016084822A1 (ja) 2017-04-27
JP6712707B2 (ja) 2020-06-24
JP6199506B2 (ja) 2017-09-20

Similar Documents

Publication Publication Date Title
US20230245019A1 (en) Use of identity and access management for service provisioning
US11700117B2 (en) System for credential storage and verification
US11770261B2 (en) Digital credentials for user device authentication
US11641278B2 (en) Digital credential authentication
US11792181B2 (en) Digital credentials as guest check-in for physical building access
US11716320B2 (en) Digital credentials for primary factor authentication
US11698979B2 (en) Digital credentials for access to sensitive data
US11627000B2 (en) Digital credentials for employee badging
US10829088B2 (en) Identity management for implementing vehicle access and operation management
US11531783B2 (en) Digital credentials for step-up authentication
US11792180B2 (en) Digital credentials for visitor network access
US11683177B2 (en) Digital credentials for location aware check in
US12093403B2 (en) Systems and methods of access validation using distributed ledger identity management
US8499147B2 (en) Account management system, root-account management apparatus, derived-account management apparatus, and program
WO2018048692A1 (en) Architecture for access management
US11522713B2 (en) Digital credentials for secondary factor authentication
KR20160085143A (ko) 익명 서비스 제공 방법 및 사용자 정보 관리 방법 및 이를 위한 시스템
JP6712707B2 (ja) 複数のサービスシステムを制御するサーバシステム及び方法
WO2019234801A1 (ja) サービス提供システム及びサービス提供方法
WO2018207174A1 (en) Method and system for sharing a network enabled entity
JP2004213265A (ja) 電子文書管理装置、文書作成者装置、文書閲覧者装置、電子文書管理方法及び電子文書管理システム
US12450368B2 (en) Systems and methods of access validation using distributed ledger identity management
KR102053993B1 (ko) 인증서를 이용한 사용자 인증 방법
JP2017146596A (ja) 機器内の情報を移行するシステム及び方法
KR20170096691A (ko) 자체확장인증을 이용한 키관리 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15863388

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016561901

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15531003

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 15863388

Country of ref document: EP

Kind code of ref document: A1