Patent Application
20100250955
The subject invention relates to sharing of information over a network such as the Internet.
The Internet has become a ubiquitous means for access and exchange of digital information. It is comprised of computers and computer networks interconnected through communication links and exchanging information via protocols such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), Simple Mail Transport Protocol (“SMTP”), HyperText Transfer Protocol (“HTTP”), Extensible Messaging and Presence Protocol (“XMPP”), and Session Initiation Protocol (“SIP”).
These and other protocols, both standardized and proprietary, enable the devices connected to the Internet to intercommunicate to share many different types of information for many different purposes. Three of the most popular applications for communications and data sharing are email, web browsing, and Voice-Over-IP (VOIP).
As the utility of these and other Internet applications has grown, so has the need to use them for sharing private data—data to which access must be controlled in order to ensure privacy, security, and confidentiality. An early example was the need to protect credit card information required to complete transactions on e-commerce sites. In order for consumers to trust sharing entering this information into a web browser and sending it over the Internet, the industry needed to develop a secure version of HTTP called HTTPS. This uses a protocol originally called Secure Sockets Layer (SSL) and now known as Transport Layer Security (TLS). TLS secures data transmissions using digital cryptography as specified in the Internet Engineering Task Force (IETF) Request For Comment (RFC) 4346 “The Transport Layer Security (TLS) Protocol Version 1.1” (http://tools.ietf.org/html/rfc4346), hereby incorporated by reference herein.
Users of a web browser can recognize when TLS security is being employed by looking for a small lock icon (typically in a corner of the browser), or a special background coloring of their browser address bar (where the web site address appears), or other visual or auditory cues. This increases the confidence of users and sites that the information entered into a web form will be transmitted securely between the browser and the site.
Although TLS and other transport security protocols can ensure the security and confidentiality of data transmitted over the transport channel, they do not by themselves solve the problem of authenticating the identity of either the user or the site involved in the data sharing transaction. Users still need to submit security credentials to sites to prove their identity to sites, and sites need to obtain trusted digital certificates from certificate authorities in order to prove their identity to users or other sites.
The most commonly employed user credential is a username and password, typically submitted by typing into a web form. Unfortunately this type of credential is susceptible to a “phishing” attack in which the identity of the site is faked by an attacker, fooling the user into entering their username and password into the attacker's web form. Such attacks are described in detail in “Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities” by Vittorio Bertocci, Garrett Serack, and Caleb Baker (ISBN 0-321-49684-1, Pearson Technologies Inc., 2008), hereby incorporated by reference herein.
The above book also describes the solution originally developed by Microsoft referred to as information cards and identity selectors. Broadly speaking, this is a system to simplify, automate, and very significantly increase the security of the process of users submitting digital identity credentials to websites, web services, and other resources both on the Internet and enterprise networks by using a standard credential format called an information card or “i-card” and standard software program and interface for selecting and managing i-cards called an identity selector or just “selector”. Information cards and identity selectors are described in detail in the book “Understanding Windows CardSpace”, which also contains references to the current information card interaction and transaction specifications published by OASIS IMI Technical Committee (http://www.oasis-open.org/committees/imi) and referred to herein as the “IMI” specifications”.
This information card architecture has been further extended by the Higgins Project, an open source project of the Eclipse Foundation (http://www.eclipse.org/higgins/). The Higgins Project uses the shorter term “i-card” to refer to all types of information cards, including new types not defined by Microsoft's IMI specification.
Whether data is transmitted to a site via TLS or other transport security protocols, and whether it is delivered via an information card security token, once the data is received the receiving site has the keys to decrypt the data. Further security and confidentiality are its responsibility. This may be adequate if the site is the final consumer of the data, or if it is trusted by the user to relay the data securely and confidentially to other third parties selected and controlled by the site. However users may wish to use a new intermediary service that manages the distribution and sharing of the data from parties that the user selects to parties that the user selects.
Furthermore, the IMI specifications were designed under the general assumption that the user's “wallet” of i-cards, often called the cardstore, is stored locally on the same device hosting the identity selector. However some of the identity selectors under development in the Higgins Project do not make that assumption—they are designed with the assumption that the cardstore is either only “in the cloud” or is synchronized between a local store and the cloud, i.e, available as a service over the Internet, an approach referred to in the industry as “cloud computing” and “software as a service” (SaaS).
To support a cloud-based digital identity approach, also called “identity-as-a-service”, however, the user of the service, referred to as the principal, must be able to provision a selector and a wallet service provider, and this provisioning must meet special security and privacy protection requirements. Furthermore, a cloud-based identity service provider, referred to as a broker, must be able to support the principal's requirements for convenience, ease-of-use, and performance, all while protecting the principal's security and privacy at the same level expected of commercial banks, government agencies, or other highly trusted service providers.
Therefore there exists a need for a method and system that enables a principal to create and control information sharing relationships over a network.
It is therefore an object of at least one embodiment of the subject invention to provide a system for and method of enabling a principal to create and control an information sharing relationship over a network.
It is a further object of at least one embodiment of the subject invention to provide such a system and method wherein the principal can more easily and safely share information.
It is a further object of at least one embodiment of the subject invention to provide such a system and method whereby the principal can control which parties on the network have access to the principal's information.
It is a further object of at least one embodiment of the subject invention to provide such a system and method wherein the principal's control over the principal's information is not tied to any specific device.
It is a further object of at least one embodiment of the subject invention to provide such a system and method whereby the principal is able to maintain service even if a password or other authentication credentials are lost.
It is a further object of at least one embodiment of the subject invention to provide such a system and method which maintains service to the principal even if the principal's devices and/or access software is lost or becomes nonfunctional.
It is a further object of at least one embodiment of the subject invention to provide such a system and method which maintains the security of the principal's information.
It is a further object of at least one embodiment of the subject invention to provide such a system and method which maintains the principal's privacy.
It is a further object of at least one embodiment of the subject invention to provide such a system and method which requires the principal to provide authorization only once for using one or more cards.
Embodiments of the invention result from the realization that it is more convenient for a principal that uses one or more cards to provide authentication only once to a broker and have the broker assert the principal's authentication to one or more issuing parties rather than having the principal provide authorization numerous times.
The subject invention, however, in other embodiments, need not achieve all these objectives and the claims hereof should not be limited to structures or methods capable of achieving these objectives.
This invention features a brokered information sharing system comprising a primary broker configured with software to store cards of a principal, to transmit said cards when requested by the principal, to authenticate the principal, and to provide a master authentication of the principal to at least one issuing party, and a selector used by the principal and configured with software to provide authentication of the principal to the primary broker, and to request and receive cards from the primary broker.
In one embodiment, the master authentication may be for authenticating a plurality of the cards each selected by the selector. The selector may be programmed to analyze a security policy provided by an information source and the selector includes a communications module configured to compose a message transmitted to the remote broker. The message may include a broker password which allows access to the primary broker. The primary broker may include programming for verifying the broker password. The primary broker may include one or more databases for storing the cards and a data adapter which queries the databases in accordance with the message. The primary broker may be further configured to authenticate a card transmitted to the selector upon request by the selector. The selector may be programmed to request a card authenticated from the primary broker. The selector may include a cryptography module which produces a security token based on the card authentication transmitted from the primary broker. The authentication may include a selector identification and a password. At least some of the information in the cards may be stored at the primary broker may be encrypted. At least one encryption key for the cards and an encryption key repository may be remote from the broker for storing the at least one encryption key. The selector may be programmed to retrieve the encryption key from the encryption key repository for decrypting an encrypted card transmitted to the selector by the broker. The software of the primary broker may be configured to store the cards remotely from the selector. The primary broker may use one or more devices or methods for authenticating the principal. The primary broker may authenticate the principal using device fingerprinting. The primary broker may authenticate the principal using a trusted platform module. The primary broker may authenticate the principal using IP address authentication. The primary broker may authenticate the principal using knowledge based authentication. The primary broker may authenticate the principal using a broker-issued one-time password. The primary broker may authenticate the principal using a hardware authentication token mechanism. The primary broker may authenticate the principal using a software authentication token mechanism. The primary broker may authenticate the principal using broker heuristics. The broker heuristics may use information relating to the enrollment of the principal in a card wallet service. The broker heuristics may use information relating to the characteristics of a card wallet of the principal. The broker heuristics may use information relating to the cards in a card wallet of the principal. The broker heuristics may use information relating to the characteristics of a group of cards from a card wallet of the principal.
This invention also features a brokered information sharing system for a principal using a selector, the system comprising a primary broker configured with software to remotely store cards of a principal, to transmit said cards when requested by the principal, and to authenticate the principal upon request by the selector, and to provide a master authentication of the principal to at least one issuing party. The selector is used by the principal and configured with software to request cards from the broker, to receive cards transmitted from the broker, and to request card authentication from the broker.
This invention further features a brokered information sharing system comprising a primary broker remote from a principal which includes a database for storing cards of a principal, the cards having at least some information therein encrypted, a data adapter configured to query the database in response to a message, means for authenticating a retrieved card, and means for transmitting the card and the authentication. A selector includes a communications module configured to compose the message based on a security policy and to transmit the message to the primary broker, and a cryptography module configured to provide a security token based on the authentication received from the primary broker. An encryption key repository is configured to store at least one encryption key of the principal and to transmit the encryption key to the selector upon request by the selector to decrypt the encrypted information in a card transmitted to the selector by the primary broker.
In another embodiment, the message may include a broker password which allows access to the primary broker. The primary broker may include programming for verifying the broker password. The authentication may include a selector identification and a password.
This invention further features a brokered information sharing system comprising a primary broker comprising means for storing cards of a principal, means for transmitting a said card when requested by the principal, means for authenticating the principal, and means for providing a master authentication of the principal to at least one issuing party, and a selector used by the principal and including means for requesting cards from the remote broker and to receive cards transmitted from the broker.
This invention further features a brokered information sharing method comprising configuring a primary broker to remotely store cards of a principal and to transmit cards when requested by the principal, to authenticate the principal, and to provide a master authentication of the principal to at least one issuing party, and to configure a selector for use by the principal to request cards from the remote broker and to receive cards transmitted from the broker.
In another embodiment, the selector may analyze a security policy provided by an information source and compose a message transmitted to the remote broker. The message may include a broker password which allows access to the primary broker. The primary broker may verify the broker password. The primary broker may include one or more databases for storing the cards and the broker queries the databases in accordance with the message. The primary broker may authenticate a card transmitted to the selector upon request by the selector. The selector may request a card authenticated from the primary broker. The selector may produce a security token based on the card authorization transmitted from the primary broker. The authentication may include a selector identification and a password. The cards stored at the primary broker may be encrypted. At least one encryption key for the cards may be stored at an encryption key repository remote from the broker. The selector may retrieve the encryption key from the encryption key repository for decrypting an encrypted card transmitted to the selector by the broker.
This invention further features a brokered information sharing method comprising configuring a primary broker with software to store cards of a principal, to transmit said cards when requested by the principal, and to authenticate the principal upon request by the selector, and to provide a master authentication of the principal to at least one issuing party, and configuring a selector used by the principal with software to request cards from the remote broker, to receive cards transmitted from the broker, and to request card authentication from the primary broker.
This invention further features a brokered information sharing method comprising provisioning a primary broker remote from a principal to: store encrypted cards of a principal in a database, query the database in response to a message, authenticate a retrieved card, and transmit the card and the authentication. A selector is provisioned to: compose the message based on a security policy and to transmit the get card message to the primary broker, and provide a security token based on the authentication received from the primary broker. A repository is provisioned to store at least one encryption key of the principal and transmit the encryption key to the selector upon request by the selector to decrypt a card transmitted to the selector by the primary broker.
In another embodiment, the message may include a broker password which allows access to the primary broker. The primary broker may verify the broker password. The authentication may include a selector identification and a password. This invention further features a brokered information sharing method comprising storing cards of a principal and transmitting a said card when requested by the principal, requesting cards from the broker and receiving cards transmitted from the broker; authenticating the principal, and providing a master authentication of the principal.
Other objects, features and advantages will occur to those skilled in the art from the following description of a preferred embodiment and the accompanying drawings, in which:
Aside from the preferred embodiment or embodiments disclosed below, this invention is capable of other embodiments and of being practiced or being carried out in various ways. Thus, it is to be understood that the invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. If only one embodiment is described herein, the claims hereof are not to be limited to that embodiment. Moreover, the claims hereof are not to be read restrictively unless there is clear and convincing evidence manifesting a certain exclusion, restriction, or disclaimer.
The present invention provides a method and system for brokered information sharing between parties on a network such as the Internet. Representations of such parties on a network are commonly referred to as digital identities. The party represented by a digital identity may be an individual, an organization of any kind, a computing device of any kind, a software program or service of any kind, or any other type of entity requiring identification on a network.
In the example embodiments disclosed herein, the first party to an information sharing relationship is referred to as the principal. The second party to the relationship is referred to as either: a) the issuing party, if they are sending or publishing information that will be shared with the principal or by other relying parties selected by the principal, or b) the relying party, if they are receiving or subscribing to information published by an issuing party. An issuing party is also referred to as an “IP”, also known in the industry as an “identity provider” or “claims authority”. A relying party is also referred to as an “RP”. In addition, a party who serves to facilitate information sharing relationships between any combination of principals, issuing parties, and relying parties, but which is itself not a direct party to the information sharing relationship, is referred to as a broker.
It is an object of this invention that any party on the network operating from any device on the network may perform any or all of these roles. Apart from the technical constraints or bandwidth limitations associated with operation of a client-only device, the only limitations on a party being able to concurrently perform multiple roles are legal, business, or social constraints. Specifically, the same party that serves as a principal in some information sharing relationships may serve as the issuing party in other relationships and the relying party in still other relationships. Although brokers are not a direct party to the information sharing relationships they facilitate, a broker may separately act as a principal, issuing party, or relying party on its own behalf. In some cases information issued or received by the broker in its role as an issuing party or relying party may separately be used by the broker in its role as a broker.
Information which asserts the attributes of a digital identity, including its relationships with other digital identities, is referred to as claims. Claims have many uses but may specifically be used for authentication and authorization in a digital identity system. A group of one or more claims together with metadata describing this set of claims is referred to herein as a card. The term “card”, also referred to in the industry as “information card”, “infocard”, or “i-card”, derives both from the grouping of claims into a set and from the ability for a user interface to present this set to the principal (or other parties) using the metaphor of a physical card such as a library card, business card, driver's license card, credit card, etc. However this metaphor does not limit the actual data structure; a card may be any structured digital object capable of transferring claims, claims metadata, and other associated information between two or more parties on a network. Cards, claims, claims authorities, claims transformers, and related art are described generally in: “Personal Identification Information Schemas”, U.S. Patent Application Publication US 2007/0204325 A1, Kim Cameron and Arun Nanda, Aug. 30, 2007, incorporated by reference herein.
In a system using digital identities and cards, three types of claims play special roles: identifiers, credentials, and encryption keys.
Identifiers are used to identify different parties on the network with different properties of identification. For example, identifiers can be absolute (context-independent) or relative (context-dependent). They can be omnidirectional (publicly dereferenceable) or unidirectional (only dereferenceable in the context of a specific relationship). They can be single-part values, hierarchical segments, or multipart aggregated values. The may appear in their native form, or be hashed or encrypted. From a privacy perspective, they can be anonymous (not correlatable at all with any other identity of the principal), pseudonymous (correlatable across a limited set of other identities of the principal), or veronymous (correlatable with the principal's real-world identity). In a brokered information sharing system 100, unidirectional pseudonyms play a special role in privacy protection as further described herein.
In a wide-area network such as the Internet, the most common identifiers are IP addresses and DNS names. The World Wide Web and IETF Uniform Resource Identifier (URI) and Internationalized Resource Identifier (IRI) standards (RFC 3986 and RFC 3987 respectively) enable these network identifiers to be combined with local resource identifiers (such as filenames) to create hierarchical global identifiers. This architecture has been extended by the OASIS Extensible Resource Identifier (XRI) Technical Committee standards including “OASIS XRI Syntax 2.0”, D. Reed and D. McAlpin, Editors, http://docs.oasis-open.org/xri/xri-syntax/2.0/specs/cs01/xri-syntax-V2.0-cs.pdf, December 2005, and “OASIS XRI Resolution 2.0”, G. Wachob et al, Editors, http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.pdf, April, 2008. Global XRI registry infrastructure has been implemented by XDI.org (http://www.xdi.org) as specified in “XDI.org Global Services Specifications Version 1.0” published by XDI.org at http://gss.xdi.org.
XRIs enable expression of abstract identifiers than can be composed of other XRIs as well as URIs or IRIs. XRIs are well-suited to cross-domain information sharing because they are designed to be domain- and application-independent; they support mapping of human-friendly, reassignable identifiers (referred to as i-names) to persistent, machine-friendly identifiers (referred to as i-numbers); they provide a uniform protocol for resolution of an i-name or i-number to discovery of concrete service endpoint identifiers; and this protocol includes three trusted resolution modes for security protection (HTTPS, SAML, and HTTPS+SAML). XRI identifiers in the example embodiments disclosed in this specification use the simplified XRI syntax published in Appendix B of “The XDI RDF Model” published by the OASIS XRI Data Interchange (XDI) Technical Committee ((http://www.oasis-open.org/committees/xdi) at the permanent link http://www.oasis-open.org/committees/download.php/30955/xdi-rdf-model-v12.pdf. In this specification, identifier resolution requests that use one of the three XRI trusted resolution modes will be referred to as “XRI trusted resolution”. XRI resolution specifies an XML-based discovery document format called XRDS documents. Filtering and selection of XRDS documents for service endpoints as specified in “OASIS XRI Resolution 2.0” will be referred to herein as “service endpoint selection”.
Credentials are the claims associated with a digital identity used to authenticate the principal on the network. One of the simplest forms of credential is a password, which is typically paired with a username as an identifier for the principal. Though weak, username/password credentials are currently the most widely deployed form of authentication used on the Internet. Stronger types of credentials include one-time passwords, hardware security tokens, biometrics, and digital certificates. Even claims like legal names, postal addresses, phone numbers, SMS addresses, and email addresses can be considered a form of credential, especially with regard to password or account recovery purposes, because principals may have one or more mechanisms by which they can prove possession or control over these claims. Credentials and authentication are discussed generally in “Authentication: From Passwords to Public Keys”, by Richard E. Smith, Addison-Wesley Professional, October 2001, ISBN 978-0201615999. Encryption keys, referred to herein as “keys”, are claims associated with a digital identity that are used to encrypt and decrypt shared information. Keys may be either symmetric, where both parties to an information sharing relationship confidentially share the same key, or asymmetric, in which the combination of a public key and a private key are used together to encrypt and decrypt shared information as necessary to ensure integrity, confidentiality, authenticity, and non-repudiation. Asymmetric keys may also be shared using digital certificates of various kinds. Digital cryptography, certificates, and hashes are described generally in “Applied Cryptography, Second Edition”, by Bruce Schneier, John Wiley & Sons, 1996, ISBN 0-471-11709-9, incorporated by reference herein.
Principals which are themselves software programs are referred to as agents. Principals which are not themselves software programs, such as individuals or organizations, must use agents operating on hardware devices connected to the network to control their digital identities and information sharing relationships. In the example embodiments disclosed herein, the agents used for this purpose are referred to as selectors.
Principal 101 communicates and interacts with the other components using selectors 200 operating on devices such as laptop computer 201, smart phone 202, and smart fax machine 203. It is an object of the present invention that a principal is not limited to using a single selector operating on a single device, but may use any number of selectors operating on any number of devices, all of which may provide access to and control of the principal's account(s) in brokered information sharing system 100.
The role of a selector is to serve as the client-side trusted agent a principal can use to select cards and control information sharing relationships. Although it may run on a server, selector 200 is typically a client software program running on a local device that communicates with servers operating online over Internet 150 or other communications networks. Selector 200 may also store a set of provisioning information, including identifiers, credentials, keys, and service endpoints, for controlling access to brokered information sharing system 100 and authenticating to brokers 300.
Information sharing relationships between principal 101 and parties 400 are facilitated by brokers 300. The role of brokers in brokered information sharing system 100 is similar to the role of bankers in a banking system. Their purpose is to serve as the server-side trusted agent of principals in information sharing transactions the same way banks serve as the trusted agent of individuals or organizations in monetary transactions. Brokers can provide data sharing messaging services that operate full time on the principal's behalf, i.e., even when client devices used by the principal are offline. Brokers may also offer data storage, search, backup, and other services that may not be available or feasible on a principal's client-side devices.
In brokered information sharing system 100, the broker with whom the principal forms their primary authentication relationship is referred to as the primary broker, shown as 301 in
One specific set of services secondary broker 302 may offer is registration, discovery, and authentication of other identifiers for a principal. The use of such identifiers may be integrated with the functions of a brokered information sharing system 100, or they may be used independently of it. One such service is OpenID authentication service as defined by the OpenID Authentication 2.0 specifications published by the OpenID Foundation at http://openid.net/specs/openid-authentication-2—0.html. A secondary broker who offers OpenID authentication service is referred to as an OpenID broker, shown as 303 in
As with banking, principal 101 may have a relationship with more than one primary broker 301 and more than one secondary broker 302. For example, an individual might use one primary broker for personal information sharing relationships and a separate primary broker for professional information sharing relationships. In the former case, examples primary brokers might be the individual's bank, telephone company, utility company, or ISP. In the latter case, examples primary brokers might be the individual's employer or a professional trade association. In all cases the individual's selectors may be configured to communicate with the respective brokers, much as an individual's email client software can be configured to communicate with multiple email service providers serving multiple separate email addresses. This has the advantage that the individual only needs to install, configure, and use one selector on each device to access and control all of the individual's information sharing relationships regardless of context.
Brokered information sharing system 100 enables principal 101 to easily and safely form information sharing relationships with parties 400.
In two-way information sharing relationships, the principal also plays the role of the issuing party. For example, if Alice wants to share one of her own business cards with Bob, Alice is playing the role of both the principal and the issuing party, and Bob is playing the role of the relying party. Even if Bob initiates the transaction by requesting a business card from Alice, Alice still plays the role of the principal, since she controls the selection of the information to be shared and the relying party with whom to share it. Two principals may of course have reciprocal information sharing relationships, i.e., after Alice shares her business card with Bob, Bob acting as his own principal and issuing party may reciprocate by sharing his business card with Alice as a relying party.
In this specification cards are referred to from the perspective of the principal. A card issued to a principal by another issuing party is referred to as a third-party card. A card for which the principal is the issuing party is referred to as a principal card. In the IMI specifications a third-party card is called a “managed card” and a principal card is called a “personal card”.
With the proper permissions, information shared with a relying party may also be republished by that relying party as another issuing party. For example, Alice as an issuing party may share her street address with her telephone company as a relying party. Her telephone company as an issuing party may in turn republish that information to an online phone directory as a relying party. The present invention enables the chain-of-authority for such multi-party information sharing relationships to remain clear and unambiguous, providing greater control, auditability, and accountability for all parties.
With the proper permissions, information shared with one relying party may also be forwarded to another relying party. For example, Alice may give Bob permission to forward her business card to Bob's friend Charles. In this example Alice, not Bob, remains the issuing party. Bob is referred to as the forwarding party.
Parties 400 may also serve as service providers to principal 101.
Data blinding at the broker may be accomplished by encrypting the data at the selector. However if the selector is the only source of the encryption keys and other provisioning information, loss of the selector (either through physical loss of the device, or malfunctioning of the hardware or software) and/or loss of the credentials needed to authenticate the selector to the broker can result in catastrophic loss of the account and the shared information.
It is therefore important to have a method for safely recovering access to a principal's broker account(s) no matter what form of credential, key, or selector loss principal 101 may suffer. One such method is for principal 101 to use the services of key escrow service 403 as relying party 402 as further described herein.
A typical selector program 200,
Selector UI module 220 is responsible for displaying screens, menus, cards, data, and information sharing relationships to the principal and accepting input from the principal to control and manage the principal's information sharing relationships. Selector logic module 230 is where the processing logic of the selector is executed to trigger the display of screens, sending of messages, reading/writing of data, or performance of other actions needed to carry out the functions of the selector.
Selector cryptography module 240 is called by other modules when data encryption, decryption, verification, and other cryptographic services are required. With respect to the generation and transformation of security tokens such as those related to cards in protocols such as WS-Trust, this module is sometimes referred to as a “security token service” or “STS”. The current WS-Trust V1.3 specification, published by the OASIS Web Services Secure Exchange Technical Committee, is available at the link http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html. In a preferred embodiment, cryptography module 240 is configured to communicate securely with a similar security module that is part of the operating system of the device, such as the Microsoft Cryptograph API (MSCAPI) in the Microsoft Windows® operating system. Such security can be further hardened by use of a trusted hardware security module such as the Trusted Platform Module whose specifications are defined by the Trusted Computing Group at https://www.trustedcomputinggroup.org/specs/TPM/.
Selector communications module 250 is called by other modules to send and receive messages that need to be delivered over communications protocols relevant to the selector's functions. In a preferred embodiment, the communications module performs these functions by calling protocol modules 251 that handle the specific details of particular communications protocols. Besides WS-Trust, the example embodiments discussed herein may involve the HTTP, HTTPS, and XDI protocols. The HTTP protocol specification, published as RFC 2616 by the Internet Engineering Task Force (IETF), is available at http://tools.ietf.org/html/rfc2616. The HTTPS protocol, published as IETF RFC 2818, is available at http://tools.ietf.org/html/rfc2818. The XDI protocol, published of the OASIS XRI Data Interchange (XDI) Technical Committee, is a work-in-progress described in the aforementioned “The XDI RDF Model”. However in a preferred embodiment, brokered information sharing system 100 is extensible to support any type of protocol that may be used to transfer data, credentials, tokens, or cards.
Selector data access module 260 is called when the selector needs to read or write data from local datastores. In a preferred embodiment, the selector uses a data abstraction layer in which data access module 260 calls different data adapters 261 to read/write data from any type of datastore 271. Such a data abstraction layer is provided by the open source Higgins Project, a project of the Eclipse Foundation available at http://www.eclipse.org/higgins/. This data abstraction layer may be used on either clients and servers to make data available via a uniform API (application programming interface) and data model called the Context Data Model (CDM). On a client device, such a data abstraction layer enables a selector to read and write data from local datastores such as the Linux, Apple Macintosh®, or Microsoft Windows® file systems; local directories system such as the Windows Registry; local applications such as Mozilla Thunderbird, Microsoft Outlook®, or Microsoft Excel®; or local databases such as MySQL or Microsoft Access®. Such datastores may use application-specific data schemas, or they may use a context-independent schema such as the RDF (Resource Description Framework) defined by the World Wide Web Consortium's Semantic Web activity (http://en.wikipedia.org/wiki/Semantic_Web) or the XDI RDF model defined by the OASIS XDI Technical Committee. In particular the aforementioned document “The XDI RDF Model” specifies a compact serialization format for XDI RDF documents called X3. Several X3 variants are specified for different purposes: X3 Standard for compact over-the-wire transmissions; X3 Whitespace for human-readable display; and X3 Simple for human-readable/writeable display. The example XDI RDF documents disclosed herein use the X3 Simple format. In such example documents, all values enclosed in squiggly brackets, e.g., {selector-i-number}, are placeholders for the actual values used in real instances. In a preferred embodiment selector 200 is integrated with a principal's Internet browser and with other communications software that may run on a device such as an email client, instant messaging client, VoIP client, etc. Selector 200 can operate entirely as a plug-in module, or as a combination of a plug-in and a standalone program, or entirely as a standalone program, or any combination as best suits the operating system, security requirements, and user preferences.
Broker subsystem 300,
Service endpoints 311 are the server-side complement of protocol adapters 251 in
Web UI module 320 is responsible for display of web pages that provide a browser-accessible user interface for the broker. The present invention is not limited to a web UI; a client-server UI or any form of UI that provides principals with direct access to the functions of a broker when required could also be implemented. The broker UI is not a limiting feature of the invention.
Registries 381 are a specialized form of datastore optimized for storage and indexing of identifiers and discovery metadata describing principals and other parties in brokered information sharing system 100. Such registries may be implemented under a data abstraction layer, such as Higgins as described above, or they may be implemented separately. Such identifiers may be an OpenID identifier as defined by the OpenID Authentication 2.0 specification published by the OpenID Foundation, available at http://openid.net/specs/openid-authentication-2—0.html. OpenID identifiers include URIs conforming to the URI specification, published by the IETF as RFC 3986 available at http://tools.ietf.org/html/rfc3986, and XRIs conforming to the aforementioned “XRI Syntax V2.0” specification published by the OASIS XRI Technical Committee, or any other form of identifier which provides the identification and discovery properties required of brokered information sharing system 100 as described herein. Such discovery metadata may include data elements defined for XRDS discovery documents as defined by the aforementioned “XRI Resolution V2.0” specification published by the OASIS XRI Technical Committee, SAML metadata documents as defined by the “Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0” specification published by the OASIS Security Services Technical Committee at http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, WS-SecurityPolicy documents as defined by the “WS-SecurityPolicy V1.2” specification published by the OASIS Web Services Secure Exchange Technical Committee available at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html, or any other discovery or metadata exchange protocol that may be integrated into brokered information sharing system 100. In a preferred embodiment XRIs are used with XRI trusted resolution to retrieve XRDS documents.
The use of data access module 360 and, in a preferred embodiment, a data abstraction layer, such as Higgins can be employed by a broker to provide access to different back-end datastores such as LDAP directories, relational or object-oriented databases, in-memory databases, data warehouses, or other data repositories as needed to meet the broker's requirements for security, performance, reliability, scalability, and storage of different data types.
An example of party 400,
Although they serve different roles, the basic components of party 400 are the same for both issuing parties 401 and relying parties 402. The differences in how these parties employ these components are further described herein.
In one example, to create and manage information sharing relationships in brokered information sharing system 100,
The provisioning information originating at selector 200,
The provisioning information originating at primary broker 301,
The provisioning information originating at an OpenID broker 303,
The ISCP protocol uses three types of identifiers for a principal 101: principal i-name 523N, principal i-number 523, and OpenID principal i-number 523O. Principal i-name 523N identifying principal acting within an individual context begins with the XRI global context symbol =. This may be either a global i-name, for example =example.name, or a community i-name, for example =community*example.name. A principal i-name 523N identifying a principal acting within an organizational context begins with the XRI global context symbol @. This too may be either a global i-name, for example @example.name, or a community i-name, for example @community*example.name.
A principal may register more than one principal i-name 523N, and all such i-names may act as synonyms for the same public principal i-number 523. Principal i-name 523N may be used by the principal at any site or application that accepts an XRI for purposes of identifying the principal and resolving an associated service discovery document such as an XRDS document. An example is the use of XRIs for site-independent authentication of principals as described in OpenID Authentication 2.0 specification published by OpenID Foundation at http://openid.net/specs/openid-authentication-2—0.html.
When principal i-name 523N is registered, in a preferred embodiment, the associated XRI registry will automatically assign a synonymous public principal i-number 523. This is a persistent XRI that will never be reassigned by the registry, and thus can be safely used to identify the principal in brokered information sharing system 100 without the security issues associated with reassignable identifiers as described in “OpenID Discovery with XRI and XRDS”, a paper presented at the 2008 IDTrust Symposium published by the Association for Computing Machinery at http://middleware.internet2.edu/idtrust/2008/papers/01-reed-openid-xri-xrds.pdf.
The synonymous i-number for a global i-name is a global i-number, for example =!2a56.43dc.f892.22b9 for a principal acting within an individual context or @!723d.12ac.9e00.4506 for an principal in an organizational context. The synonymous i-number for a community i-name is a community i-number, for example =!bc52.5a73.df8a.c3d6!4871.3bac.404d.f5a5 for a principal in an individual context or @!723d.12ac.9e00.4506!d3ac.49c7.dfae.2a03 for a principal acting within an organizational context.
OpenID principal i-number 523O is the i-number used to identify principal 101 in the context of a specific OpenID broker 303. If principal's primary broker 301 is also principal's OpenID broker 303, then principal i-number 523 and OpenID principal i-number 523O may be (but are not required to be) identical. Otherwise, OpenID principal i-number 523O will be assigned in the context of the registry i-number 527.
For the purposes of the ISCP protocol, all participating OpenID identifier registries are identified using registry i-number 527 and at least one registry i-name 527N. This applies even if OpenID registry assigns http: or https: URIs as OpenID identifiers; from the standpoint of the ISCP protocol these identifiers are all synonyms of OpenID principal i-number 523O.
Although brokers 300 may also have both i-names and i-numbers, the ISCP protocol uses only i-numbers to identify brokers: primary broker i-number 521 and OpenID broker i-number 521O. An example broker i-number is @!af83.62b1.441f.2813. The ISCP protocol uses two identifiers for selectors 200 that are used by principals 101 to interact with brokered information sharing system 100: selector i-number 525 and selector i-name 525N. Although any resolvable identifier may be used for a selector i-number 525, in a preferred embodiment it is a persistent XRI composed of two parts: primary broker i-number 521 plus a local i-number assigned by primary broker 301 to represent the locally unique identity of selector 200 as an agent. An example selector i-number is @!af83.62b1.441f.2813!ef43.3012.d9a0.bb47, where @!af83.62b1.441f.2813 is primary broker 301 i-number and !ef43.3012.d9a0.bb47 is the local i-number representing the selector.
Selector i-name 525N is a human-friendly identifier assigned by principal 101 so principal 101 can distinguish between selectors in ISCP operations. In a preferred embodiment, selector i-name 525N, like principal i-name 523N, is a reassignable XRI that supports UTF-8 encoding for internationalization. Example selector i-names 525N in English are Family Desktop, Mary Laptop, iPhone, and Home Fax Machine.
The ISCP protocol also uses two identifiers for cards: card i-number 529 and card i-name 529N. As with selector i-number 525, in a preferred embodiment, card i-number 529 is a persistent XRI composed of two parts: registry i-number 527 plus a local i-number assigned by primary broker 301 to represent the locally unique identity of the card. An example card i-number is =!bc52.5a73.df8a.c3d6!82d2.fbc3.142e.5d25, where =!bc52.5a73.df8a.c3d6 is the registry i-number and !82d2.fbc3.142e.5d25 is the local i-number representing the card.
The ISCP protocol uses six types of credentials for principal 101: principal password 532, principal passphrase 534, primary broker password 536, account recovery data 538, password recovery question 540Q, and password recovery answer 540A. Other credentials may be used for stronger forms of authentication as further described herein.
Principal password 532 may be any form of password for the principal that satisfies the relevant security policies. If a password string is used, in a preferred embodiment, it satisfies a password strength meter or test administered by the selector or primary broker (depending on the initial point of entry) to ensure it meets the relevant security policies. In alternate embodiments a pictographic password, biometric password, or other form of authentication credential may be used. The particular form or strength of the credential used as principal password 532 is not a limiting feature of the invention.
Principal passphrase 534 may be any form of seed material suitable for generation of a cryptographic key for use by selector 200 on behalf of principal 101 and for transcription by principal between selectors as needed. It may be automatically generated by selector 200, or manually entered by the principal. In the latter case, in a preferred embodiment, the selector UI includes a passphrase strength meter or test to ensure it meets the relevant security policies. The particular form or strength of principal passphrase 534 is not a limiting feature of the invention.
In a preferred embodiment, primary broker password 536 is a complex value composed by concatenating principal password 532 and principal passphrase 534 and then hashing the resulting string. This binding supports desired password recovery and account recovery properties as further described herein. Any sufficiently strong secure hash function, such as MD5, SHA-1, or the SHA-2 family may be used since only selector 200 needs to be able to calculate the hash.
The purpose of account recovery data 538 is to serve as another set of credentials that enable primary broker 301 to authenticate principal 101 in case of password loss or complete selector loss. In a preferred embodiment, account recovery data includes the principal's legal name, legal address, email address(es), SMS address(es). Other potential types of account recovery data 534 will be apparent to those skilled in the art. The particular types of account recovery data 534 are not a limiting feature of the invention.
Password recovery question 540Q and the paired password recovery answer 540A are used as a second authentication factor in password recovery. An example of each is “What was your best friend's favorite hobby?” and “anthills”. They are used in conjunction with an account recovery code 531, a token delivered to principal 101 to authenticate that the principal controls the communications channels represented by the account recovery data 538. This token take any form necessary to meet the security and usability requirements. An example account recovery code is 7D84-9KFW-43NB-29GY-HCRA.
For brokers, in one embodiment, the ISCP protocol uses conventional X.509 certificates as credentials. These certificates contain primary broker i-number 521 or OpenID broker i-number 521O, as applicable.
The ISCP protocol uses four types of keys on behalf of principal 101: principal public key 542, principal private key 544, principal symmetric key 546, and card key(s) 548. In addition it also uses a blinded principal private key 544B and blinded card key(s) 548B.
Principal public key 542, principal private key 544, principal symmetric key 546, and card key(s) 548 are generated by selector cryptography module 240, using software libraries designed for this purpose according to the algorithms and formats specified by the ISCP protocol. In a preferred embodiment, RSA 2048-bit keys are used for public/private key pairs and AES 256-bit keys for symmetric keys. Key generation is discussed generally in the aforementioned “Applied Cryptography, Second Edition”. In a preferred embodiment this routine is implemented so that it requires little or no waiting on the part of principal 101. These keys are used for encrypting data stored at primary broker 301 or sent to relying parties 402, as further described herein.
Blinded principal private key 544B, and blinded card key(s) 548B are, respectively, principal private key 544 and card key(s) 548 encrypted by selector cryptography module 240 with principal symmetric key 546 for back storage at primary broker 301.
For brokers, the ISCP protocol uses conventional public/private key pairs: primary broker public key 541 and primary broker private key 543 for primary broker 301 and OpenID broker public key 541O and OpenID broker private key 543O for OpenID broker 303. In a preferred embodiment, these are RSA 2048-bit keys. The X.509 certificates corresponding to these public keys can be discovered from the broker's XRDS documents using XRI trusted resolution.
The ISCP protocol uses two service endpoints (SEPs) to represent principal 101: principal XDI endpoint 553 and principal OpenID endpoint 553O. It also uses one SEP to represent each broker: primary broker ISCP endpoint 551 and OpenID broker ISCP endpoint 551O. Examples of these service endpoints are shown in the principal XRDS document 1901 in
Selector 200,
If principal 101 elects to use an existing account in step 802,
Now that selector 200 has been provisioned with selector i-number 525, in step 815,
In step 821,
Having registered a new selector i-number 525 to the principal's primary broker account, in step 823,
For a new account, the next phase is selection of an OpenID identifier for principal 101.
While the sequence in
If primary broker 301 is not the authoritative OpenID broker 303 in step 1502, then in step 1511 and 1512 primary broker 301 performs the same XRI trusted resolution steps as steps 1402 and 1404 of
In step 1703,
If selector i-number 525 is verified in step 1704, in step 1705 primary broker 301 proceeds with all internal steps necessary to register a new account. Primary broker 301 registers a new principal i-number 523 representing the account in its broker registry 381, then provisions the account with the attributes and values supplied in the subgraph of the XDI $add$a$$ predicate in the Add New Account message 1801R,
As with selector 200, primary broker 301 should store all ISCP provisioning information securely in datastore 371. In a preferred embodiment, primary broker 301 performs this function by calling cryptography module 340,
In step 1706,
In step 1707,
The ISCP protocol provides for both provisioning of an existing OpenID identifier (if the OpenID broker supports ISCP) as well as registration of a new OpenID identifier. It can also perform these operations transparently for principal 101,
In step 2006,
If principal 101 is registering a new account in step 2012,
In step 2016, primary broker 301 returns Add OpenID Response: Success message 2101RT,
If primary broker 301 is not OpenID broker 303 in step 2006, primary broker 301 continues with OpenID forward provisioning sequence described in
In step 2205, OpenID broker 303 first verifies primary broker 301 signature. If it does not have a copy of primary broker public key 541 cached, it looks it up by performing XRI trusted resolution on primary broker i-number 521 and extracting the X509 Certificate element. Assuming this signature verifies, in step 2206, OpenID broker 303 next decrypts blinded principal password 532 and blinded principal public key 542 using OpenID broker private key 543O. In step 2207, OpenID broker 303 uses the principal public key 542 to verify the principal's signature on principal password 532 (this signature is the value of the $password$sig$key$private$rsa$2048 predicate). Assuming this verifies, steps 2212 and 2213 then follow the same tests as steps 2012 through 2013,
If principal password 532 does not verify in step 2213, in step 2221 primary broker 301 returns Add OpenID Forward Response: Failure message 2201RF,
If the principal password 532 is verified in step 2213,
This completes ISCP provisioning of a selector for a new primary broker and OpenID broker account. The preceding sequences have also covered provisioning of a new selector for existing accounts. This enables principal 101 to install more than one selector 200 on more than one device, as well as to recover the use of their accounts if a device is broken or lost or the selector stops working. Installation of multiple selectors also provides redundancy of the principal's ISCP data stored locally by a selector. However for maximum security the selector should not store a copy of the principal's primary authentication credentials, such as the principal password 532. This means that if such credential stolen or lost, the principal must have a mechanism for modifying it or recovering it—loss of authentication credentials should no more result in loss of a principal's broker accounts than loss of a driver's license should cause a person to lose their bank accounts. Therefore ISCP includes support for both functions.
Although incorrect entry of a principal password 532 can be detected locally by selector 200 by comparing it at the time of entry with principal password hash 532H, for security purposes primary broker 301 must also verify primary broker password 536. This test is performed in Step 2411. If it does not verify, in Step 2421, primary broker returns the Modify Password Response: Failure message 2501RF,
If the current primary broker password 536 verifies in step 2411, then in step 2412 primary broker 301 modifies primary broker password 536 to the new value. Step 2413 is a test whether primary broker 301 is also the OpenID broker 303. If they are not the same, primary broker continues with the modify password forward sequence described in
If in step 2413, primary broker 301 is not the OpenID broker 303, primary broker 301 continues with the modify password forward sequence described in
Step 2611,
If in step 2611, principal signature on principal password 532 does verify, in step 2612 OpenID broker modifies the value of principal password 532. In step 2613, OpenID broker 303 returns the Modify Password Forward Response: Success message 2701RT,
If principal 101 loses or forgets principal password 532, ISCP also supports password recovery.
In step 2806, principal 101 enters the account recovery code 531 via selector UT module 220. In step 2807, selector communications module 250 sends Get Password Recovery Questions message 2902,
If the account recovery code 531 is verified in step 2808, in step 2811, primary broker returns Get Password Recovery Questions: Success message 2902RT,
In step 2815, primary broker 301 tests if the account recovery code 531 and password recovery question 540Q both verify against the values stored in the associated account. If either value does not verify, in step 2821 primary broker 301 returns an error message to selector 200 indicating which value(s) did not verify, and selector 200 returns to step 2813 to prompt principal 101 to retry entry of the appropriate value(s). If both values verify, in step 2816, primary broker 301 tests if the account recovery code has expired. If it has expired, in step 2817, primary broker 301 returns an error to selector 200, and selector 200 returns to step 2801 to prompt principal 101 to initiate another password recovery request. If the account recovery code has not expired, in step 2822, primary broker 301 deletes the account recovery code 531 to ensure it is only used once. Then, primary broker 301 completes the password modification sequence starting with step 2412,
All the foregoing operations of the ISCP protocol are designed to empower principal 101 to use selector 200 to easily create and control information sharing relationships across brokered information sharing system 100. A primary use case is using primary broker 301 for online storage of cards representing sets of claims the principal wishes to share with relying parties. This function of a primary broker is referred to as a card wallet. In a preferred embodiment, the communications between a selector and primary broker for card wallet services employs the XDI protocol over an HTTPS connection in the same manner as ISCP provisioning. However, a card wallet service may use any protocol for selector/broker, broker/IP and broker/RP communications that is capable of securely transferring the necessary data structures. The specific communications protocol employed is not a limiting feature of the invention.
In step 3105, primary broker 301 verifies primary broker password. Assuming it verifies, in step 3106, primary broker 301 securely stores the card in the broker datastore 371,
In step 3111, principal 101 initiates creation of a principal card via selector UI module 220. In a preferred embodiment, this is via reference to a card template for the type of card desired (e.g., business card, friend card, contact card, registration card, shopping card, clothing card, travel card, etc.), however, any card in the principal's card wallet may be used as a template, or the card may be created from scratch. In step 3112, principal 101 edits the card. This may include assigning a card i-name 529N, selecting an image for the card, entering or editing card metadata, adding or deleting claims, and entering or editing claim values.
Step 3113 is a test if principal 101 wishes to discard or save the card. If the choice is to discard the card, the sequence ends. If the choice is to save the card, step 3114 is a test to see if principal 101 desires blinding of the card data. Blinding may be applied automatically or on a per-card basis depending on principal and/or broker policy. If blinding is not desired, selector 200 continues with step 3124. If blinding is desired, in step 3115, selector cryptography module 240,
Steps 3124 through 3128 are identical to steps 3104 through 3108 of
Alternately, in addition to the data sharing just described using the card key 548, selector 200 or primary broker 301 may store some or all of these claims values independently of the XML serialization of the card. In a preferred embodiment, this is done to enable keeping claim values consistent across multiple cards, as well as sharing these claims via other data sharing protocols. In this case the claims may be stored in the principal's own XDI context, in another XDI context, in a Higgins IdAS context, or in any other context available for this purpose. For blinding these claim values are encrypted with the principal symmetric key 546. An example shown in
In
In step 3304, primary broker 301 verifies primary broker password 536. Assuming it verifies, in step 3305, primary broker 301 data access module 360 uses a data adapter 361 to query the datastore(s) 371 serving as the cardstore(s) for the card wallet to obtain the set of cards matching the selector query. In step 3306,
Step 3308 is a test of whether a card is selected. If not, the sequence is complete. If a card is selected, in step 3312 selector 200 consults the card metadata to determine the card type. Assuming it is a third-party card, the selector also determines the required authentication scheme as defined in the IMI specifications. IMI 1.0 supports four authentication schemes: X.509 certificate, Kerberos token, username/password, and principal card, however it may be extended to additional authentication schemes. In step 3313, selector UI module 220 prompts principal 101 to submit the necessary authentication credential. In step 3314, selector 200 sends the WS-Trust Request for Security Token (RST) message including the authentication credential to the IP. In step 3315, IP cryptography module 440, referred to as a security token service (STS), verifies the authentication credential. In step 3316, IP STS processes the RST request, gathers the necessary claims data, and performs any necessary claims transformations. In step 3317, IP STS returns the WS-Trust Request for Security Token Response (RSTR) message containing the security token to the selector.
Step 3321 is a test of whether principal 101 requested to see the claims values. If not, selector 200 skips to step 3323. If principal 101 requested to see the claims values, in step 3322, selector UI module 220 displays the claims values. Step 3323 is an optional test, depending on the principal's preferences, of whether the principal wishes to proceed with submitting the security token to the RP. If not, the sequence is complete. If the principal chooses to submit the card, in step 3324 selector 200 logs this action in the card transaction history, which it can subsequently synchronize with the card wallet at primary broker 301. In step 3325, selector 200 forwards the security token to the RP. In step 3326, the RP verifies the IP's signature on the security token, and also verifies that the submitted claims satisfy the RP's security policy. If so, in step 3327, the RP returns the originally requested resource.
If the card selected in step 3308 is a principal card, selector 200 first determines if the card was blinded. If so, it uses the principal symmetric key 546 to decrypt the card key 548 and then uses the card key to decrypt the card data. In addition, steps 3314 through 3317 are replaced by a call from selector 200 to the selector cryptography module 240 to produce the self-signed security token that will be submitted directly to the RP in step 3325.
Automatic card backup and card roaming are not the only advantages of using brokered information sharing system 100 as a card wallet service. A third key advantage is the capability of primary broker 301 to provide authentication credentials to an IP 401 on behalf of principal 101. Conceptually this is very similar to the brokering of authentication credentials that selector 200 performs between an IP 401 and an RP 402 as shown in
In a preferred embodiment this process can be further optimized by in some cases combining the Get Card request with the Get Authentication Credential request so that both the matching cards and the necessary authentication credential(s) are returned in the same response.
This process is referred to as brokered authentication, and it has several advantages over the conventional card transaction model shown in
To understand the benefits of brokered authentication, consider the situation today of a user having several managed information cards in their Microsoft CardSpace (or other non-brokered authentication-supporting) selector. It is very likely that each of these managed cards uses a separate password for authenticating the principal to the card issuer. Every time the principal wishes to use one of these cards, they are prompted for a password.
By contrast, consider the same situation if the selector 200 supports brokered authentication. In this case every the principal 101 wishes to use one of these cards they must only authenticate themselves to the selector, and thus is prompted to enter the same “master” password each time. From the principal's point of view the number of required passwords has been dramatically reduced and convenience commensurately increased. If multiple cards are used one after another the improvement is even more noticeable, since the principal would only be prompted once for the set of cards.
Brokered authentication solves this problem by reusing the authentication session principal 101 has already established with primary broker 301 in order to use their selector 200 to access their card wallet. The basic ISCP authentication credential is already strong because due to ISCP provisioning it includes three factors: 1) the selector i-number 525, 2) principal password 532, and 3) principal passphrase 534. Selector i-number 525 is registered in a one-time interaction between selector 200 and primary broker 301 and thereafter is not exposed outside of interactions with the primary broker 301, which all take place under the confidentiality protections of the HTTPS protocol. Principal password 532 and principal passphrase 534, which in a preferred embodiment are combined into primary broker password 536 for presentation to primary broker, should only be known to the principal 101. Both can meet initial entropy tests enforced by the selector, and can be subject to maximum duration and other password and passphrase security policies enforced by selector 200 and primary broker 301. Also, although selector i-number 525 and principal passphrase 534 are typically stored in the host device by the selector, in a preferred embodiment such storage uses the security protections previously discussed so that they are not accessible by any process other than the selector. In addition, as previously mentioned, if a TPM is available selector 200 may use it for hardware-level protection of these stored secrets.
However if for a particular IP or a particular card the standard ISCP authentication factors are not enough, primary broker 301 has the full range of options available to authentication authorities (also called “identity providers”) to increase the strength of the authentication session establish by principal 101. An inventory of these options is provided by the “Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0” specification published by the OASIS Security Services Technical Committee at http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf, referred to herein as “SAML Authentication Context”. Certain of these options are specifically relevant to principal/primary broker authentication due to the unique ability of having an ISCP-provisioned selector operating on the client device.
The first option is using device fingerprinting: the ability of a software program residing on a client device to obtain and create a compact summary of software and hardware settings that uniquely identify the device in the same manner as a human fingerprint uniquely identifies a person. Device fingerprinting options are described in the Wikipedia article at the permanent link http://en.wikipedia.org/w/index.php?title=Device_fingerprint&oldid=245326745. A common example of such a setting is the Media Access Control address (MAC address), the identifier assigned to most network adapters or network interface cards (NICs) by the manufacturer for identification.
A much stronger form of device fingerprinting is possible if the host device has a Trusted Platform Module (TPM) installed. In this case the TPM can produce a “remote attestation”, a nearly unforgeable hash key summary of the hardware and software configuration of the host device which also enables the primary broker to verify that the selector software 200 has not been changed. This capability of a TPM is generally described by the Wikipedia article at the permanent link http://en.wikipedia.org/w/index.php?title=Trusted_Platform_Module&oldid=239003681.
A second option is IP address authentication, described in section 3.4.1 of SAML Authentication Context. Unlike device fingerprinting, this characteristic of a client device may change over time, however in many cases it will still fall into one of a small set of allowable ranges that may be enrolled with the primary broker 301. IP address authentication has the advantage of being independently verifiable by the primary broker at the IP protocol level when the authentication request message is submitted by selector 200.
Because they are attributes of the device hosting selector 200, both device fingerprinting claims and an IP address claim may be included as additional authentication factors in the Get Authentication Credential message 3501,
Another option is integrating the selector with a visual password authentication scheme such as those developed by Passfaces Corporation of Oak Hill, Va., USA (http://passfaces.com) or Vidoop Corporation of Portland, Oreg., USA (http://vidoop.com, also described in the Wikipedia article at the permanent link http://en.wikipedia.org/w/index.php?title=Vidoop&oldid=241774479). Such schemes do not rely on character-based passwords that can be subject to keyloggers or other spyware. Instead they employ human cognitive recognition capabilities to pick out a sequence of images such as faces or photographs from a matrix, a process that can be easier to remember and harder to guess than traditional passwords.
Visual password authentication may be integrated with selector 200 by having selector 200 request the image matrix from the primary broker in the same fashion as the CAPTCHA request messages described in
Another option which can be used if the principal 101 has been using the selector 200 for sufficient time. The principal can be challenged to answer questions about the history of interactions that they have been involved with using this particular selector. They could be asked, for example, questions as to which cards they have and haven't used at certain websites in some previous time interval.
Another option is integrating the selector with a hardware or software authentication token mechanism such as the SecurID token sold by RSA Security Corporation described in the Wikipedia article at the permanent link http://en.wikipedia.org/w/index.php?title=SecurID&oldid=243490527. Such token mechanisms employ a piece of hardware such as a key fob or USB key or a “soft token” operating on a PDA or cell phone that generates a unique authentication code at fixed intervals (typically less than a minute) using a built-in clock and the card's factory-encoded random key known as the “seed”. The seed is different for each token, and is loaded into the corresponding server as the tokens are purchased or assigned to principals.
Such a hardware token mechanism may also integrate a biometric credential. Biometric authentication is described generally by the Wikipedia article at the permanent link http://en.wikipedia.org/w/index.php?title=Biometrics&oldid=246537356. An example is the plusID personal biometric token sold by Privaris Corporation of Charlottesville, Va., USA (http://www.privaris.com) and described at http://www.privaris.com/pdf/plusID_datasheet.pdf. Once principal 101 has properly enrolled a biometric such as a fingerprint scan in biometric authentication system, it has the advantage of providing stronger proof that the actual principal is present at the point of authentication. It is also not subject to being lost or forgotten in the same manner as certain other authentication credentials, although biometric credentials may be subject to their own challenges such as change over time.
To be integrated with selector 200 as additional authentication factors for principal 101, hardware or software tokens and biometric credentials must first be enrolled with primary broker 301. Once enrolled, the selector may submit the corresponding token values or biometric values as additional authentication factors to the primary broker by adding new predicates to the {selector i-number} subject in the same manner as previously described.
Another option is using an independent second communications channel for authentication. This has already been illustrated with in the password recovery sequence shown in
Second-channel authentication is particularly effective for brokered authentication because it is much more difficult to attack than single-channel authentication. It cannot be compromised even by gaining complete control of a single device. It also uniquely leverages the ability of primary broker 301 to communicate with principal 101 via multiple communications channels, a capability not available to a card selector operating independently on a principal's client device.
Another option is integrating the selector with knowledge-based authentication, referred to as Knowledge Based Authentication (KBA). Rather than a memorized secret, KBA relies on a principal's knowledge of own past transaction history and relationships. Strong KBA relies on “out of wallet” information, i.e., knowledge that would not be available to an attacker even if the attacker stole the principal's wallet and thus gained intimate knowledge of the principal's conventional identification credentials. An example is KBA services offered by IDology of Atlanta, Ga., USA (http://idology.com) under the “ExpectID IQ” trademark and described at http://www.idology.com/knowledge.html.
Primary broker 301 has two basic options for offering KBA to principal 101. The first is using a third-party KBA service provider. The second is performing KBA based on a principal's knowledge of the non-blinded contents and transaction history of their own card wallet. The former may involve questions such as former addresses, employment history, or the sources or amounts of past credit transactions. The latter may involve questions such as card i-names assigned to specific cards, recently created principal cards, recently accepted third-party cards, past card transaction history, or knowledge of password recovery answers 540A. Wallet-based questions whose answers are discoverable from direct inspection of the card wallet may only be used to authenticate a principal at the start of a new wallet authentication session.
In step 3605,
Another advantage of brokered authentication is that primary broker 301 can provide authentication claims transformation services. Claims transformation as described by the IMI specifications and associated documentation is the process of an STS accepting a first set of claims from principal 101 or another IP 401 and transforming them into a second set of claims for an RP 402. A common example is when an RP's security policy requires a claim that a principal's age is greater than 21, but the claim input to an IP's STS is the principal's precise birthdate. In this case the STS can perform a claims transformation to return a boolean TRUE/FALSE claim of “age-greater-than-21” to the RP, thereby not revealing either the principal's precise age or birthdate.
Primary broker 301 may perform the same service for authentication claims. For example, it may take the authentication scheme required by a card from an IP as an input and determine whether the authentication credential(s) currently submitted by principal 101 meet the requirements of the requested authentication scheme. If not, primary broker 301 may “bump up” the principal's authentication level by challenging the principal once for the additional authentication credentials required.
In addition to claims transformation into the authentication token format required by an IP 401, primary broker 301 can also provide the IP with a richer set of authentication context claims. For example, while one of the four standard authentication schemes supported by the IMI V1.0 specifications is a principal card, and such a credential can be submitted directly by a card selector using its own local STS, such a card has a fixed set of standard claims, none of which convey authentication context information. However if a primary broker acts as its own IP, it can issue a third-party card or set of cards that offer a rich set of brokered authentication claims. Such a card or cards could include all the claims described herein; all the claims defined in the SAML Authentication Context specification; claims defined by other authentication context or assurance frameworks such as the “Electronic Authentication Guideline” published by the National Institute of Standards and Technology (NIST) as NIST Special Publication 800-63 Version 1.0.2 available at http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1—0—2.pdf, or any other authentication claims required by IPs 401.
In this case, IP 401 can formally act in the role of an RP 402 for the purpose of accepting an authentication token from primary broker 301 as an IP. This requires the IP to formally publish its own security policy to the primary broker describing the claims it requires and the security token types it accepts for authentication of principal 101 with regard to a particular card. This enables the primary broker to precisely produce the set of claims required by the target IP in the token type requested by the IP.
Although such authentication claims may be transferred automatically between the primary broker 301 and the IP 401 on behalf of principal 101, in a preferred embodiment, principal 101 may be given explicit control over such authentication via a brokered authentication card. This is a card formally issued by primary broker 301 to principal 101 to represent the authentication relationship with IPs 401 who accept that brokered authentication card. The principal may then choose the IP and/or card relationships for which their selector should automatically “remember this card” and authenticate them automatically vs. which the relationships for which the principal wishes to provide manual consent.
Another special type of brokered authentication scheme is a broker-issued one-time password, also referred to as an OTP. One-time passwords are generally described in the Wikipedia article with the permanent link http://en.wikipedia.org/w/index.php?title=One-time_password&oldid=245813937. One-time passwords are based on shared knowledge of the OTP generation algorithm by both the issuer and the relying party. In the case of a broker-issued OTP, the primary broker 301 is the OTP issuer and IP 401 is the OTP relying party. Once the OTP algorithm is shared between primary broker 301 and the IP, any principal 101 using a card wallet from that primary broker may be authenticated to the IP by an OTP issued by primary broker 301. One advantage of this authentication scheme is efficiency: the authentication claim is very small and the IP only needs to perform an efficient algorithmic check on the OTP instead of verifying a cryptographic signature from primary broker 301. Another advantage is that this scheme will worth with the standard IMI username/password token type instead of the more complex token types. A third advantage is that primary broker may use different OTP algorithms to convey OTPs corresponding to different authentication credentials or contexts. For example, four different OTP algorithms may be used to represent the four authentication assurance levels defined in the NIST “Electronic Authentication Guideline” described above.
Another special type of brokered authentication scheme involves direct backchannel communications between IP 401 and primary broker 301.
If a card is associated with an authentication contract, selector 200 may skip steps 7 and 8,
The security of this protocol can be further improved if the authentication contract token includes a nonce generated by primary broker 301 and returned to selector 200 in Get Card Response 3401R message,
Like the broker OTP model, the authentication contract model can be very efficient. Another advantage is that it allows IP 401 to dynamically communicate the IP's security policy requirements directly via the authentication query to primary broker 301 instead of via a static predefined security policy document. This enables the IP to customize the authentication requirements based on a particular card, a particular principal, a particular time or date, a particular primary broker, or any other dynamic security policy variable. One disadvantage of this authentication model is that the primary broker gains direct knowledge of when a principal is using a particular card from a particular IP, a requirement that can be avoided when the authentication credential request is submitted by selector 200,
In addition to brokered authentication, primary broker 301 is also in a unique position to provide claims describing characteristics of a principal's card wallet service. These include claims about other claims (“metaclaims”), as well as claims about cards, card transaction history, and primary broker interactions, collectively referred to as broker heuristics. Broker heuristics can provide valuable relationship metadata to both IPs 401 and RPs 402.
One category of broker heuristics is claims about the principal's enrollment in the card wallet service. For example, primary broker 301 can provide a claim concerning whether the principal passed a CAPTCHA test or a KBA test; whether the principal supplied a verified email address or SMS address; whether the principal has a verified postal address or legal jurisdiction; and whether the principal has performed age verification. Related heuristics are the age of each of these claims and how often these verifications were performed.
Another category of broker heuristics is claims regarding overall characteristics of the principal's card wallet, such as the age of the account, the frequency of usage of the account, the period since last usage, the number of selectors provisioned for the account, the age of the selector currently being used, how many times the principal has been authenticated at the selector currently being used, the type of host device for the selector currently being used (e.g., mobile or fixed, or other information available from device fingerprinting as described above).
Another category is claims regarding the cards in the wallet, such as the total number of cards, the number of principal cards, the number of third-party cards, the total number of card sharing transactions, and the average age of the cards. Still another category is claims concerning a specific card, such its age, frequency of usage, period since last usage, frequency of update, and period since last update.
In addition to individual metrics, a primary broker may also provide claims represented aggregated characteristics, metrics, or “scores” of a particular card, groups of cards, or the wallet as a whole. These are analogous to the metrics and scores provided by credit bureaus regarding an individual's or company's credit history, and they can be used for similar purposes, in particular to help prevent fraud or identity theft.
Broker heuristics can also be subject to the same privacy concerns as credit histories. A particular advantage of brokered information sharing system 100 is that the sharing of broker heuristics can be subject to the same security and privacy controls as the sharing of any other information regarding principal 101. For example, primary broker 301 may issue one or more cards directly to the principal to represent their relationship. Such cards, referred to as broker cards, may include claims controlling the gathering and sharing of broker heuristics. For example, the principal may elect via a broker card for a broker to automatically share broker heuristics with IP 401 or RP 402 that the principal has passed a KBA test to enroll in the card wallet service and has a verified email address and SMS address, but for the broker not to share metrics about third-party card transaction histories without requesting the principal's explicit consent. Broker cards provide a mechanism for principals to be directly involved in decisions regarding sharing of broker heuristics in the same way they control the release of claims from any other IP.
Broker heuristic claims may be shared directly between primary broker 301 and IP 401 by including them in brokered authentication credentials as described above. They may also be shared directly between the primary broker 301 acting as IP 401 and RP 402 whose security policy requests broker heuristic claims directly. A third option is for a broker heuristic to flow through from the primary broker to the IP in a brokered authentication credential, and then for the IP to dynamically include this claim in the security token it returns to selector 200 to forward to the RP. The more widely desired the broker heuristic claim, such as, “Has this principal passed a CAPTCHA?” or “Does this individual have a verified email address?”, the more value it provides to principals, IPs, and RPs to reuse this claim automatically throughout the chain of relationships.
However, although specific features of the invention are shown in some drawings and not in others, this is for convenience only as each feature may be combined with any or all of the other features in accordance with the invention. The words “including”, “comprising”, “having”, and “with” as used herein are to be interpreted broadly and comprehensively and are not limited to any physical interconnection. Moreover, any embodiments disclosed in the subject application are not to be taken as the only possible embodiments.
In addition, any amendment presented during the prosecution of the patent application for this patent is not a disclaimer of any claim element presented in the application as filed: those skilled in the art cannot reasonably be expected to draft a claim that would literally encompass all possible equivalents, many equivalents will be unforeseeable at the time of the amendment and are beyond a fair interpretation of what is to be surrendered (if anything), the rationale underlying the amendment may bear no more than a tangential relation to many equivalents, and/or there are many other reasons the applicant can not be expected to describe certain insubstantial substitutes for any claim element amended.
Other embodiments will occur to those skilled in the art and are within the following claims.
This application hereby claims the benefit of and priority to U.S. Provisional Application Ser. No. 61/196,931, filed on Oct. 22, 2008, under 35 U.S.C. §§119, 120, 363, 365, and 37 C.F.R. §1.55 and §1.78, which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61196931 | Oct 2008 | US |
