Laws for secure credentialing
This presentation is the property of its rightful owner.
Sponsored Links
1 / 9

Laws for Secure Credentialing PowerPoint PPT Presentation


  • 75 Views
  • Uploaded on
  • Presentation posted in: General

Laws for Secure Credentialing. Gilles Lisimaque Steve Howard Dave Auman. 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

Download Presentation

Laws for Secure Credentialing

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Laws for secure credentialing

Laws for Secure Credentialing

Gilles Lisimaque

Steve HowardDave Auman


The laws of identity

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


How does this apply to smart tokens

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


Definitions 1 2

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


Definitions 2 2

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


Identity privilege relationship

Identity & Privilege Relationship

Identity

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


Identity or privilege credential

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


Consequences for smart id tokens

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


Thanks you for your attention

Thanks you for your attention

Gilles Lisimaque

[email protected]

Stephen Howard

[email protected]

Dave Auman

[email protected]

WWW.IDTP.COM


  • Login