Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Trusted Claims aspect describes the AM-Requester (on behalf of Requesting Party) relationship.
UMA is designed to support claims-based Access Control, by which the access control decision to grant access to Authorizing User's resource (Protected Resource at Host) is made based on Requesting party information, such as Subject's name, age (or date of birth) email address, role, location, or score credit, etc.
In general, in UMA authorization system, there is no relationship between a Requester and the Authorization Manager (AM) prior to a request. Because the AM does not know the requester directly, to satisfy the access policy, it has to ask for information (Trusted Claims) from third parties who know the Requester better.
UMA trust model leverages the Trust Framework in order to trust identity (claims) issues from Identity Service provider.
For this specific purpose, UMA protocol provides an OpenID Connect claim profile  based on OpenID Connect specification. 
OpenID Connect provides authentication, authorization, and attribute transmission capability. It allows third party attested claims from distributed sources.
OpenID Connect specification refers to the Authentication Context which is an information that the Relying Party (AM) may require before it makes an entitlements decision with respect to an authentication response. Such context may include, but is not limited to, the actual authentication method used or level of assurance such as ITU X.1254 | ISO/IEC 29115||\ entity authentication assurance level.
The picture below shows an high level diagram about UMA and OpenID Connect interoperability model based on the following steps:

...

  • AM relays Authorization Server's OpenID Connect domain because it is part of a Trust Framework.

Anchor
h.k8lpyo7pgj7q
h.k8lpyo7pgj7q

Delegation and Trust Chain

The Delegation aspect describes the Host-Requester relationship. The Trust Delegation is to use natural trust relationships to gain access to digital services.
The following diagram shows the basic principle of that concept. A trust source (AM) generates a token with explicit information about the access rights to a specific service or a trust value that describes the trust relationship between the trust source and the Requester.
During the service invocation the Requester delivers the token to the Host. Through the content of the token, the Host decides autonomously if the access will be granted or not.


In the diagram are also represented implicit trust aspect (dotted lines) that allow to determine the AM as trusted source in a kind of Trust Chain.

...