The Identity Dictionary

an identipedia (c)

100 (or so) technical terms for the common understanding of IAM

In this fast-moving world where standards are being developed even as solutions are being implemented, it is essential that technologists world-wide understand what each other is saying.

This dictionary is a simple and practical aid to understanding the complex discussions of technical concepts in relation to Identity and Access Management (and only that). I have compiled it over a number of years, as I make my living managing some of the world’s largest and most complex leading edge Identity Management projects , for financial, government and educational organisations.

It is not an attempt to create any standards in IAM concepts and terms; it would probably not achieve this on the broader stage due to language differences and changes in common usage over time.

Feel free to disagree, or to suggest additons to this list.

Acknowledgement - thanks must go to Dave Kearns for his superb newsletter, his musings and our discussions over the years. They have helped clarified the terms and concepts embedded here.

===================

1. Access – The ability to use a resource or a service. More specifically, the Permissions or Entitlements associated with an Identity.

2. Access Control – The management and authorisation process of controlling access to Roles, Resources and Services by Identities and Accounts. Roles are a pre-packaging of resources and services. Resources and services can be any object for which access can be controlled, such as hardware, software, devices, equipment, buildings, doors, and so on. If the role names (or descriptions) are based on one or more attributes directly related to the roles of an identity (e.g. a position title, location, function) it will enable dynamic role provisioning as a by-product of existing business processes - for example LAN access, email, building access. If the role names are not based on identity attributes (e.g. a particular software package, a PDA, internet access), they are a static role that is provisioned on a discretionary basis (i.e. an identity must request them in addition to the dynamic roles). The assigning of access rights may be permanent or temporary, and may only be valid for a single session. Also see Authorisation, RBAC and GBAC. This process is not to be confused with the registration and authentication of an identity; access is part of the risk/trust relationship that determines what a user is permitted to do, not who they are.

3. Access Control List – (ACL or ACI) – The security settings of an Application or Platform. Indicates the ability of an Account to read a file (or all the files) in a directory, to write to the files, and to execute the programs.

4. Account – An instance of an Identity. An Identity may have multiple Accounts. Usually associated with a single computer application or platform, but also applies to such things as bank accounts, utilities and telephone accounts.

5. Anonymity – The ability of an Identity to keep its Entity secret from everyone. Literally means "no name". It must be “persistent” which makes it difficult, if not impossible, to remain truly anonymous because details deduced over time may be joined with other details and republished (unless there are privacy laws preventing it). For example, a prepaid mobile phone can allow the purchaser to remain anonymous until a pattern of use is established. Also see Pseudonym.

6. Application – A software system, usually a business solution or end user tool.

7. Applications Inventory – A comprehensive repository of information about each Application, such as name, id, locations, business owner, system manager, platform, language, frequency of revalidation, users, and so on. Used to assist management in licensing, distribution, support, provisioning and auditing.

8. Assurance – A level of risk associated with an Authentication.

9. Assurance Framework – A methodology for managing Transaction Risk within a Channel, based on the combination of Registration strength and Credential strength. Usually presented as a simple model with X and Y axes. For example; the Australian Government Assurance Framework (AGAF). Also refer to The Assurance Framework

10. Assertion – A claim, such as to be a particular Identity or a member of a Group. Usually requires proof via a credential, such as in a user-id and password pair. Also see Authentication.

11. Attestation – The confirmation, corroboration or formal acceptance that something is correct. It is increasingly required by good corporate governance. For example; the “Sarbanes-Oxley” Act (SOX) requirements. Also see Revalidation.

12. Attribute – A type/value pair of information related to an Entity or Identity. It may be shared (eg nationality), or unique (eg DNA). A combination of attributes may be sufficient to satisfy an assertion. Usually a value in an identity repository (directory or database) collected directly or indirectly through registration, enrolment or access control. Also see Role.

13. Authentication – The process of establishing an Identity to be used in a particular instance, by verifying an assertion (eg claiming to be the owner of a set of credentials). See Assertion. In principle the original issuer of a credential should be the one to authenticate it; in practice this may be problematic and methods have been devised to share the authentication process. Also see re-authentication, and mutual authentication.

14. Authorisation – What the Identity can do, in a given instance, as a result of proving an assertion.

15. Biometric – A physical trait or behavioural characteristic that can be used for the purposes of identification or verification. A good biometric should be unique to an individual, stable over time, quick and easy to present and verify, and not be easily duplicated by artificial means.

16. Biometric Verification – Any means by which a person can be either a) Identified or b) Verified (authenticated), by evaluating one or more distinguishing biological traits. An identification system (eg AFIS) consists of the original trait and a database of stored traits, by comparing of a sample for close matches. On the other hand, a verification system consists of an assertion by using a username and a biometric that generates a ‘password’ string from the minutiae for an exact single match. Note: for verification, a biometric should not be used as a single-factor solution (see Factor).

There is a potential for the general public to misconstrue the use of biometrics for verification as a personal or civil liberty matter, but the privacy issues are very different to those related to identification (when the raw biometric data is stored).

Unique identifiers include fingerprints, hand geometry, retina and iris patterns, facial patterns, voice waves, DNA, photos and signatures. Keyboarding characteristics when entering a password (time between keystrokes and length of time keys are depressed) can also be used.

The possibility of false positives (acceptance of the wrong person) and false negatives (rejection of the right person) varies with the type of biometric and the desired balance or threshold between the False Acceptance Rate and the False Rejection Rate. The fingerscan single-factor FAR for a large population is usually below 5% when used for computer access, and can be much lower for a specific group such as office workers. Retina, Iris and fingerprints are much more accurate than most other biometrics. A finger can be re-scanned very more quickly after a false reject, as an occasional second touch will not be an inconvenience to valid users. It is not 100% accurate in all circumstances because variable environmental conditions (eg the cleanliness of scanners or finger), but some scanners have a design goal of a one-in-50,000 chance of accepting the wrong fingerprint and a one-in-100 chance of rejecting the correct one.

Biometrics are security and privacy enhancers, and fraud mitigators, by ensuring "you are you". Biometric verification systems based on finger-scans are less costly, more convenient, quicker and easier to use than any other single-factor alternative. Even identical twins and genetic clones, who have identical DNA and similar voices, have different fingerprints. They generally remain unchanged throughout a person’s lifetime (although they can be damaged and then may need to be re-acquired).

Physical tokens such as Smart-Cards, Magnetic-Stripe cards, Proximity cards, One-Time Password calculators, physical keys and so forth can be shared, misplaced, stolen, lose memory, be duplicated or be left at home. Personal Identification Numbers (PINS) and Passwords can be forgotten, written down, copied, shared, guessed, observed, or the keystrokes captured and replayed. Biometrics isn’t necessarily more accurate than these, but it has none of these disadvantages, and it has some additional advantages. Biometrics should always be used in conjunction with another factor such as passwords, PINs, smart-cards or tokens to add a second access layer to security for authorised users. A "one-time biometric" would consist of a biometric that unlocks a OTP device.

The most common FAQs regarding fingerscans revolve around Security, Privacy, and popular folklore such as fingers being ‘chopped off’; all of these are easily addressed in a non-AFIS verification system (where the image itself is not recorded, the pass-phrase it generates is encrypted, it cannot be reverse engineered back into a usable image and it cannot be copied from server to server) . There are four main types of finger-scanners: Optical scanners use reflected light; silicon-based Capacitance use the body’s natural conductivity; Radio Frequency (RF) uses the live sub-surface skin cells, not the dead outer skin layer; Thermal Image registers the differences in temperature between the ridges and valleys, by swiping the finger over a thin line of sensors. None will recognise a latent print, such as a print left on a glass or the sensor itself. It is recommended that at least one finger on each hand should be enrolled (usually the index finger). This will still enable a user to log on even if a finger or hand has been injured, cut, blistered, etc. Additions or replacement scans can be easily enrolled at any time in the future, although access to the registration software might be restricted, depending on whether self-enrolment is allowed.

Any planned use of a strong biometric for authentication of customers should be paralleled by a similar planned use by employees.

17. CardSpace – aka InfoCard – Microsoft’s answer to remembering multiple passwords and other levels of security data. An Identity is represented by an icon representing a (digitally signed) set of claims. These are held in an XML security token called a card (.crd file, encrypted and password-protected) . The cards can be "self-issued" ('add a card') which you can link to an existing account, or they can be uneditable third-party "Authority issued". The card doesn't hold any credentials, only pointers to them - think of a business-card. The cards are stored on the user’s PC, and tell it how to contact each Identity provider to get an Identity token each time one is needed (usually initiated by a web-browser) and what it will look like (Kerberos, SAML, X.509, etc), using WS-Security protocols to deliver the different token types. You can export one or more cards from the Cardspace client and then import them into another client, email them or put them onto a USB key or mobile device. Also see MS-Passport.

In a similar manner, IBM's open-source Identity Mixer (Idemix) lets a person use digital encrypted tokens for on-line transactions via a browser plug-in. They are issued by trusted sources (e.g. a bank or government agency) and can "vouch" for a person without disclosing unnecessary personal information (eg birth date, drivers licence, credit-card number). Where card-space uses either self-issued cards or identity-provider tokens that ping an identity provider, Idemix allows a person to maintain their tokens and the identity provider doesn't have to be contacted.

18. Certificate Authority – CA – The issuer of a public/private key pair belonging to one identity. Also see Digital Certificate and PKI.

19. Certificate Verification Service – CVS – the process used to verify a Digital Certificate via the CA. Also see Certificate Revocation List, OCSP, Digital Certificate and PKI.

20. Certificate Revocation List – CRL – The published list of revoked certificates from the CA. Also see Certificate Verification Service, OCSP, Digital Certificate and PKI.

21. Channel – The instance or form of communication between identities and service providers, each with its own set or security processes and risks. Similar to "context" where the circumstances (where, when, how) of an authentication can influence its assurance level. For example; face-to-face, proxy/representative, legal documents, telephone, mail, on-line network, email, FTP, internet, world wide web, unusual location, unusual time of day.

22. Connector – An agent or interface that enables changes to Identity data to be collected from trusted sources in near real-time and made available (published or subscribed) to identity directories or other systems. For example; details of a new employee published by the HR application to the Identity repository, for the purpose of provisioning. Some interfaces are termed “agent-less” when they don’t use a permanent connection between sources; instead they acquire the most up-to-date identity information only when it is required (ie event-based), usually by prior indexing or schema matching of the sources of the data; this is the way a 'virtual directory' work.

23. Credential – The private part of a paired Identity assertion (user-id is usually the public part). The thing(s) that an Entity relies upon in an Assertion at any particular time, usually to authenticate a claimed Identity. Credentials can change over time and may be revoked. Examples include; a signature, a password, a drivers licence number (not the card itself), an ATM card number (not the card itself), data stored on a smart-card (not the card itself), a digital certificate, a biometric template.

There is no need to issue a new credential if an Identity already has one that can be used, is trusted and whose currency can be reconfirmed at each authentication such as an existing account, or a digital certificate from a trusted organisation (see ID Law 5 in The Identity Laws).

24. Cryptography - The mathematical methods of protecting and keeping private of shared secrets, usually in a message. Literally means "hidden writing" (greek). For example; ROT13 (a rotation cipher) and Code (word replacement). Modern technoiques include algorythms, hashes and keys. Qantum cryptography allows only a single recipient, as the act of reading alters the contents and so allows detection of a passive eavesdropper - most systems use single photons from a laser. Fibre lasers can provide secure transmissions over long distances. Not to be confused with steganography (the act of hiding the existence of a message, such as in pictures or sounds). See encryption and decryption.

25. Data Quality – A measure of the timely correctness of information. New IAM solutions usually highlight that existing data and processes are inadequate, even though they remain suitable for existing business needs as reflected in the source application’s objectives. Also see Trusted Source.

26. Decryption – The process of converting encrypted data back into its original form, so it can be understood.

27. Device ID – The unique serial number or ‘fingerprint’ that a particular device has embedded in it. Thus a particular PC or PDA can be “something you have” in a two-factor solution. It can be the combination of several components (eg CPU + graphics card) and can include a threshold (ie less than 100% matching) to allow for partial upgrades, such as with the iPass (proprietary) solution. It may be a temporary identification for a session for ensuring compatible device usage, or it may be a permanent registration of the ID for inclusion as a trusted credential in an Assurance Framework and in a subsequent authentication process.

28. Defence in Depth – DID – This is a concept that refers to implementing layers of technical, organizational, and operational security controls, requiring breaches to penetrate several layers in sequence beginning at the border or perimeter of the network. Can be used in conjunction with an Assurance Framework’s credential strength.

29. Delegated Administration – To act on behalf of the administrator of an Identity repository. This is usually achieved by partitioning and filtering the directory and providing simple tools such as web-based functions to add/modify/delete a subset of accounts. It is particularly useful for trusted organisations working as agents on behalf of the owner of the repository, to manage its own staffs access.

The ability to nominate a proxy, representative or agent is a different form of delegation, that usually establishs trust between the entity and another entity (not the service provider). For example allowing an accountant to access some banking records but not to transact, or telling your partner your PIN and giving them use of your ATM card.

30. Digital Certificate – an electronic ‘document’ based on the International Telecommunications Union (ITU) X.509 (1988) standard consisting of a public/private key pair; their usage is governed by a Policy and a Practice Statement. They can be used for verification, encryption and digital signing. A digital certificate can also serve as an electronic notary seal (stamp). A certificate contains a digital signature, verified by another certificate - this creates a chain of certificates that ends with the 'root' certificate (which is self-signed); the owner of the root certificate is called the Root CA.

A Trust Policy can specify appropriate uses for a certificate: "should I trust this certificate for this action?". For example an S/MIME policy specifies that in order to be trusted to verify a digitally signed email, a certificate must contain an email address that matches the address of the sender of the email. This should also be part of an Asurance Framework.

Also see Cryptography.

The structure of a digital certificate is:
Certificate
... a. Version
. . b. Serial Number
. . c. Algorithm ID
... d. Issuer
. . e. Validity
. ... i. Not Before
.. .. ii. Not After
... f. Subject
. . g. Subject Public Key Info
... . i. Public Key Algorithm
..... ii. Subject Public Key
. . h. Issuer Unique Identifier (Optional)
. . i. Subject Unique Identifier (Optional)
... j. Extensions (Optional)
Certificate Signature Algorithm
Certificate Signature.

31. Digital Signature – An electronic signature that can be used to authenticate the identity of the sender of an electronic message or the signer of a digital document, and to ensure that the original content of the message or document that has been sent is unchanged. Not to be confused with a digital certificate.

A cryptographically calculated value is derived from the message and the private key associated with the digital certificate. The public key in the digital certificate can be used to verify that the calculated value corresponds with the message, proving that the digital signature was created by the person in possession of the private key associated with the digital certificate, and that the message has not been changed.

Digital signatures can be susceptible to a “birthday” attack – so called because the probability of two or more people in a small sample having the same birthday appears to defy intuition (as do most coincidences). It is applicable to coincidences in languages and alphabetic cyphers. As an example, for a 64-bit hash there are approximately 1.9 x 1019 different results, but it would take 'only' approximately 5.1 x 109 attempts to generate a match. To create a ‘birthday’ attack, you first prepare a document where a number of things can be changed without changing the meaning, such as inserting commas, empty lines, replacing synonyms, etc., and then you create a large number of variations of the document and apply the hash function to all these variations until a version of the original and a version of the fraudulent document are found to have the same hash value. After the recipient has signed the original document, the issuer takes the signature and attaches it to the fraudulent document, thus “proving" that he signed the fraudulent document. To avoid this attack, the output length of the hash function used for a signature scheme should be large enough so that the birthday attack becomes computationally infeasible, i.e. about twice as large as is needed to prevent an ordinary brute force attack. It is also recommended that a recipient always cosmetically modify any document presented for signing; however this may not solve the problem, because the issuer may then suspect the signer of attempting to use a birthday attack.

32. Directory
Directory [1] – a hierarchical repository used for authentication and/or identity management. Usually based on the X.500 standard and LDAP protocol. A directory may be replicated, partitioned and/or filtered. A ‘virtual’ directory may conjoin data from disparate data stores by containing only pointers to the data, rather than the data itself.
Directory [2] – a list of Identities used for inquiring or searching, usually the by-product of identity management. For example; a staff telephone list or White Pages phone directory.

Directory merge and replication is the most efficient way to consolidate directories in two organisations, in suchcircumstances as takeovers or partnerships.

33. Duress indicator – A method of indicating that a particular authentication is being done under threat or coercion. For example; a particular password, a special finger(print) or a spoken phrase that is never used for authentication unless being forced to do so.

34. Encryption – The conversion of clear text (readable data) into a form called cipher text that cannot be easily understood by unauthorised people or systems, by using cryptographic keys. These keys need to be kept secure from software hacking and loss - PC motherboards that have a Trusted Platform Module can be used. For example; Microsoft's BitLocker in Vista can use the TPM chip to store disk encryption keys.

Authentication data should also be encrypted from its initial input source to the final authenticator to ensure that it is protected from in-transit attacks - this especially applies to smart-card readers and biometric devices.

Encryption methods are either symmetric or asymmetric. In symmetric algorithms (Private-key cryptography), e.g. DES (USA 1976, 56-bit key, can now be broken in less than 24 hours), TripleDES (168-bits or three 56-bit DES keys) and more recently AES (USA 2001, fixed block size of 128 bits and a key size of 128, 192 or 256 bits, approved by NSA for TOP SECRET), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption. In an asymmetric key algorithm, e.g. RSA (USA 1977, MIT 1983, based on factoring large prime numbers, typically 1024 or 2048 bits long) there are two separate keys: a public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform decryption.

Also see Cryptography, Digital Certificate and Decryption.

35. Enrolment – The process of adding a Permission to an Identity. It may result in the issuing of a new identity or an additional account. The link between Registration and Enrolment must remain unbroken.

36. Entitlement – see Permissions.

37. Entity – anyone (a natural or legal ‘person’) or anything with a separate existence that can be characterised through the dimension of its attributes. Usually requires a cognitive ability, such as human cognition, whereas an Identity doesn't - refer to the Turin Test, the Deep Blue chess program and the HAL9000 of "2001 -A Space Odyssey". An Entity may not need an Identity to access a ‘free’ service, but needs at least one Identity to access a restricted service. In general an Entity cannot be owned, in the way that an identity can be owned, except in some legislative sense. Shareholders of a company may claim ‘ownership’, when they in fact only have some legal entitlement to the assets. Animals (eg horses) and humans (eg slaves) cannot actually be owned in the Identity sense, only possessed due to legal arrangements. Given that access credentials are issued to identities, why does this matter? Because it is the entity that applies for each identity, and the entity is legally responsible for the actions of the identity. It is often the entity that federates multiple identities.

In similar ways to this, Dr Sigmund Freud saw the person (entity) as consisting of the ID (identity) with an Ego or rational mind (additional identity ‘attributes’) and a SuperEgo or conscience (more identity ‘attributes’). Nietzsche called the ID the “It” (identity) and investigated the life-affirming and life-denying qualities (attributes). Thus some people are seen to have multiple personalities, more than one ID each with its own ego (more than one Identity each with its own attributes). Also see Identity and Owner.

38. Ephemeral Key – A cryptographic key associated with an expiration time. The ability to encrypt data in such a way that ensures it cannot be decrypted after a given date/time. This results in ‘ephemeral data’. One party establishes a number of ephemeral public/private key pairs, each of which will be destroyed at a time in the future and makes them publicly available; a second party then selects one of these key pairs having an expiration time appropriate for its needs. The requesting party first encrypts the data using an encryption key of the party which will receive the message, and then encrypts the resulting encrypted data again using the acquired ephemeral encryption key. It is not necessary to encrypt an entire message using an ephemeral encryption key; it may simply be used to encrypt another key contained within the message header.

39. Event Logging – The recording of details of an end-to-end enterprise-wide process, for audit purposes. It should have the ability to give a single picture of the actions of any identity over time. The file should be encrypted, and digitally signed to detect tampering. It may include capture of web-based actions, authentication, accesses and database activity related to an application or a session. It may also include real-time alerts, as well as after-the-event reports.

40. Evidence of Identity – EOI or POI – The items and documents used to prove an Entity’s identity.

41. Factor – The fundamental classification of credential types. There are actually only three factors: what you ‘know’, what you ‘have’, and what you ‘are’. Combining two, or three, into a multiple-factor solution is a means of stronger authentication. There are suggestions from time to time of new factor classifications such as ‘what you do’ or ‘where you are’, but they always resolve into the basic three.

Recent suggestions have included Context-based access (or Presence), which attempts to assign access rights based on the platform or the location of the user; but these are simply something you ‘have’. Examples are a particular PC configuration, IP address, MAC address or a Device-id. This is not to say that context inicators (such as when, where, how) can't be used in an authentication framework; they can, but mostly as an inicator that the identity is not using the usual device based on past patterns, weaking the original assurance level (therefore requiring further challenges), or causing the provider to use a different assurance-framework instance that requiries a different challenge (or via a different channel) . IP address can also be used as a blocker to services where government regulations prevent access, and as a check to prevent session piggybacking, but it is not really a 'credential'.

Also the idea of Reputation is occasionally suggested as an identity or as a credential; but it is only a temporary trust attribute that may only be valid for a single session and as such is not an integral part of the identity. Examples are an eBay sellers rating or history, a criminal record, a reference check, a credit report. These can still be considered as part of the risk/trust relationship to determine what accesses you have or are permitted to do in a session, but they are not really an authentication credential and therefore not a credential type or factor.

Another recent idea is "who you know"; clearly this is simply what you know about an identity and therefore is not a new fourth factor. More importantly "who you know" can have little or no value as a credential in an assertion unless it relies on proving that claim, and that must include the identity that you know confirming that they know you. Perhaps "who knows you" might be useful in establishing an identity but that is a Registration strength, not a Credential strength - refer to Known Customer, and Assurance Framework

Similarly, using multiple challenges such as several passwords or secret question/answer sets is not multi-factor - it is only multiple tiers of the same factor (more things that you "know"). No matter how many you use, the added strength of each SQA adds an exponentially smaller increment. It can't increase the assurance level to equate the strength of two factors, although it can go close. Also see Credential, and Assurance Framework.

42. Federation – A method of linking together the Identities of an Entity, to provide shared services as a matter of convenience, efficiency and trust.
The main methods are:
i. the Gateway / Key-store approach, where Identities from different platforms or organisations are permanently related to each other by ‘keys’ that are stored in a centralised vault. Think of non-bank ATMs, or telecom accounts. Identities usually choose to become a “member” (and can later opt out?) in order to access shared services on a LAn or externally that have been designed with interoperability in mind, usually (but not always) via a single authentication. It may allow the Entity to choose which organisation and which Identity will be used, or there may be a single authentication gateway or portal and a single (new) Identity required. The benefits may be related to only having to do something once, such as change password or mailing address. Depending on the number and type of shared attributes, as the scale of this federation increases their management can become burdensome, and the risks can outweigh the benefits.
ii. the Passport / Wallet approach – This is (or was) similar to the key-store approach but limited to authentication, by a central authority (eg Microsoft). It aims to achieve universal single sign-on to do open and federated authentication among organizations, thus avoiding the user proving an assertion to each participating site. The service may be free to users, but the relying business may pay a fee. There are significant privacy and security issues related to this approach.
iii. the Single Sign-on approach, for temporary access to multiple internet domains, via a single authentication, where separate organisations have agreed to provide common Identities with shared access (and thus provide reciprocal hyperlinks on their web site). Identities usually choose to access the other organisation(s) simply by clicking a link on the web-page of the original organisation. This method re-establishes the trust in each session, and shares a set of common pre-determined attributes between organisations (including identity, channel, location and credential used). It allows the Entity to choose which organisation will be the entry point and which Identity it will use, for each session. For example; SAML assertions.
iv. the Invitation approach, where an Identity who is an Owner of a resource invites one or more Identities to accept access to the offered resource (ie to join their user list). Each invitee’s positive response creates or updates access, based on a shared identifier, between the invitee’s service provider and the owner’s service provider. This is actually the federation of the invitee’s identity between two service providers, for the specified purpose of using a People Service (PS) web-service. It does not federate the inviter (unless inviting one of its own identities). It is a means of allowing identities that are members of a community of interest (eg a circle of friends) to share resources, without needing to ‘remember’ the URL, as the hyperlinks will usually not be hosted by either service provider. This approach could also be seen as a combination of both i) and ii) above, but with few (if any) attributes shared; it may become burdensome to maintain if the membership and reciprocation multiplies significantly.

v. the Open Identity or "Identity v.2" or "User-Centric" approach, where an entity authenticates itself (maybe even to itself) by choosing which identity it wishes to use this time, and then provides the required attributes to the relying party. Some propose OpenID be based on ownership of a URI/URL, or even a GUID. One of the tenets (and security issues) of OpenID is that there should be nothing installed on the client-side. It embodies the idea that you don't need to be issued a new identity or credential if you already have one that can be trusted (see ID Law 5 in The Identity Laws). Proponents are yet to overcome the question of trust, the lack of incorporation of a formal assurance framework (a common standard assurance is implied), and the legal/policy aspects, before it is applicable to anything other than sites who don't really care who you are. Yadis (Yet Another Decentralised Identity Interoperability System), Sxip, MS-Cardspace and Liberty ID-WSF protocols are related to this approach. But is it a new era, or is it simply an example of the evolution of a generalised federation beyond SAML and single sign-on? And can it become applicable to more than one credential type? This may depend on the degree of support recently announced by Microsoft (see Cardspace).

NOTE - Many SSO solutions involve replacing the native Windows GINA logon screen that is invoked at startup or by CtrlAltDel (eg Win2K, XP) with a different one. This is usually done to manage, recover and snynchronise the AD password with other platforms. However that is no longer possible - the GINA concept was abandoned in Vista. You now need to create a "Credential Provider" to run code before a user logs on; the provider object stays alive until the user logs off. You may need to deal with multiple instances (if fastswitch is invoked).

Another common technique for SSO, for browser-based applications, is SPNego (Simple and Protected NEGOtiation mechanism) a Microsoft protocol that allows for HTTP negotiation between the client browser and the web server. Sometimes referred to as 'spengo', and as “Windows Integrated Authentication”. The client identity presented by the browser can be verified using Kerberos authentication mechanisms.

43. Federated Identity – A shared Identity and/or authentication, as the result of federation by either the Entity or by two or more organisations. In a federated identity management scenario, an organisation may assume the role of an identity provider, or requestor / service provider, or both - they are not mutually exclusive. An identity provider ‘owns’ the relationship, directly manages end users and is the authoritative source for issuing and validating identities and credentials for a set of users. Identity providers "vouch" for the user identity in a federated interaction with service providers. A service provider does not have a vested business interest in managing the user, but acts as a "relying party" to validate credentials issued by a trusted identity partner. Key standards are SAML, Liberty, WS-Federation, WS-Security and WS-Trust. Also see Federation. A "Circle of Trust" is used to describes the legal agreements made between the parties.

44. Governance Based Access Control – GBAC – Information assets can be managed based on their governing legislation. GBAC considers the larger issue of why information is being held in the first place, and takes into account that multiple authorities may be required to determine access control or information sharing decisions. Rules can be enforced based on key governance issues: Jurisdiction, Collection Legislation, Collection Purpose, Security Designation, Disclosure Legislation and Disposition Authority. By classifying information according to governance and specifying the rules of governance, an organization may share information without knowing the recipient, the intended use or the specific contents. Also see Privacy and RBAC.

45. Group – A set of one or more Identities that can be authorised under one Rule. An Identity may belong to zero, one or more groups. Grouping is usually done for ease of management. See RBAC.

46. Hard Certificate – A digital certificate where the private key is generated directly onto a token, from where it cannot be copied. This does not stop it being exported and imported using the PKCS standard #12. Also see Soft Certificate.

47. IAM – An acronym for Identity and Access Management, its techniques, tools and solutions.

48. Identification – The process of establishing an Entity, rather than an Identity. For example; any one-to-many matching of characteristics or features of a group to derive “best fits” to raw data (not a yes/no outcome), such as in an AFIS (the law-enforcement Automated Fingerprint Identification System) or DNA matching process. Usually not performed in real-time due to the processing overheads. Contrasts with Verification. Also see Identity [3].

49. Identity – A much abused or misunderstood term. In the IAM context it generally refers to the particulars of an authentication. More specifically, it can mean:
Identity [1] - the established relationship between an Entity and a particular Registration (eg a regsistered user's EOI details). An Entity can have multiple Identities, usually one per Registration. An Identity may have multiple Accounts, usually one per environment or platform. Also see Entity.
Identity [2] - an instance of an Entity. A user (username and password), an account.
Identity [3] [lesser usage] - the identifier (username, customer number) used as a means of identifying an Entity. If this usage is adopted, then ‘Digital Identity’ is the term to be used to mean the relationship between an Entity and a particular Registration, or the instance of an Entity (ie Identity [1] or [2] above). But this is regarded as a clumsy invocation that does not add to understanding or communication.

An identifier is issued by the registration authority. A particular identifier known as a GUID (Globally Unique Identifier) is generated in the identity repository, but is not usually issued to the entity.

50. Identity Fabrication - the creation of one or more fictitious identities. This is usually achieved by fabricating an entity, or by an existing entity altering one of it's identities, for fraudulent pourposes.

51. Identity Management – Formal standardised enterprise-wide or community-wide processes for managing multitudes of Identities.

52. Identity Theft – This is the use of an existing Identity without the permission of the Entity. Usually achieved by guessing or stealing the credentials, enabling authenticating to a service provider. For example ATM card skimming. The original entity may or may not lose the particular Identity. Often confused with Identity Takeover. Also see Owner.

53. Identity Takeover – This is usually the creation of a new Identity without the permission of the Entity. It is actually the theft of the Entity, because the aim is to create a new identity that is linked to someone else, and this is the only way of doing that. It is commonly but incorrectly called "identity theft" (see above). It is mostly done off-line by acquaintances, by mail intercept, credit card receipt dockets or by "dumpster diving". It occurs by accumulating information and documents about the entity, usually accompanied by some social engineering. It is then followed by registration of new identities with different service providers under the other entity's name. The original entity may not lose any existing identities, but is generally presumed responsible for the actions of the new identity. Also see Owner.

54. IDM – An acronym for Identity Management tools and solution.

55. Kerberos – (Greek mythology: the three-headed dog that guarded the gates of Hades). An authentication service that issues a ticket-granting ticket and a one-way hashed session-key (for encryption), stored in a cache. It requires the continuous availability of the kerberos server and synchronised clocks, and can support SSO to other 'kerberised' services. It provides mutual authentication, and many-to-many communications. Created by MIT, used by MS-Windows, Mac, SUN, Linux and others.

56. Known Customer – A level of trust, it may be peer-generated or be determined by the service provider. Biased towards recent actions, it is an indication of a regular customer acting as expected at a predetermined registration strength or level of trust. This is usually only applicable within one organisation, or in a "community of interest" such as a group of government agencies or in "user-centric" identity management. A good example is how a user earns 'karma' at slashdot.org. Similar to Reputation or Character, it may be based on the recommendations of others whose opinions may have a trust value to the relying party, but it should be limited to within a given context. Social networking is a similar term. The results can be manipulated and even purchased, e.g. on My Space. Also see Trust, and the Federation ‘invitation’ approach. Social networking where ones reputation or friends .

57. Man-in-the-middle – MITM. An intermediate party acting as a proxy for clients on either side. Also a method of attacking a secure transmission, whereby the MITM intercepts and forwards messages without either party knowing it. This gives the potential to eavesdrop, change the message or collect private information. Applies to any message, encrypted or not. Mutual authentication is one form of protection. Trusted agents (eg a Root Certificate Authority) are another.

58. Meta-data – The information that describes another set of data (ie data about data). It is used to establish a common naming terminology and/or a common repository for instances of the same data. Applicable mainly to IDM attributes, data warehousing cubes and data exchange events. For example; surname, last name, family name, employee name, customer name, staff-surname may all be described as “sn” in an IDM repository or in XML.

59. Mutual Authentication – This requires that both the service provider and the user positively identify each other. In this way the authentication is strengthened for both parties; it cannot be phished or spoofed as users aren't tricked into entering personal information on fake sites.

60. Non-repudiation – The ability through historical logs and logical analysis to prevent or discourage an Entity from denying that it had acted as an Identity in a given transaction, especially in a legal sense. It may need to be based on a biometric and include encrypted audit trails to be successful in a court of law; otherwise the offender could be able to plead guilty to the lesser charge of leaving their password on a Post-It Note.

61. OCSP – Online Certificate Status Protocol – This is the real-time method of establishing the status (current, expired or unknown) of a Digital Certificate, using HTTP. An older method, which OCSP has superseded in some scenarios, is known as Certificate Revocation Lists (CRL).

62. One-Time Password – OTP – A temporary password generated by a time-based algorithm that is then compared to a server-calculated password. It is only valid within a short time ‘window’ (such as one minute) and can (preferably) only be used once within that time window. Also known as Time Synchronisation. The server and the token clocks need to remain synchronised over time and processes are usually implemented to adjust for that. The passwords are usually 6-digit codes and usually generated by a device, either after the entry of a PIN or with a continuous display of the next OTP (ie no PIN required). For example; a hardware token with a display screen, either with or without a keypad. Those with a keypad are two-factor devices (‘have’ the device and ‘know’ the PIN), whereas those without a keypad are really only a single-factor device. For the latter to become a two-factor solution a PIN/Password can be keyed into the PC along with the OTP during the logon process. Some would argue that constant-display tokens are still only a ‘single-factor’ solution because two passwords are needed (both ‘know’) for authentication (and only one password is needed in the case of a stolen or found OTP constant-display token).

Other methods of generating the OTP are possible, such as where the PIN entered into the token is combined with the token’s code to create a single pass-code (this method is prone to user error, as the PIN is not checked by the token, only by the OTP server). Another method consists of the OTP being distributed by the server (eg to a mobile phone or PDA) and then returned to the server in an authentication session within the allowed timeframe – this method should use digital signing of the distribution of the message, for enhanced security.

'One-time Pads' require that both parties have an identical list of pairs of numbers, words, or symbols, preferrably randomly generated. Once a choice has been used, it is crossed off the list and never used again. This method can also be used for "shared secrets" - see Secret Q&A.

63. Owner – The registered Entity for an Identity. An Entity owns an Identity (and therefore its access rights) due solely to the ability to authenticate it. See Registration.

64. Password – A credential, something only you know and that the authenticator can conirm. Also see OTP and Secret Q&A.

65. People Service – A web-services framework by which one identity can track the other identities it ‘knows’, via entries in its list, typically to manage their accesses to its resources. For example; the Liberty Alliance ID-WSF People Service (PS) is a “federated social identity”.

66. Permissions – The profile, or Entitlements, or combined Authorisation rights and Access Levels, of an Enrolment or a Role.

67. Persona – a super-identity or ‘avatar’ of an entity; a persona may be the result of federating several existing identities. Literally means "mask" (greek). The result is intended to convey a special purpose or role, such as the incarnation of a higher being. See Identity.

68. PKI – The infrastructure needed to support the use of Digital Certificates. It includes Registration Authorities, Certificate Authorities, relying parties, servers, PKCS and OCSP protocols, validation services, revocation lists. Uses include secure e-mail, file transfer, document management services, remote access, web-based transactions, services, non-repudiation, wireless networks and virtual private networks, corporate networks, encryption, and e-commerce.

69. PKCS – A set of Public Key Cryptographic Standards. It usually forms part of other security standards.

70. Plastic Card – A standard-sized card token. It may also have a credential such as a serial number, photo and other information printed on it. It may have embossed information. It may have a tamper-resistant lamination, including a logo or a watermark or other holographic images. It may also have a magnetic stripe with credentials recorded on it. For example, a club membership card, a Credit/ATM card. Also see Smart Card.

71. Platform – A class of infrastructure. For example; Mainframe, Mid-range, Desktop, LAN.

72. Policy – A set of Rules, usually associated with a Role or other dynamic attributes. It is normally used for access provisioning and access reconciliation.

73. Portal – A personalisable, dynamic web-page based service. Usually the main or ‘home’ page of a web site.

74. Privacy – a right to control the dissemination of the attributes of an entity. Attributes can be given up, after which it is dificult to restrict their use in the absence of any specific legal remedy. Some would argue that there is no privacy other than that artificially created by legislature. See Anonymity, Pseudonym and Registration.

75. Provisioning – This is automatically providing an Identity with access to a role, resource or service, or automatically changing or removing that access, based on the life cycle of events or work requests or changed attributes. For example; the first-day, second-day, on-going provisioning and last-day deprovisioning of the access rights of an employee.

76. Public/Private Key Cryptography – A mechanism of encrypting and decrypting data using two different but related keys - hence they are termed asymmetric. While the two keys are related, one cannot be computed from the other. Something encrypted with one key can only be decrypted with the other. One key is kept secret - the private key - and the other can be given to anyone - the public key. With this system, any two people can communicate securely after exchanging their public keys. Each recipient uses the corresponding private key to decrypt the session key.
In a symmetric system the keys used to encrypt and decrypt are very closely related and this ‘relationship’ is then shared between two parties, or there may only be a single key – hence they are termed symmetric.
In a hybrid system, a much briefer session key may generated by one party and encrypted by each recipient's public key; each recipient uses the corresponding private key to decrypt the session key and once all parties have obtained the single shared key that was encrypted by each recipient’s public key, they can use a much faster temporary symmetric algorithm to encrypt and decrypt messages.
Digital signatures can be susceptible to a “birthday attack”, as follows. A message m is typically signed by computing f(m), where f is a cryptographic hash function, and then using some secret key to sign it. To trick an identity Y into signing a fraudulent contract, the originator X prepares both a fair contract m and a fraudulent one m'. X then finds a number of positions where m can be changed without changing the meaning, such as inserting commas, empty lines, one versus two spaces after a sentence, replacing synonyms, etc. By combining these changes, X can create a huge number of variations on m which are all fair contracts. In a similar manner, X also creates a huge number of variations on the fraudulent contract m'. X then applies the hash function to all these variations until a version of the fair contract and a version of the fraudulent contract is found to have the same hash value, or f(m) = f(m'). X then presents the fair version to Y for signing. After Y has signed, X takes the signature and attaches it to the fraudulent contract; this signature then "proves" that Y signed the fraudulent contract. To avoid this attack, the output length of the hash function used for a signature scheme can be chosen large enough so that the birthday attack becomes computationally infeasible, i.e. about twice as large as needed to prevent an ordinary brute-force attack. It has also been recommended that Y cosmetically modify any contract presented to him before signing; however, this may not solve the problem, because now X may suspect Y of attempting to use a birthday attack.

77. Pseudonym – A fictitious identity that an Entity creates for itself, whereby the Entity can remain pseudonymous, or prehaps even fully anonymous, in certain contexts. Literally means "false name". It may be persistent or temporary. But it must be “persistent” if you will want to reuse it; this makes it difficult to remain fully anonymous because any details provided or collected over time may be joined with other details and republished (unless there are privacy laws preventing it). Also see Anonymity.

78. Re-authentication – The same authentication is resubmitted by the known Identity, in order to “commit” a transaction that has been fully prepared during the session under the same assurance strength (this is deemed to be further protection from “session hijacking”). Alternately, the re-authentication may be required to ‘step up’ the assurance strength, so as to enact a transaction that requires higher security (such as two or three factors).

79. Registration – The process of an entity (re)establishing an Identity with a service provider. For example; a bank’s 100-point check, an employment background check, an RA process for generating a Digital Certificate. Usually results in the issuing of a Credential that is associated with the Identity. Registration strength also has a ‘time value’, in that recent registrations may provide a greater assurance than old registrations (re-registration will uncover any errors, expiries and changes). Not to be confused with the ‘registration’ of a device – see Device ID.

80. Registration Authority – RA – The party that verifies identities using an agreed registration strength model and process, and may also advise a CA (Certificate Authority) to issue a digital document confirming the identity. Also see Digital Certificate.

81. Relying Party – The entity that relies on the result of an authentication. Usually, but not always, the same as the authenticating party and service provider.

82. Repository – A digital store, usually an LDAP directory or a relational database.

83. Revalidation – The periodic automated reassessment of existing access privileges to establish that security policy is being complied with, usually by workflows to the persons or roles responsible for the original approvals. Access may be reviewed down to the individual menu or transaction level within an application; especially for internal staff and outsourced management. Revalidation is an essential part of IAM solutions, increasingly required by corporate governance regulations (eg SOX). Note that some proprietary solutions (eg IBM TIM) do continuous reconciliation of entitlements within rules (using policy), thereby making this periodic revalidation redundant. Also see Attestation.

84. RFID – Radio Frequency IDentification – The use of radio waves to transfer data wirelessly between a transponder (such as a plastic card) and a transceiver, for contactless access like ‘proximity’ door-access cards, supply-chain tracking tags, shipping containers, luggage tags, livestock, motorway toll collections, an so on. Passing the aerial in the card though a magnetic field can generate an electrical current with sufficient power for the chip to transmit a fixed message a short distance. Some cards have an active emitter that uses an internal power supply and can transmit signals up to 100 metres. These transmissions can (and should) be encrypted, but this adds to the cost of a card (up from about $1, to over $5).

85. Risk – A measure of the (potential) impact that may be caused by the failure of an activity. By identifying the ‘primary risk’ and its probability of occurring, then by proper planning it may be mitigated into a ‘residual risk’ that can be more easily managed if it should occur. Also see Trust and Assurance.

86. Role – The dynamic or logical associations, privileges or capabilities applying to multiple Identities, based on a set of one or more current Attributes. A role may have multiple identities, and an identity may have multiple roles.

87. Role Based Access Control – RBAC – This reduces the complexity and cost of security administration in large networked applications by grouping accesses into functional roles. A Role is a common purpose of a group of users. Within an organization, roles are created for various job functions, usually based on attributes (static job role or dynamic functional role) that are the by-product of normal business. For example; a role such as a Bank Teller or a Manager. The permission to perform certain operations are assigned to specific roles. Management of individual user rights becomes a simple matter of assigning the appropriate roles to the user. Identities are assigned particular roles, and thus acquire the permissions to perform particular application functions. An identity can have multiple roles; a role can have multiple identities; a role can have many permissions; a permission can be assigned to many roles. RBAC reduces the complexity and cost of security administration by grouping accesses into separable functional roles and discretionary rights. ANSI/INCITS 359-2004 is the fundamental RBAC standard and XACML is the access-control mark-up language standard.

Roles are actually pre-packaged resources and services. If the role names (or descriptions) are based on one or more attributes directly related to the roles of an identity (e.g. a position title, location, function) it will enable dynamic role provisioning as a by-product of existing business processes - for example day-1 provisioning of a new employee. If a role is not based on identity attributes it is a static role that is provisioned on a discretionary basis (i.e. an identity must request them on day-2). Also see Access Control.

88. Rule – The implementation of a decision that determines the Permissions of a Group, a Role or an identity whose access is based on particular attributes.

89. Same Sign-on – The process whereby infrastructure presents the same authentication credentials (or some other predetermined information or token) to a subsequent application, without the user re-entering it, or even being aware of it. This enables those third-party packaged applications that have their own built-in authentication that is not able to be detached, to behave as though they are participating in a Single Sign-on solution.

90. Self Signed Certificate – A digital certificate where the issuer and subject are the same. There is no way to verify the certificate except by checking it against itself; it must be manually configured.

91. Separation of Duties – Mutually exclusive acccess or roles. This involves dividing responsibility for sensitive information or risky actions so that no individual acting alone can compromise a system. As a security principle, it has as its primary objective the prevention of fraud and errors. This principle is demonstrated in the occasional requirement for two signatures on a bank cheque, or by preventing a person from authorising their own workflow requests.

92. Session – A single Identity authentication period and its associated activity (temporary, non-persistent). Usually from logon until logoff or time-out, sustained with a local session cookie.

93. Session Hijack –session piggyback – This is where an unknown identity acts to take over a legitimate on-line session after the known identity has successfully authenticated. It can be thwarted by good application design. See Re-authentication.

94. Secret Q&A – An identity credential; previously stored personal questions and answers. Also known as Challenge/Response. It can be used for stronger authentication (as additional passwords) or for password resets (if forgotten). For example; mothers maiden name, name of your first pet, favourite football team, preferred cuisine. It must be stored encrypted. It may be compromised by social engineering and multiple attempts. Not to be confused with shared information (such as date of birth, last payment amount, last document reference number) which is not encrypted and is known to the service provider and anyone on their help desk; these are not secret although they are sometimes called by the misnomer “shared secrets”.

95. Single Sign-On - once-only assertion / authentication per session, per credential. Also see Same Sign-on, and Federation.

96. Single-Use Password – A password that can only be used once, in sequence from a list, with no time-based limitations. Also known as Sequence Synchronisation. For example; a code printed on a ‘scratchie’, as a password or for ticket validation. An initial password on a new account would also qualify. Also see OTP (One-Time Password).

97. Smart Card – A plastic card that contains a small computer chip. It may be contactless (RF), may have a visible computer chip (contacts), a magnetic stripe and/or a bar-code, to electronically store and process credentials. It may also have a photo on it and/or in it,and other printed information on it. It may be used for personal identification, physical access to facilities such as buildings and/or logical access to applications. The inclusion of all three aspects (ID, physical and logical access) in the one token is a convenience for issuing and management, but it is an inconvenience to the Identity if lost or misplaced and thus it may represent a greater overall security risk.

98. Soft Certificate – a digital certificate where the private key is created in such a manner that it can be easily copied or shared. This makes it insecure. Also see Hard Certificate.

99. Spoof – the process of faking or attacking a credential; to reproduce a credential without proper authority.

100. SSL – Secure Socket Layer protocol. The SSL protocol uses private and public keys to authenticate a service provider's web server to the browser. The protocol also creates encryption keys to protect the integrity and confidentiality of information at it traverses the Internet. The server generates a short-term public/private key pair using a long term private key belonging to the server. The server periodically changes its short term private key, discarding any previous versions and the client uses the short-term public key to encrypt a symmetric key for use during the session. This renders records of previous sessions un-decryptable. Sometimes referred to as providing "perfect forward secrecy". A Hardware Security Module (HSM) is often used both to securely store the private keys and to accelerate the encryption-decryption process.

Standards include ISO 11770 (guidelines for key management), ISO 9564 and ISO 16609 (retail financial transactions for PIN encipherment and message authentication, respectively). ISO 1568 (management of keys used in the retail banking environment - interfaces between a card-accepting device, acquirer, card issuer and a key-holding device).

See PKI.

101. Step Up Authentication – To transact at a higher assurance level during an already authenticated session may require a stronger credential; that is, to step up the credential strength by submitting an additional or stronger credential. It is a design decision that favours ease of user access over strongest possible authentication at initial logon time.

102. Token – A thing, a device, a physical item or software used to store attributes and credentials. Sometimes incorrectly used to describe the credential itself. For example; a drivers licence, a birth certificate, a door key, a scratchie, a plastic card, a smart-card, a OTP calculator, a digital certificate, a mobile phone or PDA.

103. Trust – an instance of a relationship between two or more entities, in which an entity assumes that another entity will act as authorised/expected. The risk/trust relationship depends on who you are and what you want to do at any instance. The degrees of separation between parties can decrease the trust (increase the risk). They trust you, so I (kinda) trust you (for now) to do (only) this. Also see Assurance Framework.

104. Trusted Source – A repository of identity information that can be relied upon for its accuracy due to the processes and security surrounding its creation and maintenance.

105. User – An Identity where the identifier of the identity is the public part of a paired Identity assertion. A user may have several identities / usernames / user-ids / logon-ids / sign-ons. See Identity and Authentication.

106. Verification – The process of confirming a claimed Identity. For example; any one-to-one precise matching of an identity’s registered credentials, such as in a logon or any non-AFIS process. Usually performed in real-time, with a yes/no outcome. Contrasts with Identification.

107. Web Service – A standard means of web-based application to application communication, running on a variety of platforms and/or frameworks, sharing metadata, often publicly available to calling software. WS-Policy describes the capabilities and requirements, WS-Transfer describes the end-point resources, WSDL describes the messaging, WS-Security and WS-Trust describe how to protect the communications, XML schema describes the contents, SOAP (protocol) describes the use of XML and HTTP as a messaging protocol.

108. Workflow – The automated routing of tasks associated with one or more business processes, or the whole lifecycle. For example; when an employee requests access to a resource or service an approval task is sent to that person’s line manager; if approved, an authorisation request is sent to the resource owner; if authorised, a provisioning task is sent to the resource manager who organises the access and advises the relevant parties. Tracking of progress, need for justification, and rerouting based on business rules and elapsed time, may be included as options in workflow diagrams. The workflow may be initiated by the individual, or others such as the line manager, but it usually cannot be approved by the requester (separation of duties). If the person’s functional role changes, a revalidation of the person’s access profile may be initiated automatically and routed to the new line manager. Also see Provisioning and Revalidation.

===================