11. 実装に関する考慮事項 (Implementation Considerations)
11.1. 特定のデプロイメントでのauthorization_detailsの使用 (Using authorization_details in a Certain Deployment)
この仕様を使用するエコシステムは、使用されるtype値と認可詳細タイプ、および各タイプに定義される拡張フィールドを定義します。このような定義は、ASとクライアントによる検証を容易にするために、各type値についてJSON Schema(または他の適切な形式化手法)を含むべきです(SHOULD)。
認可サーバーは、authorization_details_types_supportedメタデータパラメータを公開し、そのデプロイメントでサポートされているtype値を宣言すべきです(SHOULD)。
特定のデプロイメントまたはユースケースでscopeまたはauthorization_detailsを使用するかどうかを決定する際、以下の考慮事項が役立つ場合があります:
scopeは、各scope値が一意の意味を伝える用例に使用できます。- 伝えられる権限がさらなる認可詳細によって細分化できる場合は、
authorization_detailsを使用すべきです。
開発者は、複雑さを制限し混乱を避けるために、同じ種類の認可データを指定するために両方の認可データ形式を使用すべきではありません。
11.2. 最小製品実装 (Minimal Product Implementation)
RARの最小限の機能のみを実装したいシステムは、機能のサブセットを実装することでそれを実現できます:
- クライアントは、特定の
type値1つとその特定のtypeの共通データフィールド(セクション2.1)のみをサポートする場合があります(MAY)。 - ASは、特定の
type値1つとその特定のtypeの共通データフィールド(セクション2.1)のみをサポートする場合があります(MAY)。 - リソースサーバー(RS)は、RSのリソースインジケーターに対して
locations要素のみをチェックし、他のauthorization_detailsコンテンツを無視する場合があります(MAY)。
11.3. 認可リクエストのサイズ (Size of Authorization Requests)
この仕様を利用するデプロイメントでは、伝達される追加の詳細情報により、認可リクエストのサイズが増加する可能性があります。デプロイメントは、予想されるサイズの増加を処理できるように、システムに十分なバッファスペースが割り当てられていることを確認する必要があります。認可リクエストURI(例えば、HTTPリダイレクトバインディング内)は、認可リクエストにエンコードされるコンテンツの結果として大きくなる可能性があります。システム実装者は、クライアント、AS、またはプロキシやキャッシュなどの中間インフラストラクチャコンポーネントでエラーを引き起こすことなく、予想されるサイズの増加を処理できるようにシステムを構成する必要があります。
セクション12に示されているように、[RFC9101]と[RFC9126]を使用したリクエストの整合性と機密性の保護は、URLパスコンポーネントのサイズを境界内に保つのにも役立ちます。