Claims are name/value pairs that contain information about a user, as well meta-information about the OIDC service. The OIDC specification defines it as a “piece of information asserted about an Entity.”

Note: It is important to realize that different domains may have different business rules as to what extent the claims are valid and/or verified! These definitions are business rules from the Security Domain.

Example claim set

{
  "sub":"7a9cb1cf-c495-4db1-a25e-d24d84accc6d",
  "preferred_username": "user",
  "email": "user@foo.com",
  "name": "Firstname Lastname"
}

Claims can be returned in the ID Token and from the userinfo endpoint (and from the Claims directly (for by value tokens) or indirectly using the introspect endpoint).

It is configurable and dependent on the context and functional requirements where the different claims should be returned (The email claim may be available in the ID Token for some clients/in some contexts, but not in others). This is dependent of the policies defined in the Security Domain.

Hence: all claims are defined in context of a client (context and domain).

Standard claims

The OIDC specification defines a set of standard claims. Requesting for standard claims are done using the standard scopes (the scopes control the access privileges for what claims that should be returned).

Custom claims

Any custom claims and data may be added (as long as it is in accordance with the OIDC specification: Claims). The use of custom claims should considered controlled by custom scopes.

Note the recommendation from the OIDC specification stating that custom claim identifiers should be collision-resistant.

Buypass specific claims

Buypass will strive to use the standard claims (with values according to the definition) whenever possible. If, however, Buypass specific claims are needed, they will be named with prefix "bp_" (according to Private Claim Names).

In general, both the availability and inclusion of these claims depend on the scopes requested by the client and on the data available and policies for each Security Domain.

There might however be Buypass-claims included in the token as part of the basic claims (inclusion without explicit request form the client).

Note that all Buypass claims are context specific (even if some of them may appear in several contexts). Some of these custom claims may also be customer or client specific.

Claim	Scope	Description	Example
bp_id_sub	bpid	A Buypass ID. The Buypass alternative to the "sub" claim with a given format. The Buypass ID has a specific proprietary numeric format.	"bp_id_sub": "12345"
bp_nnin_sub	bpnnin	The Norwegian national identity number (NNIN) is a unique identifying number that you are assigned for life. It consists of 11 digits, of which the first six digits indicate the person's date of birth. Alternatively a D-number is a temporary identification number which can be assigned to foreign persons who'll generally be resident in Norway for less than six months.	"bp_nnin_sub": "31129956789"
bp_sub	openid	A Buypass specific alternative to the standard subject identifier. Note that in contrast to the "bp_id_sub", the format of this claim is open (can be any string in accordance with the standard sub claim). A locally unique and never reassigned identifier within the Issuer for the end-user. Intended to be consumed by the client as a possible end-user reference. NOTE: Even if the identifier is "never reassigned" it may still change for the same user! An user may be reassigned a new sub, but a used sub will never be assigned to a new user. Hence, do not use this as a user reference over time!	"bp_sub": "7a9cb1cf-c495-4db1-a25e-d24d84accc6d"
bp_x509certificate	bpx509certificate	Note that this claim is only available if a PKI certificate has been used for authentication. The X.509 certificated in PEM format used for authentication. Certificate information can be extracted using standardised methods, ex: Serial Number: Used to uniquely identify the certificate within a CA's systems. In particular this is used to track revocation information. Subject: The entity a certificate belongs to: a machine, an individual, or an organization. Issuer: The entity that verified the information and signed the certificate. Not Before: The earliest time and date on which the certificate is valid. Usually set to a few hours or days prior to the moment the certificate was issued, to avoid clock skew problems. Not After: The time and date past which the certificate is no longer valid. Key Usage: The valid cryptographic uses of the certificate's public key. Common values include digital signature validation, key encipherment, and certificate signing. Extended Key Usage: The applications in which the certificate may be used. Common values include TLS server authentication, email protection, and code signing. Public Key: A public key belonging to the certificate subject. Signature Algorithm: The algorithm used to sign the public key certificate. Signature: A signature of the certificate body by the issuer's private key.	"bp_x509certificate": " MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= "