Overview [1]#
Claim is an assertion made by a Entity that the one or more values of one or more Attributes of a Digital Identity (or Identity Document) which may be disputed or in doubt.Only by use of Trust can a Claim be assumed to be True as Authentication would be done by an Identity Provider (IDP) or a Verifier which involves Trust.
Using the JWT Claims Set is one method where Claims also solve the concern of data being added in transit. Because the information encoded and Digitally Signed by the Issuing Authority, nothing is added in transit unless the Issuing Authority is involved – in this way, the source of data can be directly controlled.
Verifiable Claims and Verified Claims are another method.
We can for our purposes use Claim the same as we would use assertion in regards to Authentication
Verified Claims are a fix because they don’t simply tell you something about the subject; they give you context and the ability to verify that information. Verifiable Claims There are two core types of attributes that a claim can reference:
- Contextual Attributes tell us about the situation when a token is issued
- Subject Attributes tell us about the thing that received the token
Examples #
Examples of the kinds of Identity Attributes that might be conveyed in a Claim:- A Claim could just convey an identifier—for example:
- that the digital subject's student number is 490-525
- that the digital subject's Windows name is REDMOND \ kcameron.
- A Claim may make an assertion that a Digital Subject knows a given key and should be able to demonstrate this fact.
- A Claim might convey Personally Identifiable Information for example:
- name
- address
- date of birth
- citizenship
- A Claim might simply propose that a Digital Subject is part of a certain group — for example, that she has an age less than 16.
- A Claim might state that a Digital Subject has a certain Authorization — for example, to place orders up to a certain limit, or modify a given file.
Comment1: Claims may or may not be directed to specific Parties (aud). (KimC, DickH, PaulT)
Comment2: A Claim is an association between a Claimant, a Digital Identity, and an Identity Attribute (PaulT)
Here is an OAuth 2.0 example: "Curity states that the Resource Owner has this list of attributes."
| Asserting Party | Subject | Claims |
|---|---|---|
| Curity | Resource Owner | Attributes |
In OAuth 2.0 Claim might and often are mapped to a OAuth Scopes (scope of access).
verified_claims#
verified_claims are an extension to OpenID Connect to ensure that Relying Partys cannot mix up verified and unverified Claims and incidentally process unverified Claims as verified Claims.verified_claims are defined as Claims about an End-User, typical a Natural Person, where those Claims were Bound to a particular Digital Identity in the course of an Identity Verification process.
OpenID Connect Standard Claims#
The OpenID Connect Standard Claims specification only defines a single set of standard OAuth Scopes defines the Access Request for the Claim:
| Scope | Claims |
|---|---|
| email, email_verified | |
| address | address |
| profile | name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at |
| phone | phone_number, phone_number_verified |
| openid | sub, auth_time, acr |
Verifiable Claim#
Verifiable Claim is an assertion made by a Third-party about a subject which is tamper-proof and whose authorship can be cryptographically verified. Multiple claims may be bundled together into a set of claims.More Information#
There might be more information for this subject on one of the following:- Access Token Validation
- Assertion
- Aud
- Authentication
- Authentication Context Class
- Authentication Method Reference
- Authentication Method Reference Values
- Authentication Request
- Authenticator
- Authenticator Assurance Levels
- Authorized party
- Backchannel_logout_session_required
- Backchannel_logout_session_supported
- CBOR Web Token
- Claim
- Claim_token
- Claimant
- Contextual Attributes
- Credential
- Credential Holder
- Credential Service Provider
- DID Document
- Data Ownership
- Default Profile Claims
- Default_acr_values
- DefinitionTokenService
- Derived Credential
- Digital Context
- Digital Identity
- Digital Signature Algorithm
- Dynamic Access Control
- Essential Claim
- Exp
- Frontchannel_logout_session_supported
- Geneva Framework
- Glossary Of LDAP And Directory Terminology
- Holder
- Hosted domain
- Hyperledger Indy
- Iat
- Identifier registry
- Identity Assurance
- Identity Proofing
- Identity Token
- Identity Token Claims
- Identity Token Validation
- Identity Verification
- JSON Web Token Best Current Practices
- JSON Web Tokens
- JSON-LD Examples
- Javascript Object Signing and Encryption
- LOA 1
- Law of Minimal Disclosure For A Constrained Use
- Level Of Assurance
- Logout Token
- OAuth 2.0 Token Exchange
- OAuth Scope Validation
- OAuth Scopes
- OpenID Connect Authentication Response
- OpenID Connect Back-Channel Logout
- OpenID Connect Claims
- OpenID Connect Federation
- OpenID Connect Scopes
- OpenID Connect for Identity Assurance
- Openid-configuration
- PCT
- Persisted Claims Token
- Primary Refresh Token
- Prompt Parameter
- Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
- Provenance
- Public Claim Names
- Reserved Claim Name
- Right to be forgotten
- SAML
- Scopes vs Claims
- Security Event Token
- Security Token Service
- Self-Issued OpenID Provider
- Self-Sovereign Identity
- Sub
- Subject Attributes
- Ten Principles of Self-Sovereign Identity
- Token
- U-Prove
- User Provisioning
- UserInfo Request
- UserInfo Response
- Verifiable Claims
- Verification
- Verified Claim
- Verified_claims
- Verifier
- Why Use Tokens
- [#1] - Claim
- based on information obtained 2003?
- [#2] - Identity and APIs - based on information obtained 2020-11-03
- [#3] - Introduction to Claims - based on information obtained 2022-05-27
- [#4] - Claims Best Practices - based on information obtained 2022-05-27
- [#5] - OIDC Standard Claims - based on information obtained 2020-05-27