User-Managed Access

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/06 15:46 UTC 版)

UMAを開発したグループの憲章^[1]に記述されているように、プロトコル仕様の目的は「リソースオーナー（RO）が、オンラインサービス間で行われるデータ共有や他のリソースに対するアクセス認可を制御できるようにすること」にあり、これは、「POの代わりに、あるいは、ROによる認可を伴って自律的なアクセス要求者（RqP）によって」行われる。この目的には、標準化グループの参加者によって行われたケーススタディの収集によって探求されたように、WebアプリケーションとIoT（Internet of Things）についてのプライバシーと承諾が考慮されている ^[2]。

経緯と背景

Kantara InitiativeのUMA Work Group^[3]は、2009年8月6日にその最初の会合を開催した^[4]UMAの設計原則と技術的な設計は、2008年3月に始まったProtectServeと呼ばれたプロトコルについてのサン・マイクロシステムズ社の従業員による以前の作業によって知らされていた。今度はProtectServeが、ベンダー関係管理（VRM）の動向と、「feeds-based VRM」と呼ばれる副次的活動の目標によって、影響を受けた。

ProtectServeとUMAの初期バージョンは、OAuth 1.0プロトコルを応用していた。 OAuthは、WRAP（Web Resource Authorization Protocol）仕様や、以降のOAuth 2.0のドラフトの発行を通じて大幅な変更を経たが、UMA仕様は追随し、現在、いくつかの主要プロトコルフローのためにOAuth 2.0系の仕様を使っている。

UMAは、OpenID 2.0をユーザ認証の手段として使ったり依存したりしない。しかし、オプションとしてアクセス要求者（RqP）からアイデンティティクレーム（claim）を収集する手段として、認可を行うユーザのアクセスポリシーを満たすようにするために、OAuthに基づくOpenID Connect プロトコルを使う。

またUMA はXACML（eXtensible Access Control Markup Language）を、ユーザポリシーの符号化にも、アクセス認可のリクエストの手段としても、使ったり依存したりしない。 UMAは、ポリシーのフォーマットを指定しない。 UMAの観点からは、ポリシーに照らした判定は、ASにとって最初に行われるからである。しかし、アクセス許可をリクエストするためのUMAプロトコルフローは、XACMLプロトコルといくつか共通の機能をもつ。

標準化状況

UMAグループは、Kantara Initiativeにおいて作業を行っており ^[5]、UMAの標準化作業についての本家としてIETF（Internet Engineering Task Force）における一連のInternet-Draft 仕様にも貢献してきた。こちらでは、このWGは、IETFに対して、考慮に値するいくつかの個別のInternet-Draftに貢献してきた。これらのひとつであるOAuth dynamic client registration^[6] のための仕様は、より一般化されたメカニズムについて入力する役割を果たし、結局、OAuthの開発につながった^[7]。

脚注