Introduction

This document describes the UMA trust model aspects. Mainly, it describes the three fundamental aspects: Registration, Trusted Claims and Delegation which help to bind the trust relationship (legal/business and technical) among the parties involved in the UMA Authorization process.

Aspects of Trust

Business Trust

Who gets to use what, for what, in what circumstances

Legal Trust

Who is responsible when things go sideways

Technical Trust

How different systems actually talk to each other

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).

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.

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

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

Authorizing User Registration

• Untrusted Registration or Self-registration
• Affiliate Registration (SSO) based on an Identity Assurance framework

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.

Secure Tokens

A token is an electronic information that comprises access permissions and trust values.
TBD

Cryptography

TBD

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).

Applying UMA Trust aspects to a Business case

Healthcare scenario

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.

Accreditation

• CopMonkey.com applies for an accreditation request to the NHS.
• NHS evaluates CopMonkey.com based on the accreditation procedures.
• CopMonkey.com is published as an accreditated Authorization Service provider for online healthcare systems.

Subject Registration

• Alice choices HealthcareSystem.com as his prefered online healthcare records management.
• Alice is automatically provisionated in the HealthcareSystem.com because she is registered with the NHS and she has an assurance.

Protecting Healthcare Records

• Alice decides to protect his healthcare information with an external authorization system. She choices CopMonkey.com from the accreditated Authorization Service, listed in the HealthcareSystem.com app page.
• She introduces the Host to CopMonkey. She uses an affiliated SSO process to authenticate herself to CopMonkey.
• She defines an access policy at CopMonkey.com by which allow access to his healthcare record only to Hospital Doctor (role), including emergency room operators. She provides also reduced healthcare records access to researcher.

Hospital visit

• Alice visits the hospital for an health check-up.
• She meets with Bob, a Doctor from department of ecography.
• Bob needs to access to online Alice's healthcare records.
• Bob uses a Hospital's web application to attempt to access to Alice's healtcare records at the HealthcareSystem.com.
• CopMonkey.com applies Alice's policy, asking for Trusted Claims, to verify the Bob's role.
• Bob gets access to the Alice's Healthcare record.

References

User-Managed Access Core Protocol 

UMA Trust Model Specification

OpenID Connect Spec

Rainer Steffen, Rudi Knorr, A trust based delegation system for managing access control