1 / 9

Laws for Secure Credentialing

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

abie
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Laws for Secure Credentialing Gilles Lisimaque Steve HowardDave 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 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

  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 GLisimaque@IDTP.com Stephen Howard SteveHoward@idtp.com Dave Auman DAuman@idtp.com WWW.IDTP.COM

More Related