1. Laws for Secure Credentialing
Gilles Lisimaque
Steve Howard Dave Auman

2. The Laws of Identity User Control and Consent
Minimal Disclosure for a Constrained Use
Justifiable Parties
Directed Identity
Pluralism of Operators and Technologies
Human Integration
Consistent Experience Across Contexts
Source: “The Laws of Identity”, Kim Cameron, Architect of Identity, Microsoft Corporation

3. How does this apply to smart tokens
The credential should never be used without implicit or explicit user’s consent
The credential should reveal only the minimum information required for a given interaction
All parties involved should be authenticated
Entities interacting with a smart token should be able to prove the capacity in which they are acting
There will always be multiple technologies as well as multiple identity issuing authorities involved
The rules of the game should be understandable by humans
Identity systems should be designed with coherence and appear consistent for all users

4. Definitions (1/2)
Subject is a person, system or object with associated attributes
Attribute is a quality or characteristic inherent in or ascribed to a subject
Claim is an assertion by a subject about the value of an attribute
Vetting is the process of inspection and adjudication of claims
An Identity is an association between vetted claims and a subject, certified by a trusted authority
A Credential is a physical or logical representation of an identity or privilege issued by an authority

5. Definitions (2/2)
Identity Authority is a trusted authority able to do the vetting of a subject’s claims
Application Authority defines the rules of the application and attribute disclosure required from a subject to be disclosed in order to provide the service which may be delegated to a service provider
A Challenge is the demand for disclosure of one or more attributes related to a subject made by a service authority
Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be.
A Privilege is an authorization granted by an application authority for a subject to perform an action

6. Identity & Privilege Relationship
Authority
Transfer
Trust
Establish
Trust An
ID card
asserts the
identity of the
legitimate
cardholder,
but may not grant explicit
privilege
Link at
privilege granting
Link at enrollment and vetting
Identity Assertion
Attribute Certification
Application
Authority
Person/Subject
Subject Verification
Link at use

7. Identity or Privilege credential?
The privilege (or service access) may be linked to
An attribute, part of an identity, which may not be linked to a given subject (e.g. whoever uses my EzPass, it will work)
The biometrics of a given subject without any other attributes being required ( Registered Traveler)
Or a bit of both when a credential is used by another application than the one it was created for
In either case, any number identifying the user for this privilege (becomes an attribute) should change with the credential and never be permanent for the user

8. Consequences for Smart ID Tokens
A Smart ID Token should never reveal any user attribute to a client application which has not been authenticated
A Smart ID Token should always protect the confidentiality of any user attribute (including token identifiers)
A Smart ID Token should restrict disclosure of user’s attributes according to the application authority of the requestor
Before taking any action on the behalf of its legitimate user a Smart ID Token should always have the user authenticated
A Smart ID Token should keep a log, available to its legitimate user, of all interactions

9. Thanks you for your attention
Gilles Lisimaque
Stephen Howard
Dave Auman