Where should Identity Live

Convener: Andrew Arnott

Note-taker: Hannes Tschofenig

Tags: Identity, IdP, service provider, token, assurance

Discussion notes:

Definitions

• Entity - A person or device that should be discernable from another.
• Identity - the minimal data necessary to discern between entities in a given context.

Terminology taken from ISO/IEC JTC 1/SC 27 N7751: 
entity: something that has a separate and distinct existence

identity:  total list of attribute values of an entity that allows this entity to be distinguished from other entities within a context and to be recognized in that specific context

some term needed for "context". 

What identity is not:

Membership: identity is not controlled by an organization, and cannot be revoked by an organization. Membership or authorization may be revoked by a controlling party, but that is not identity.

Authorization or (necessarily) access control: although an organization may control access to a resource, they do that by assigning or revoking privileges to an identity, and not by revoking privileges to assert that identity. Ideals in identity

Roamability of the client: (most) users MUST be able to log into (most) services from any geographic place and from any device.  An entity's possession is not always a requirement.

Portability of the IdP: The identity asserting service or device MUST be able to transfer that capability of assertion to another service or device.  Or Limited delegation of authority.

Rights of assertion: (some) users are willing to empower a trusted third party to assert their identity without aid of another party or device. Some services require multi-factor authentication. Some users will prefer to spread out rights of assertion, such that an IdP and a physical user token are required at the client in order to assert an identity at an RP. Perhaps users will fully empower one IdP, while only partially empowering another.

Multiple identities (persona): (some) users want or need to maintain multiple identities for individual services in order to avoid correlation or separate tasks.

Correlation of identities: some users want to correlate their identity across services. Some services want or need to correlate the identities of their users. Some users do not want services to be able to correlate their identity across services. Some sites MUST NOT be able to correlate their users' identities across services.

Phishing protection: identity SHOULD NOT be phishable. It's not that we mitigate against profitable phishing -- we make it impossible by using non-phishable credentials wherever possible. (non-correlatible)

Verifiable assertions: An identity assertion can be verified by a service without a need to trust the IdP that sent the assertion (the IdP may not be the signing entity), and possibly without a network connection. Checking various identity revocation lists, if supported by a particular service, would require at least periodic updating of a cached list or a network connection.

Non-collision of identities: an identity must be globally unique. Revokable only by entity: an identity, once created, can only be destroyed (or rather, the ability to assert that identity can only be destroyed), by the owning entity. The creator of an identity may also create a power of revocation that may be assigned to the entity, allowing the entity to terminate a compromised identity.

Temporary revocation: Some entities may lose control of their identities (lost cell phone) but later recover it. Non-transferrable: Roles are transferrable -- not identity. Identities MUST NOT be reassignable to others, especially by accident. (exception: perhaps an organization does not want to expose that a change in the person filling some role has taken place).

Non-enumerable: if a physical token maintains a user's identities and the services the user is a member of, physical access to that token should not enable someone to enumerate the services the user has come in contact with.

Non-repudiation: (some) services may need to be able to prove that an identity was asserted to it. (some) users may need to prove that they visited some service.

Level of assurance: Some services demand a certain level of assurance that an asserted identity is indeed originating from the owning entity. Practical details

Identity may have metadata (attributes) associated with it (i.e. membership, roles, authorization, signed claims). Services may store metadata about an identity within the service, or may publish metadata to a shared service for which access control may be set, perhaps with user consent.

These public identity-metadata correlation services may provide a service to search for identities with metadata that matches some criteria, thus allowing people to easily find identities based on traits known about a known entity.

Some services do not need identity at all, but only claims (membership, roles, or other metadata) signed by a trusted identity in order to provide services to other entities.

Risks

Denial of service: An evil entity that gains temporary control of an identity may obtain a revocation for that identity, which the evil entity may issue at a later date, after the identity's rightful entity regains control of that identity.

Denial of service: A disruption of a service's means to verify new identities.