Anchor
h.2aybfh7m3ksh h.2aybfh7m3ksh

Introduction

...

Anchor
h.vrlb7me5wl5a h.vrlb7me5wl5a

UMA Trust Model aspects

UMA trust model is built on the following implications that are based on the UMA features:

• Host's Authorization decision is externalized to the Authorization Manager (AM).
• There is no relationship between a Requester and the Authorization manager prior to a request for access.

Externalizing an authorization decision requires a formal registration process and consequently a delegation of protection of a resource.
Furthermore, because the AM does not know the requester directly, it has to use information from third parties who know the requester better. Normally, the AM trusts these third parties only for certain things and only to certain degrees.
These trust and delegation aspects make UMA's authorization system different from traditional access control.
The following diagram illustrates is an high level representation of the UMA Trust Model which describes the trust relationships. We use a multiple triangles representation because it's useful to represent this complex trust relationship (2 parties + one authority).

In the diagram are represented the three main aspects of the UMA trust model:

• Registration (Host-AM trust relationship),
• Trusted Claims (AM-Requester trust relationship) and
• Delegation (Host-Requester trust relationship)

All these aspects are functional to the UMA Authorization process which includes the following actions: Protect, Authorize and Access (as showed in the centered triangle).

Anchor
h.r6nfx170rypi h.r6nfx170rypi

Registration

The Registration aspect is the initial process to create the trust relationship between the Host and Authorization Manager, this includes technical procedures (such as private key exchange), legal agreements and policies. This process is mediated by the Authorizing User.

Anchor
h.dyu68pfafdan h.dyu68pfafdan

Bootstrapping Trust

Authorizing User (AU) is an actively part during the UMA protecting a resource phase. For this reason, this is the most critical trust (Bootstrapping trust) aspect of the whole process, where the AU builds his (trust) mental state towards others agents (Host, AM), evaluating the possible trustworthiness factors. Viceversa, the agents must trust the Identity of the subject involved in the process.
Parts of this fundamental process are:

• Accreditation System and
• Authorizing User Registration and Identification

Anchor
h.9lnifugszfuv h.9lnifugszfuv

Accreditation System

The "Accreditation system" could be part of the Registration process, which is involved to guarantee an adequate level of trustworthiness about the parties in case of specific business (i.e. Healthcare, financial credit).
The Accreditation System is a trusted third party (an Authority) which is involved in the creation of the Host-AM relationship.
Roles and Responsibilities:

• Provides accreditation guidelines for specific business case (i.e. Healthcare, Financial, Government, etc.) that the Authorization Manager (AM) must adhere.
• Maintains the list of accredited Authorization Managers.
• Assess/Evaluates the AMs based on a specific model.
• Defines legal agreements between the Host and the AM, based on specific business.

The following steps describe the Accreditation System process:

1. The Authorization Manager makes an accreditation request for a specific business.
2. The Accreditation System finds the policies and procedure to apply for the request.
3. The Accreditation System evaluates AM against the business/legal and technical procedures.
4. AM adheres on the Terms of services specific the business.
5. The Accreditation System registers the AM in the list of the accredited service provider.
6. The Host can retrieve the list and include the AM link in the resource page for the registration purpose.

To characterize the the Accreditation system, it can be expressed as quaternary relation:
Accreditation_System:AM= Trust_Framework:IdP

Anchor
h.fq72vv2uu7qk h.fq72vv2uu7qk

Authorizing User Registration

...

Anchor
h.ycsqo17d3jcj h.ycsqo17d3jcj

Trusted Claims

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:

1. The AM OpenID Client sends a request to the Server's End-User Authorization Endpoint.
2. The Server authenticates the user (Requesting Party) and obtains appropriate authorization.
3. The Server responds with a Token (access token) and a few other variables.
4. The Client sends a request with the Token to the Userinfo Endpoint.
5. Userinfo Endpoint returns the additional user supported by the Server.

The trust binding for this aspect is based on the following element:

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

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.

...

Anchor
h.ya1ekhebq9h3 h.ya1ekhebq9h3

Trust Frameworks

A trust framework is a certification program that enables a party who accepts a digital identity credential (called the relying party) to trust the identity, security, and privacy policies of the party who issues the credential (called the identity service provider) and vice versa.
AM Roles and Responsibilities:

• The AM is a relying party of Identity Service Providers (for the AU Registration and for Trusted Claims scopes)
• The AM maintains the list of certified IdP, including the cryptographic material (i.e. Public key).

...

Anchor
h.zhniwh12wz47 h.zhniwh12wz47

Actors and roles

• Alice is a citizen who is registered with the National Healthcare System (NHS) through the Employer's assurance company.
• HealthcareSystem.com is a Service Provider which provides an online personal healthcare records, part of the National healthcare system (NHS).
• NHS provides the guidelines, procedures and the legal framework for online access to Healthcare records and it leverages Trust Framework in order to trust identity (claims) issues from Identity Service provider.
• CopMonkey.com is an Authorization Service provider based on UMA protocol, it provides advanced distributed access control services for individual, and it leverages a Trust Framework (as relying party) in order to trust identity (claims) issues from Identity Service provider.
• Hospital are part of NHS and they provides web application acting as Requester for individual healthcare records.
• Bob is a Doctor of the Hospital and he acts as Requesting Party.

Anchor
h.nvpyjjrvw5l5 h.nvpyjjrvw5l5

Accreditation

...