User-Managed Access
0系の仕様を使っている。
UMAは、OpenID 2.0をユーザ認証の手段として使ったり依存したりしない。 しかし、オプションとしてアクセス要求者(RqP)からアイデンティティクレーム(claim)を収集する手段として、認可を行うユーザのアクセスポリシーを満たすようにするために、OAuthに基づくOpenID Connect プロトコルを使う。
またUMA はXACML(eXtensible Access Control Markup Language)を、ユーザポリシーの符号化にも、アクセス認可のリクエストの手段としても、使ったり依存したりしない。 UMAは、ポリシーのフォーマットを指定しない。 UMAの観点からは、ポリシーに照らした判定は、ASにとって最初に行われるからである。 しかし、アクセス許可をリクエストするためのUMAプロトコルフローは、XACMLプロトコルといくつか共通の機能をもつ。
次の図では、UMAがOAuth 2.0に追加した点を強調してある。
典型的なOAuthフローにおいて、クライアントアプリケーションを運用している人間であるRO(Resource Owner)は、ログインするためにAS(Authorization Server)にリダイレクトされ、クライアントアプリケーションが機能としてROの代わりにRS(Resource Server)の一定範囲にアクセスできるようにアクセストークンの発行に承諾する。 RSとASは、一般的に同一のセキュリティドメイン内で運用されており、それらの間の通信は、OAuthの主仕様によっては標準化されていない。
UMAは、3つの主要コンセプトと対応する構造とフローを追加する。
UMAは、ASにおいてRSがしゃべりかける標準化されたAPI(protection APIと呼ばれるもの)を定義する。