OpenID Providerを作る）定義済み属性の値として何を返却すべきか

こんにちは、富士榮です。

前回はscopeの定義と返却すべき属性について整理をしました。

ちなみに仕様の5章に定義されているStandard ClaimsはIANAのレジストリに登録されているのでOpenID ProviderとRelying Partyの間で個別にフォーマットや値のすり合わせをしなくても良いように標準化されています。登録済みのClaimについては18章に記載されています。

ですので、OpenID Providerを作る時は、基本的にこのStandard Claimをサポートするようにし不足している属性はRelying Partyと個別に調整を行った上で定義する必要があります。

今回はStandard Claimsとして実際にどのような値を返すべきか確認していきましょう。

その前にこれまでのおさらいです。

• まずは全体像から
• まずOpenID Providerの情報をRelying Partyに提供する
• OpenID Providerを作る）認可エンドポイントを作る
• OpenID Providerを作る）トークンエンドポイントを作る
• OpenID Providerを作る）UserInfoエンドポイントを作る
• OpenID Providerを作る）response_typeを実装する
• OpenID Providerを作る）Hybridフローを実装する
• OpenID Providerを作る）Pairwise識別子を実装する
• OpenID Providerを作る）scopeの定義と返却する属性

では、早速確認していきます。

昨日のStandard Claims一覧を再掲しておきます。

scope	属性	形式	備考
profile	name	string
	family_name	string
	given_name	string
	middle_name	string
	nick_name	string
	preffered_username	string
	profile	string	URL
	picture	string	URL
	website	string	URL
	gender	string	female/maleを利用
	birthdate	string	ISO 8601:2004形式（YYYY-MM-DD）
	zoneinfo	string	IANAタイムゾーン形式（JapanやAmerica/Los_Angelesなど）
	locale	string	BCP47言語タグ表現（ja_JP、en_USなど）
	updated_at	number	unixtime
email	email	string
	email_verified	boolean	検証済みならtrue
address	formatted	string	JSON
	street_address	string
	locality	string
	region	string
	postal_code	string
	country	string
phone	phone_number	string	E.164形式
	phone_number_verified	boolean	検証済みならtrue

nameなどのstring形式の属性についてはあまり迷うことはないと思うので、迷いそうなところだけピックアップしておきたいと思います。

• profile
• この属性にはURLを返却することが想定されています。仕様をみると「この Web ページに掲載されるコンテンツはこの End-User に関するものであるべきである (SHOULD).」とあるので、もしOpenID Providerがマイページやプロフィールページを持っているならそのURLなどを使うと良いと思います。
• picture
• この属性も同じくURLですが、このような注意点が定義されています。
• この URL は画像ファイル (PNG, JPEG, GIF 画像ファイル等) を参照すること (MUST). またこの画像は End-User が撮影した任意の写真ではなく, End-User に言及する際の表示に適切なプロフィール画像とするべきである (SHOULD).
• 利用者自身でアップロードできたる編集するものじゃなさそうですが、OpenID Providerの種類（コンシューマ向けなのかエンタープライズ向けなのか）でどのような写真を使うのかは変わってきそうです
• website
• この属性もURLです。こちらも以下の注意点が記載されています。
• この Web ページは End-User 自身や End-User が所属する組織が発信する情報を含むべきである (SHOULD).
• こちらもシナリオ次第ですね
• email
• 想像通りだと思いますがメールアドレスのSyntax（RFC 5322）に従う必要があります
• gender
• string形式ですが使用上はmale/femaleが定義されています。しかしながら最近のID基盤ではそれ以外の値を定義することもあります。仕様にはその他の値を設定することも許容しています
• 定義済の値に適切なものがない場合, その他の値を利用してもよい (MAY).
• birthdate
• こちらもstring形式ですがISO 8601:2004に準拠すべきです。仕様には以下の記載があります。
• ISO 8601:2004 YYYY-MM-DD 形式で表現される. 生年を 0000 とすることで生年を省略することもできる (MAY). 生年のみを提示する場合は YYYY 形式としても良い. 利用するプラットフォームの日付関連の関数の実装によって, 生年のみを提供した場合の月日の扱いは様々であるため, 実装者はこの点を考慮にいれて日付を処理すべきである.
• zoneinfo
• こちらもstring形式です。ユーザのタイムゾーンを表す属性ですので、IANAのタイムゾーンレジストリに登録されているコードを使うことが想定されています。
• 例えば日本ならJapan、北米/ロサンゼルスならAmerica/Los_Angelesです
• locale
• こちらもstring形式ですが、結構鬼門だと思っています。仕様には以下の記載があります
• BCP47言語タグ表現. これは通常 ISO 639-1 Alpha-2 言語コードを小文字表記, ISO 3166-1 Alpha-2国コードを大文字表記し, ダッシュでつなげたものである. (en-US, fr-CA 等) 実装によってはダッシュの代わりにアンダースコアを区切り文字に用いる場合もあるため, 互換性の観点からは注意すること. (en_US 等) 
• いわゆるISOのAlpha-2言語コード（jaとかen）とAlpha-2区にコード（jpとかus）を大文字表記したものをダッシュ（ハイフン）もしくはアンダースコアで繋げたものという緩めの仕様なので、ja-JPもしくはja_JPという形で値が表現されます。この辺りはRelying Partyに対してどのような表現になるのか事前に伝達しておく必要があります
• phone_number
• こちらもstring形式ですが、locale同様に少し揺れる要素があります。原則はE.164形式を推奨するようですが、内線番号の有無や区切り文字やカッコの有無などは考慮が必要です
• この Claim のフォーマットとしては E.164を推奨する (RECOMMENDED). (+1 (425) 555-1212, +56 (2) 687 2400 等) 電話番号が拡張を含む場合, その拡張は RFC 3966 拡張シンタックスで表記することを推奨する (RECOMMENDED). (+1 (604) 555-1234;ext=5678 等)
• E.164の仕様だけ見ていると+[国番号]に市外局番の最初の0をとったものと局番をつなげたものということですが、実装を見ているとハイフンの有無やカッコの有無が揺れているようにも見えます。この辺りも事前にRelying Partyに伝達しておいた方が良さそうです
• updated_at
• こちらはnumberとして定義されていますので要注意です。UTC 1970年1月1日の0:00:00からの経過秒数、いわゆるunix timeをセットする必要があります

今日はこのくらいにしておきたいと思います。