.NET開発基盤部会」によって運営されています。†このプロファイルを簡単に説明すると、以下のようになる。attackの可能性がある。†acrとamrat_hashとc_hash更に、切り離された署名のためのs_hash。認可レスポンスが改ざんされていないことを検証。s_hashクライアントは、at_hashとc_hashに加え、s_hashの値を検証する。値のASCII表現のオクテットのハッシュの左端の半分をbase64urlエンコーディングハッシュはIDトークンのJOSEヘッダのalgパラメタで使用されるアルゴリズム。左端の256ビットを切り出し、base64urlエンコードする。この代替に「JARM」と言う仕様もある。3特定される身元識別情報の信用度が「相当程度ある」。パスワードだけではなく、2要素以上を用いてユーザー認証をする。Assertion(private_key_jwt)「MTLS」(「OAUTB」の場合は?以下のように書かれているため、「MTLS」を使用するのかも。FAPIクライアントが「MTLS」または「OAUTB」を使用する場合、認証コードはTLSチャネルにバインドされます。紐付け(トークン・バインディング)のために以下の何れかをサポートする必要がある。Profile)」に準拠。Confidentialクライアントをサポートする。Publicクライアントをサポートすべき。切り離された署名のためのs_hash紐付け(トークン・バインディング)のために以下の何れかをサポートする必要がある。†クライアント認証が必要。JWEのIDトークンの要求が必要推奨される。†クライアント認証は不要。PKCEをサポート「ハッシュ関数」には、「S256」を使用する。Redirection」を使用する。3以上での認証を要求し、acrとamrを検証する。各カギは、SPA系は、クライアント端末ごとになる。Nativeは、インストール(インスタンス)毎になる。Profile)」に準拠。†Publicクライアントの場合、必須。Serverがホストする。これにより、Clientが指定したrequest_uriへの要求をサポートする必要が無い。Requestオブジェクトの機密性のためにURIのエントロピーに依存しない。request_uriは、以下の何れか。expクレームを含める必要がある)。OAuth2の認可リクエスト仕様で要求されている場合は、一致した重複を更に送信しても良い。†どうも、この(specの)コンテキストからすると、このリクエストは認可リクエストではなく、Requestオブジェクトの登録リクエストっぽい。このRequestオブジェクトの登録エンドポイントは、Discoveryで公開される。...)zCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzwなので、request_uriの形式は、URNになるのが既定と考える。error署名検証が失敗した場合。error要求サイズが上限を超える場合。errorある期間にClientからの要求数が上限を超えた場合。†Publicクライアントの場合、AuthZ実装も大変だが、Client実装が大変。JavaやJavaScriptでJWT検証処理等を実装する必要が出てくる。このためか、JWEがPublicクライアントのFlowで求められていない。