From MgmtWiki
Revision as of 12:53, 21 February 2022 by Tom (talk | contribs) (Solution)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Full Title or Meme

A statement by or about a Subject is a Claim. If there is some corroboration of the claim, it is called a Validated or Verified Claim.

A collection of Attributes and other information about a user that are used in Authorization of access to a Resource.


  • The English word Claim means to call our for, or to publish, pretty much the same meaning as the Latin word clamare.[1]
  • Merriam Webster definitions
: a right to something
specifically : a title to a debt, privilege, or other thing in the possession of another
The bank has a claim on their house.
b: an assertion open to challenge
a claim of authenticity
advertisers' extravagant claims
  • The first evidence found so far of the use of the word Claim in an Identity context was in the 2003-10-08 Liberty ID-WSF Security and Privacy Overview. "A security token is a representation of security-related information that is used to represent and substantiate a claim." But in the case the claim appears be be a statement made by a claimant.
  • A claim made by an actor stating its identity. Without validation, no assumptions can be made regarding the actor’s identity. An Identity Claim is usually made by a User towards a Service Provider.
  • The JWT spec defines it as "A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value."
  • NIST - Claim = A true-false statement about the limitations on the values of an unambiguously defined property called the claim’s property; and limitations on the uncertainty of the property’s values falling within these limitations during the claim’s duration of applicability under stated conditions.
  • NIST [ - Claimant] = A party whose identity is to be verified using an authentication protocol. A subject whose identity is to be verified using one or more authentication protocols. The person who is asserting his or her identity
  • NIST - Credential (2. 2) Evidence attesting to one’s right to credit or authority. (1. 1). Evidence or testimonials that support a claim of identity or assertion of an attribute and usually are intended to be used more than once.
  • IETF RFC 7519 JSON Web Token (JWT) Claim = A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
  • OIDC Core first says that the definition is taken from RFC 7519 and then says a few different things, none of which agrees with the other.
    • Claim = (section 1.2) Piece of information asserted about an Entity.
    • (section 1.3) The UserInfo Endpoint returns Claims about the End-User
    • (section 2) The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server (for example the auth_time and nonce claims)
    • (Section 5) Claims about the End-User and the Authentication event.
  • OIDC Credential = Data presented as evidence of the right to use an identity or other resources. (This applies only to clients' creds sent the OP and access tokens in the doc.)
  • IdM Glossary of Terms: (
    • Claim (Assertion) is a statement of the value of one or more identity attributes; e.g. if Ben is currently a CIT freshman, the Identity Management system could create a credential containing the claim: “Ben’s affiliation is student”.
    • Credential is an object that is verified when presented during an authentication transaction. Credentials consist of one or two elements:
  1. Identity Attributes (required): most often just a single identifier (e.g. username) associated with the entity being authenticated. However, in many circumstances, other identity attributes may be required (e.g. assertion of a right to use license for a particular resource)
  2. Verifier (optional as part of the credential
  • claim = An assertion made about a subject.
  • The first patent that described the process of using a claim (authentication ticket) in an Authorization process (OAuth) appears to be: United States Patent 7,257,835 Thomas C. Jones August 14, 2007 Filed: May 28, 2003 Securely authorizing the performance of actions
Securely authorizing the performance of actions may be enabled by linking each secure/privileged action to a requisite policy for authorizing that secure/privileged action. In a described media implementation, one or more electronically-accessible media include electronically-executable instructions that, when executed, direct an electronic device to execute operations including: receiving an action performance request that is directed to a requested action; locating an authorization policy that is associated with the requested action from among multiple authorization policies, the authorization policy indicating how performance of the requested action can be authorized; and extracting at least one rule and one or more authentication ticket requirements from the authorization policy. Example operations may further include: determining whether one or more authentication tickets have been validated in accordance with the at least one rule and/or the one or more authentication ticket requirements; and if so, authorizing performance of the requested action.


There is a discrepancy in the way that claims were defined in OASIS SAML and internally inside Microsoft. Some of that can be seen in the following thread. Tony used to work in IBM before we ended up in Microsoft

To: Tony Nadellin;
something seems to be lost in the technical jargon.
In the definition i supplied we expect that claims will flow from the user agent to the rp.
Claims are what your own company calls the data blobs that flow to the rp (see below).
If the rp is happy, a transaction can continue.
if the rp is not happy, additional claims will be requested.
that is how the process works today. I suspect that is how it will happen in the future.
The rest seems to be a technical semantic of no value to any one other than a business owner/developer inside the the RP.
I would think that our job is to understand what input the user gets and how the user responds. Not the internals of the RP.   ..tom
When you build an application that relies on claims, you are building a relying party (RP) application. Synonyms for an RP include “claims aware application”
Subject: RE: [Userexp_wg] user vs principal
Date: Thu, 25 Oct 2012 15:00:09 +0000

What you describe is an assertion based decision as claims are always in doubt by definition 

Sent from my Windows Phone


Claims typically go through a series of steps, for example:

  1. A User will go to a Web Site hosting a Resource that the user wants to access.
  2. The Web Site will send a scope to a User asking for Claims to authorize access.
  3. The User Agent should know, a priori, where to send the Claims for verification.
  4. The Verified Claims will be collected and forwarded to the Web Site.
  5. The Web Site will evaluate the Verified Claims and determine whether to authorize access to the resource.
  6. Optionally the Web Site will request additional claims to meet the needs to authorize access.

  • In computer networking a variety of statements can be made by a user to acquire authorized access to a resource.
  • The distinction as to Authentication, who a user is, versus Authorization, or what that user is permitted to do, is no longer helpful.
  • NIST has recognized that there are multiple metrics for the quality of statements about a user in their third update to SP 800-63
  • Claims can be highly detailed, do to data fields, or a collection of fields, like the User address, this can be overwhelming if presented for User Consent. Some protocols, like OpenID Connect provide for aggregated collections of claims that OpenID calls Scope.[2]


  1. Walther W. Skeat, An Etymological Dictionary of the English Language. Oxford (1882)
  2. Nat Sakimura Scopes and Claims in OpenID Connect