Claim Catalog
From wiki.informationcard.net
This page is a catalog of ICF-defined and other well-known claim type URIs. By creating this central repository, we seek to increase interoperability of Information Cards between issuers and relying parties. This page is an official output of the ICF's Schemas WG.
Contents |
New Requests
The following requests failed to get the votes needed (see Adding to the Claim Catalog)
| Claim-Name | Data Type | Value Range | Description | Status | URI | Rationale (i.e. Why now?) |
|---|
Notes:
ICF-Defined Claims
The Claim-Name is appended to the base URI , http://schemas.informationcard.net/@ics, along with a date segment to form the full claim URI as defined in Claim URI Syntax.
2009
| Claim-Name | Data Type | Value Range | Description | Status | URI |
|---|---|---|---|---|---|
| icam-assurance-level-1 | xs:string | unspecified | A claim that the security token is issued according to the requirements of the U.S. federal Identity Credential and Access Management (ICAM) Assurance Level 1 by an identity provider certified to do so. | Approved | http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06 |
| icam-assurance-level-2 | xs:string | unspecified | As above but level 2. | Approved | http://schemas.informationcard.net/@ics/icam-assurance-level-2/2009-06 |
| icam-assurance-level-3 | xs:string | unspecified | As above but level 3. | Approved | http://schemas.informationcard.net/@ics/icam-assurance-level-3/2009-06 |
| password | xs:string | unspecified | The password of the user on a target website or application. This claim MAY be used in conjunction with the username claim. Together the values of the username and password (un/pw) claims might be used to an Information Card compatible RP site or service that in turn conveys the un/pw values to the target website or app. These claims MUST only be implemented and supported by selectors and/or IdPs that include logic[1] to prevent phishing attacks.[2] | Provisional | http://schemas.informationcard.net/@ics/password/2009-03 |
| username | xs:string | unspecified | The username of the user on a target website or application. This claim is used in conjunction with the password claim. See the password claim for details. | Provisional | http://schemas.informationcard.net/@ics/username/2009-03 |
| resource-udr | xs:string | A resource UDR (Uniform Data Reference - previously called a resource UDI as defined in UDI Syntax) | A reference to a source of attribute data. This claim is used to pass a reference to an RP so that the RP can resolve the UDR and extract additional information about the subject. Used by Higgins relationship cards. | Provisional | http://schemas.informationcard.net/@ics/resource-udr/2009-03 |
| age-21-or-over | xs:token | tri-boolean | True if the subject is 21 or over years of age. | Approved | http://schemas.informationcard.net/@ics/age-21-or-over/2008-12 |
| us-resident | xs:token | tri-boolean | True if the subject is a resident of the United States. | Provisional | http://schemas.informationcard.net/@ics/us-resident/2008-12 |
Notes:
- ↑ As an example of this logic for use with personal cards: the selector’s self-issued STS must have a whitelist that is exactly one entry in length; the selector user will explicitly permission one special RP (e.g. the browser password manager) as this one and only whitelisted RP; and the selector will only release un/pw claim values to this RP.
- ↑ One example of use is a RP that validates the security token from the selector, extracts the un/pw values and uses them to authenticate the user to the "target" site or app. A second example of use is an RP application located within the user's browser that validates the security token, extracts the value and uses HTML form fill to authenticate the user to the site.
2008
| Claim-Name | Data Type | Value Range | Description | Status | URI |
|---|---|---|---|---|---|
| verification-method | xs:string | URI | The verification method claim provides a URI representing the verification method employed for verifying the verified claims enumerated in the verified-claims/2008-11 claim. The claim value may utilize any of the verification method URIs defined at Verification Methods. Other URI values may also be defined and used. | Approved | http://schemas.informationcard.net/@ics/verification-method/2008-12 |
| coppa-certified-adult | xs:token | tri-boolean | True if the subject is a COPPA-certified adult who has been verified using one of the COPPA-specified methods. Some of these methods are documented in the COPPA Rules, which can be found at http://www.ftc.gov/os/1999/10/64fr59888.pdf. | Approved | http://schemas.informationcard.net/@ics/coppa-certified-adult/2008-12 |
| us-registered-voter | xs:token | tri-boolean | True if the subject is a registered voter in the United States. | Provisional | http://schemas.informationcard.net/@ics/us-registered-voter/2008-12 |
| age-18-or-over | xs:token | tri-boolean | True if the subject is 18 or over years of age. | Approved | http://schemas.informationcard.net/@ics/age-18-or-over/2008-11 |
| verified-claims | xs:string | A possibly empty space-separated list of URIs | A list of the other claims contained in the token that the Identity Provider asserts that it has verified. This enables a token to convey both verified and unverified claims and for the Relying Party to know which of the claims are verified. (The absence of this claim within a token conveys no information about the token and its absence should not be interpreted otherwise; only the presence of this claim conveys information from the Identity Provider about the claims in the token.) | Approved | http://schemas.informationcard.net/@ics/verified-claims/2008-11 |
Well Known Claims
http://schemas.xmlsoap.org/ws/2005/05/identity/claims
The above base URI as well as the following claim names have been defined in ISIP 1.5. The claim names are appended to the above base XML namespace URI to form the complete claim type URI (as shown in the right-most column):
| Claim name | Data Type | Description | URI |
|---|---|---|---|
| givenname | xs:string | (givenName in RFC 2256) Preferred name or first name of a subject. According to RFC 2256: “This attribute is used to hold the part of a person’s name which is not their surname nor middle name.” | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname |
| surname | xs:string | (sn in RFC 2256) Surname or family name of a subject. According to RFC 2256: “This is the X.500 surname attribute which contains the family name of a person.” | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
| emailaddress | xs:string | (mail in inetOrgPerson) Preferred address for the “To:” field of email to be sent to the subject, usually of the form @. According to inetOrgPerson using RFC 1274: “This attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822.” | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
| streetaddress | xs:string | (street in RFC 2256) Street address component of a subject's address information. According to RFC 2256: “This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery.” Its content is arbitrary, but typically given as a PO Box number or apartment/house number followed by a street name, e.g. 303 Mulberry St. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress |
| locality | xs:string | (l in RFC 2256) Locality component of a subject?s address information. According to RFC 2256: “This attribute contains the name of a locality, such as a city, county or other geographic region.” e.g. Redmond. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality |
| stateorprovince | xs:string | (st in RFC 2256) Abbreviation for state or province name of a subject's address information. According to RFC 2256: “This attribute contains the full name of a state or province. The values should be coordinated on a national level and if well-known shortcuts exist - like the two-letter state abbreviations in the US – these abbreviations are preferred over longer full names.” e.g. WA. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince |
| postalcode | xs:string | (postalCode in X.500) Postal code or zip code component of a subject's address information. According to X.500(2001): “The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object’s postal address - zip code in USA, postal code for other countries.” | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode |
| country | xs:string | (c in RFC 2256) Country of a subject. According to RFC 2256: “This attribute contains a two-letter ISO 3166 country code.” | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country |
| homephone | xs:string | (homePhone in inetOrgPerson) Primary or home telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a home telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone |
| otherphone | xs:string | (telephoneNumber in X.500 Person) Secondary or work telephone number of a subject. According to X.500(2001): “This attribute type specifies an office/campus telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone |
| mobilephone | xs:string | (mobile in inetOrgPerson) Mobile telephone number of a subject. According to inetOrgPerson using RFC 1274: “This attribute type specifies a mobile telephone number associated with a person.” Attribute values should follow the agreed format for international telephone numbers, e.g. +44 71 123 4567. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone |
| dateofbirth | xs:date | The date of birth of a subject in a form allowed by the xs:date data type. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth |
| gender | xs:token | Gender of a subject that can have any of these exact string values –
|
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender |
| privatepersonalidentifier | xs:base64binary | A private personal identifier (PPID) that identifies the subject to a relying party. The word “private” is used in the sense that the subject identifier is specific to a given relying party and hence private to that relying party. A subject?s PPID at one relying party cannot be correlated with the subject?s PPID at another relying party… | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier |
| webpage | xs:string | The Web page of a subject expressed as a URL. | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage |
Value Ranges
| Name | Value | Display Value (English) | Other languages (optional) |
|---|---|---|---|
| tri-boolean | |||
| 0 | False | ||
| 1 | True | ||
| 2 | Unknown | ||
Verification Methods
These URIs represent verification methods used to verify claims. Some of these methods are documented in the COPPA Rules, which can be found at http://www.ftc.gov/os/1999/10/64fr59888.pdf. These URIs are rooted at http://schemas.informationcard.net/@ics/verification-method/.
| Method Name/Year-Month | Description | Status | URI |
|---|---|---|---|
| ssn4/2008-12 | The last four digits of the user's social security number match the name provided. | Approved | http://schemas.informationcard.net/@ics/verification-method/ssn4/2008-12 |
| drivers-license/2008-12 | The driver’s license number of the user matches the name and date of birth provided. | Approved | http://schemas.informationcard.net/@ics/verification-method/drivers-license/2008-12 |
| credit-card/2008-12 | The credit card was successfully charged in conjunction with the registration process. | Approved | http://schemas.informationcard.net/@ics/verification-method/credit-card/2008-12 |
| email-verification-then-email/2008-12 | An email was sent to the user's email address and the user clicked on a link provided in the email to confirm his participation. A delayed confirmation email was later successfully delivered. | Approved | http://schemas.informationcard.net/@ics/verification-method/email-verification-then-email/2008-12 |
| email-verification-text-msg/2008-12 | A short code was sent to the user's email address and the user texted the code back to confirm. | Approved | http://schemas.informationcard.net/@ics/verification-method/email-verification-text-msg/2008-12 |
| email-verification-web-code/2008-12 | A short code was sent to the user's email address and the user returned to the website and entered the code online to confirm. | Approved | http://schemas.informationcard.net/@ics/verification-method/email-verification-web-code/2008-12 |
| postal-mail-text-msg/2008-12 | A short code was sent to the user via postal mail and the user texted the code back to confirm. | Approved | http://schemas.informationcard.net/@ics/verification-method/postal-mail-text-msg/2008-12 |
| postal-mail-web-code/2008-12 | A short code was sent to the user's postal mail address and the user returned to the website and entered the code online to confirm. | Approved | http://schemas.informationcard.net/@ics/verification-method/postal-mail-web-code/2008-12 |
| web-text-msg/2008-12 | A short code was provided to the user on screen and the user texted the code back to confirm. | Approved | http://schemas.informationcard.net/@ics/verification-method/web-text-msg/2008-12 |
