Additional Information

Claim	Support	Example	Description	Comment	Editorial comment
sub		9578-5999-4-1765512	Subject Identifier
name		Nilsen, Frode Beckmann	Full name
given_name		Frode Beckmann	Given name (first name)
family_name		Nilsen	Surname (last name)
middle_name			Middle Name		Must be added
nickname			Casual name
preferred_username		Nilsen, Frode Beckmann	Shorthand name		Must be reviewed
profile			Profile page URL
picture			Picture URL
website			Homepage URL
email			Preferred email		Must be added
email_verified			Email verification status		Must be added
gender			Gender		Must be added
birthdate		1966-12-18	Birthdate
zoneinfo			Time zone
locale			Locale
phone_number		95871775	Preferred phone numer
phone_number_verified		false	Phone number verification status
address		{ "formatted": "Lybekkveien 11C\n0772 Oslo\nNorway", "country": "Norway", "street_address": "Lybekkveien 11C", "postal_code": "0772", "locality": "Oslo", "house_number": "11", "house_letter": "C", "street_name": "Lybekkveien" }	Postal address
all_phone_numbers		{"number":"95871775","number_verified":false},{"number":"46897469","number_verified":false},{"number":"94782958","number_verified":false}

---

BankID OIDC also integrates with a service to provide additional information like private address and phone number for the end-user being authenticated.

ontains a consent dialog allowing the user to accept or deny use of any additional information the BankID OIDC Service may provide. 

Characteristics of BankID OIDC access_tokens

Resources managed/authorized by the BankID OIDC Service get a “public” access_token (“one access_token to rule them all”). When an OIDC Client uses scope (or default scope) to define what resources it needs authorization for, the issued access_token can be used for all those resources. The resources must call the introspect endpoint in order to verify that it is the correct audience/resource for this access_token as well as getting returned the access_token contents/claims. Resources are expected to cache/cookie this information so there’s no need to call introspect for every incoming request with the same access_token.

The introspect endpoint demands basic authentication with the resource’s client_id and client_secret so that it knows what resource it is dealing with. 

Another policy is to have “private” access_tokens. That means each resource has their own access_token issued and encrypted with their client_secret/resource_secret. This would remove the need to call introspect in order to validate and get claims, but it will be difficult for the client to keep track of all the access_tokens issued to individual resource services. AAD is doing this and using the refresh_token to ask for more scope (new resources). This would work as long as the refresh_token is issued for the same resource owner (end-user).

"Private access_tokens" are currently not supported. Refresh_tokens are also not implemented. The rationale is that the supported “public” implementation is considered to more efficient (provided the caching we mentioned).