idnits 2.17.00 (12 Aug 2021) /tmp/idnits20688/draft-maler-oauth-umatrust-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 5, 2015) is 2596 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 757, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'UMAcore' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Maler, Ed. 3 Internet-Draft ForgeRock 4 Intended status: Standards Track T. Hardjono 5 Expires: October 7, 2015 MIT 6 April 5, 2015 8 Binding Obligations on User-Managed Access (UMA) Participants 9 draft-maler-oauth-umatrust-03 11 Abstract 13 User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how 14 resource owners can control protected-resource access by clients 15 operated by arbitrary requesting parties, where the resources reside 16 on any number of resource servers, and where a centralized 17 authorization server governs access based on resource owner policy. 18 This document provides a contractual framework that defines the 19 minimum obligations of parties that operate and use UMA-conforming 20 software programs and services. The goal of this framework is to 21 support end-to-end legal enforceability of the terms and conditions 22 of access sharing relationships between authorizing and requesting 23 sides that use UMA. The audience for this document includes 24 technologists, legal professionals, and operators of UMA-conforming 25 services. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 7, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Sample Use Cases for Sharing Access to Resources . . . . 3 63 1.2. How to Use the Contractual Framework . . . . . . . . . . 4 64 1.3. Obligations Not in the Scope of the Contractual Framework 6 65 2. Binding Obligations on UMA Participants . . . . . . . . . . . 7 66 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . 10 69 2.2. Obligations of the Requesting Party . . . . . . . . . . . 10 70 2.2.1. Requesting Party-Authorizing Party: Adhere-to-Terms . 10 71 2.2.2. Requesting Party-Authorizing Party: Make-Factual- 72 Representations . . . . . . . . . . . . . . . . . . . 11 73 2.2.3. Requesting Party-Authorization Server Operator: 74 Supply-Truthful-Claims . . . . . . . . . . . . . . . 11 75 2.2.4. Requesting Party-Resource Server Operator: Is- 76 Legitimate-Bearer . . . . . . . . . . . . . . . . . . 12 77 2.3. Obligations of the Resource Server Operator . . . . . . . 12 78 2.3.1. Resource Server Operator-Authorizing Party: Delegate- 79 Protection . . . . . . . . . . . . . . . . . . . . . 12 80 2.3.2. Resource Server Operator-Authorization Server 81 Operator: Register-Accurately-and-Timely . . . . . . 12 82 2.3.3. Resource Server Operator-Authorization Server 83 Operator: Respect-Permissions . . . . . . . . . . . . 13 84 2.3.4. Resource Server Operator-Requesting Party: Give- 85 Accurate-Access . . . . . . . . . . . . . . . . . . . 13 86 2.4. Obligations of the Authorization Server Operator . . . . 14 87 2.4.1. Authorization Server Operator-Authorizing Party: 88 Follow-Policies-Accurately-and-Timely . . . . . . . . 14 89 2.4.2. Authorization Server Operator-Resource Server 90 Operator: Follow-Policies-Accurately-and-Timely . . . 14 91 2.4.3. Authorization Server Operator-Requesting Party: 92 Request-Limited-Claims . . . . . . . . . . . . . . . 15 93 2.5. Obligations of the Authorizing Party . . . . . . . . . . 15 94 2.5.1. Authorizing Party-Requesting Party: Adhere-to-Terms . 15 95 2.5.2. Authorizing Party-Authorization Server Operator: 96 Introduce-Resource-Server . . . . . . . . . . . . . . 15 98 2.5.3. Authorizing Party-Resource Server Operator: 99 Introduce-Authorization-Server . . . . . . . . . . . 16 100 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 101 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 4.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 4.2. Informative References . . . . . . . . . . . . . . . . . 17 104 Appendix A. Document History . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 107 1. Introduction 109 User-Managed Access (UMA) [UMAcore] is a profile of OAuth 2.0. UMA 110 defines how resource owners can control protected-resource access by 111 clients operated by arbitrary requesting parties, where the resources 112 reside on any number of resource servers, and where a centralized 113 authorization server governs access based on resource owner policy. 114 This document provides a contractual framework that defines the 115 minimum obligations of parties that operate and use UMA-conforming 116 software programs and services. The goal of this framework is to 117 support end-to-end legal enforceability of the terms and conditions 118 of access sharing relationships between authorizing and requesting 119 sides that use UMA. The audience for this document includes 120 technologists, legal professionals, and operators of UMA-conforming 121 services. 123 Capitalized terms and abbreviations used in this document are defined 124 in Section 2.1 because they form a normative part of the framework 125 defined in Section 2. Readers are strongly encouraged to review 126 these definitions before reading the rest of the introduction. 128 1.1. Sample Use Cases for Sharing Access to Resources 130 UMA makes possible a loosely coupled end-to-end access sharing 131 relationship between an Authorizing Party and a Requesting Party, 132 with its primary goals being to constrain access according to the 133 Authorizing Party's access policies and to encourage the Requesting 134 Party to adhere to any obligations it consented to in the 135 authorization process by raising the consequences for doing 136 otherwise. Following are sample use cases that explore the potential 137 differences in these obligations beyond the basic level represented 138 in the contractual framework. 140 Person-to-self sharing Here, Alice is both the Authorizing Party and 141 the Requesting Party. This use case describes most types of 142 today's OAuth-mediated access, for example, when Alice introduces 143 the Klout service to her Twitter account. She uses both services 144 herself, and wants them to communicate together on her behalf. 145 With UMA, Alice can potentially manage the entire set of such 146 access connections from a single place rather than from Twitter 147 and other online "home bases" separately. In this circumstance, 148 it's unlikely Alice will want to impose stringent contract terms 149 on herself. 151 Person-to-person sharing Here, Alice is an Authorizing Party and Bob 152 is a Requesting Party. Today, many Web 2.0 sites offer some level 153 of selective sharing between people, but methods, strengths, and 154 interfaces are inconsistent between sites and people are unable to 155 reuse policies across sites. Alice can share Flickr photos with 156 Bob by adding him to her Flickr friends list or family list or by 157 mailing him a special link to a photo album, or Alice can add Bob 158 as a friend on Facebook. With UMA, Alice can craft authorization 159 policies that let Bob "qualify in" to get access to her photo 160 album and even to other resources she manages at other sites, 161 without her having to be present during this process. 163 Mediated person-to-organization sharing Here, Alice is an 164 Authorizing Party, the DentalCare company is a Requesting Party, 165 and the company's office assistant Carl is a Requesting Party 166 Agent. Alice wants to give her dentist's office, DentalCare, 167 temporary access to her calendar to make it easier to schedule a 168 series of root canal appointments. Carl might be the actual 169 person acting on behalf of the dental practice who actually asks 170 for and views Alice's calendar. With UMA, Alice can require Carl 171 to prove he is acting on behalf of DentalCare -- for example, 172 demonstrating control of an email address in the dentalcare.com 173 domain -- before seeing her calendar. 175 Autonomous person-to-organization sharing Here, Alice is an 176 Authorizing Party and the Valley Vehicles car dealership is a 177 Requesting Party. Alice has crafted a "personal request for 178 proposals" because she's in the market for a new car, and she's 179 willing to let car dealerships in her region of the country see 180 her request and make offers to her. With UMA, Valley Vehicles and 181 other dealerships might use Web crawler services to go out and 182 collect requests for proposals, without human helpers, and these 183 services might have to prove in automated fashion that they 184 legitimately represent the right kind of business. Alice can also 185 ensure each dealership agrees to her terms before seeing her 186 request for proposals. 188 1.2. How to Use the Contractual Framework 190 The contractual framework in Section 2 is the normative portion of 191 this document. It is intended to apply to all Subjects that take 192 part in software interactions using services that are declared to be 193 UMA-conforming. It defines the minimum set of obligations that these 194 Subjects accept. The Subjects can adopt additional obligations, and 195 can further refine or constrain the obligations listed here, but 196 cannot make these minimum obligations less strict. 198 Each clause takes the following form: 200 "[_Clause ID_]. When [_protocol interaction takes place_], the 201 [_obligated Subject_] gains an obligation to the [_expecting 202 Subject_] to [_behave towards it in a particular way_]." 204 The clause ID has the following internal structure: 206 "[_obligated_]-[_expecting_]-[_keyword_]" 208 It uses abbreviations for the obligated and expecting Subjects as 209 follows: RqP for Requesting Party, RSO for Resource Server Operator, 210 ASO for Authorization Server Operator, and AzP for Authorizing Party. 211 Clauses are generally followed by non-normative explanatory comments, 212 which are labeled with "Comments:", and occasionally open issues, 213 which are labeled with "Issues:". The latter are meant to be 214 resolved and removed before final publication. 216 Specific obligations come as a result of precise protocol 217 interactions, so that at a moment in time, any one Subject may not 218 yet have taken on all of the obligations defined in the contractual 219 framework as belonging to that Subject. By analogy, if Alice were to 220 visit a website that imposes terms of service on the site's users, 221 but it requires users to consent actively by clicking on an "I Agree" 222 button, Alice would take on terms-of-service obligations only after 223 she clicks on the button. 225 Following are the key UMA interactions that result in obligations, 226 with specific cross-references into the [UMAcore] specification. A 227 non-normative visual correlation of interactions to binding 228 obligations can be found at [UMAFAQ-swim]. (Lowercase versions of 229 names are references to constructs in the technical specification 230 versus this document.) 232 o An authorization server issues a protection API token (PAT) to a 233 resource server: Section 1.3.1. 235 o An authorization server issues an authorization API token (AAT) to 236 a client: Section 1.3.1. 238 o An authorization server issues a requesting party token (RPT) to a 239 client: Section 3.4.1. 241 o An authorization server responds positively to a client's 242 authorization request: Section 3.4.2. 244 o A resource server determines the status of an RPT: Section 3.3. 246 o A resource server registers a client-requested permission: 247 Section 3.2. 249 o A requesting party supplies claims to an authorization server: 250 Section 3.5. 252 o A resource server responds to a client's request for access: 253 Sections 3.1.1 and 3.1.2. 255 o A client successfully receives access: Section 3.1.2. 257 1.3. Obligations Not in the Scope of the Contractual Framework 259 Of the Subject types defined and discussed in this document, some -- 260 Requesting Party Agents and Client Operators -- have no UMA-dictated 261 obligations, though they might have obligations as part of 262 contractual agreements with other UMA-related Subjects, for example, 263 pairwise contracts or membership in trust frameworks. Additionally, 264 pairs or groups of Subjects that do have obligations imposed by the 265 contractual framework might have additional obligations among 266 themselves beyond those in the framework. Following are some typical 267 examples: 269 o When a Resource Owner registers for an account at a Resource 270 Server, the Authorizing Party might gain an obligation to the 271 Resource Server Operator to adhere to the Resource Server 272 Operator's terms of service. 274 o When a Client registers with an Authorization Server for OAuth 275 client credentials (for example, through an explicit approval 276 process or through a passive "API-wrap" process), the Client 277 Operator might gain an obligation to the Authorization Server 278 Operator (apart from any particular Requesting Party's usage of 279 that Client) to adhere to the Authorization Server Operator's 280 terms of service for API clients. 282 o When a Subject becomes a Requesting Party Agent for a Requesting 283 Party (for example, through an employment agreement), the 284 Requesting Party Agent might gain an obligation to adhere to any 285 agent agreements in place in the Subject's UMA-related 286 interactions performed on behalf of the Requesting Party. 288 o When a Requesting Party contracts with a Client Operator to engage 289 in UMA-related interactions on the Requesting Party's behalf, the 290 Client Operator might gain an obligation to adhere to the terms of 291 that contract. For example, a car dealership may contract out to 292 use a cloud service that crawls the Web looking for personal RFPs 293 that meet the dealership's criteria, and want to impose 294 confidentiality requirements. 296 o When a Client accesses a protected resource at a Resource Server, 297 the Resource Server Operator might gain an obligation to the 298 Client Operator to be trustworthy as a source of the expected 299 data. For example, in a scenario where the Requesting Party is 300 also the Authorizing Party and is trying to fill in an online loan 301 application through an online financial service (the Client), 302 where the Resource Server Operator provides credit risk data about 303 the Authorizing User, the Client Operator will want to 304 authenticate the Resource Server service in some fashion. 306 2. Binding Obligations on UMA Participants 308 This section constitutes a normative framework that defines the 309 minimum obligations gained by parties that operate and use software 310 programs and services that the operators declare to be UMA- 311 conforming. The framework consists of clauses, where each subsection 312 with content is a clause. 314 2.1. Terminology 316 2.1.1. Terms 318 This framework uses the following terms. Where terms are used 319 without capitalization and are not otherwise defined in the 320 [UMAcore], they are used in their normal sense. 322 Individual 323 A natural person (that is, a human being) with the capacity to 324 take on contractual duties and obligations as a participant in 325 an UMA interaction. 327 Non-Person Entity (NPE) 328 A legal person (such as a corporation) with the capacity to 329 take on contractual duties and obligations as a participant in 330 an UMA interaction. 332 Subject 333 An Individual or NPE. Subjects play various roles in achieving 334 and seeking user-managed access, and the same Subject might 335 serve in multiple contractual roles. 337 Conformance 338 Claimed adherence of a running software program or service to 339 the requirements of one or more of the roles "authorization 340 server", "resource server", or "client", as defined in 341 [UMAcore]. Software components play various roles in 342 participating in the technical interactions necessary to 343 achieve and seek user-managed access, and the same software 344 component might serve in multiple technical roles. 346 Authorizing Party 347 A Subject that fills the "resource owner" role as defined in 348 [UMAcore], using and configuring software services that 349 variously fill the "authorization server" and "resource server" 350 roles. This Subject is the "user" in "User-Managed Access"; 351 UMA's first priority is to enable Individuals to serve in the 352 Authorizing Party role, though NPEs can serve in this role as 353 well. 355 Authorization Server 356 A software service that fills the "authorization server" role 357 as defined in [UMAcore]. 359 Authorization Server Operator 360 A Subject responsible for running and operating an 361 Authorization Server. 363 Resource Server 364 A software service that fills the "resource server" role as 365 defined in [UMAcore]. 367 Resource Server Operator 368 A Subject responsible for running and operating a Resource 369 Server. 371 Client 372 A software application or service that fills the "client" role 373 as defined in [UMAcore]. 375 Client Operator 376 A Subject responsible for running and operating a Client. 378 Requesting Party 379 A Subject that uses a Client to seek access to a protected 380 resource. This Subject may be an Individual or an NPE. The 381 Requesting Party and the Authorizing Party may be the same 382 Subject or different Subjects. 384 Requesting Party Agent 385 A Subject using a Client to seek access to a protected resource 386 on behalf of a Requesting Party. Typically this Subject is an 387 Individual acting on behalf of an NPE. 389 Comments: The [UETA] defines two terms that are particularly relevant 390 to understanding the interactions among UMA participants: 392 o "'Automated transaction' means a transaction conducted or 393 performed, in whole or in part, by electronic means or electronic 394 records, in which the acts or records of one or both parties are 395 not reviewed by an individual in the ordinary course in forming a 396 contract, performing under an existing contract, or fulfilling an 397 obligation required by the transaction." 399 o "'Electronic agent' means a computer program or an electronic or 400 other automated means used independently to initiate an action or 401 respond to electronic records or performances in whole or in part, 402 without review or action by an individual." 404 Where a Client is used by a human Requesting Party or a human 405 Requesting Party Agent, at times human-computer interaction (HCI) 406 will be required, but otherwise the access-attempt transaction is 407 likely to be fully automatic from the perspective of the "requesting 408 side". Furthermore, where the Authorizing Party and the Requesting 409 Party are the same natural person, or where the Authorizing Party has 410 set a policy that requires real-time approval through some out-of- 411 band method, this person can expect to engage in HCI. Otherwise the 412 access-attempt transaction is likely to be fully automatic from the 413 perspective of the "authorizing side" because the access attempt is 414 made without any requirement for the Authorizing Party to be present 415 at run time. 417 The National Strategy for Trusted Identities in Cyberspace [NSTIC] 418 defines some terms similar to those defined here: 420 o "An individual is a person engaged in an online transaction. 421 Individuals are the first priority of the Strategy." 423 o "A non-person entity (NPE) may also require authentication in the 424 Identity Ecosystem. NPEs can be organizations, hardware, 425 networks, software, or services and are treated much like 426 individuals within the Identity Ecosystem. NPEs may engage in or 427 support a transaction." 429 o "The subject of a transaction may be an individual or an NPE." 431 UMA shares with NSTIC a priority to enable and empower individual 432 people in the context of their online interactions. Note that this 433 framework uses the terms Individual, NPE, and Subject exclusively for 434 parties that have the capacity to take on contractual obligations, 435 distinguishing them "from hardware, networks, software, or services", 436 which do not have this capacity. 438 2.1.2. Abbreviations 440 This framework uses the following abbreviations. 442 UMA User-Managed Access, the interoperability protocol defined by in 443 [UMAcore] and the other specifications it includes normatively by 444 reference. 446 API Application programming interface. 448 PAT Protection API token, as defined iin [UMAcore]. 450 AAT Authorization API token, as defined in [UMAcore]. 452 RPT Requesting party token, as defined in [UMAcore]. 454 Comments: Tokens are critical to managing authorization and auditing 455 of resource access. Section 1.3 is recommended reading for 456 understanding what the various tokens represent and how they are 457 issued and used. The RPT, in particular, has a definition that can 458 vary depending on the RPT profile in use; thus, any obligations in 459 this framework that depend on an RPT profile specify it by name. 461 2.2. Obligations of the Requesting Party 463 2.2.1. Requesting Party-Authorizing Party: Adhere-to-Terms 465 When the Client successfully gains access from a Resource Server to a 466 protected resource by wielding a valid "bearer" RPT associated with 467 at least one currently valid permission for the type of access 468 sought, the Requesting Party using that Client gains an obligation to 469 the Authorizing Party to adhere to any terms it agreed to in order to 470 gain the permission. 472 Comments: This key obligation enables the end-to-end access 473 authorization agreement that UMA exists to forge. At a previous 474 stage, the Requesting Party asked for a relevant permission from the 475 Authorization Server and might have had to provide claims of a 476 promissory nature. Accepting access to the protected resource binds 477 the Requesting Party to any terms it agreed to using the claims 478 mechanism, for example, agreeing only to read the resource rather 479 than modifying it, or forbearing from selling the resource data to 480 someone else. 482 Issues: Note that the obligation goes into effect the first time a 483 Client gains access under the power of a "currently valid 484 permission". If there was more than one valid permission attached to 485 different sets of promises, if a secure record was not kept by the 486 Resource Server and/or Authorization Server of which permission was 487 used for granting access, ambiguity is introduced. Defining and 488 using RPT profiles other than the "bearer" profile might lessen the 489 potential ambiguity. 491 2.2.2. Requesting Party-Authorizing Party: Make-Factual-Representations 493 When the Requesting Party provides, or facilitates the sourcing of, 494 claims to an Authorization Server in a claims-gathering flow, the 495 Requesting Party gains an obligation to the Authorizing Party to 496 stand behind any factual representations it makes in order to gain 497 the permission, to the best of its knowledge at the time it makes 498 them. 500 Comments: This obligation is gained during the providing of actual 501 claims, rather than at the time of AAT issuance or protected resource 502 access, because factual claims might age and expire. Where the 503 Requesting Party supplies or sources claims in a manner that can be 504 verified by the Authorization Server, the risk imposed by this need 505 for "trust" can be reduced. Note that UMA defines an optional OpenID 506 Connect claim profile that provides one way to collect trusted claims 507 from third-party claim providers. 509 2.2.3. Requesting Party-Authorization Server Operator: Supply-Truthful- 510 Claims 512 When the Authorization Server issues an AAT to a Client and for as 513 long as the AAT is valid, the Requesting Party using that Client 514 gains an obligation to the Authorization Server Operator to supply or 515 facilitate access to truthful claims required for access 516 authorization at this AM, when it chooses to supply them, to the best 517 of its knowledge at the time it supplies them. 519 Comments: At a later stage, the Requesting Party might be asked to 520 provide claims to support authorization processes at this 521 Authorization Server for accessing _all_ resources protected by this 522 Authorization Server, managed by any Authorizing Parties, at any 523 Resource Servers. The Requesting Party's responsibility to act in 524 good faith in interacting with this Authorization Server begins now 525 because factual claims it supplies could be reused for more than one 526 access-sharing relationship. This obligation can be removed through 527 AAT revocation. 529 2.2.4. Requesting Party-Resource Server Operator: Is-Legitimate-Bearer 531 When the Authorization Server issues an RPT to a Client and for as 532 long as the RPT is valid, the Requesting Party using that Client 533 gains an obligation to the Resource Server Operator to represent the 534 legitimate bearer of the RPT or its authorized representative, and 535 not to allow others to impersonate the Requesting Party. 537 Comments: In the case where the "bearer" RPT profile or any other 538 bearer-style RPT profile is used, the token may not be bound in any 539 technically confirmable way to the specific client and requesting 540 party it applies to. Defining and using different UMA token profiles 541 can mitigate the risk of failure or malice on the Requesting Party's 542 part. The "authorized representative" phrase is intended to clear 543 the way for token-chaining profiles or similar. 545 2.3. Obligations of the Resource Server Operator 547 2.3.1. Resource Server Operator-Authorizing Party: Delegate-Protection 549 When the Authorization Server issues a PAT to a Resource Server and 550 as long as the PAT is valid, the Resource Server Operator gains an 551 obligation to the Authorizing Party to delegate protection services 552 to the Authorization Server Operator for the set of protectable 553 resources for which it represents this capability to the Authorizing 554 Party, and to respect the authorization data that the Authorization 555 Server has associated with an RPT when the Resource Server 556 subsequently allows or disallows access by the Client that presented 557 that RPT. 559 Comments: Once the Authorization Server Operator becomes the 560 Authorizing Party's authorization proxy, it begins relying on the 561 Resource Server Operator in other, more specific ways. The Resource 562 Server has the opportunity to inspect AM-issued permissions or take 563 other actions that delegate protection responsibility to the 564 Authorization Server at a later stage, but its responsibility for 565 respecting them begins now. The specific protection services made 566 available to the Resource Server by the Authorization Server differ 567 depending on the RPT profile in use. This obligation can be removed 568 through PAT revocation. 570 2.3.2. Resource Server Operator-Authorization Server Operator: 571 Register-Accurately-and-Timely 573 When the Authorization Server issues a PAT to the Resource Server and 574 as long as the PAT is valid, the Resource Server Operator gains an 575 obligation to the Authorization Server Operator to register resource 576 set descriptions accurately and timely according to the Authorizing 577 Party's expressed instructions for protection. 579 Comments: At a later stage, the Resource Server has the opportunity 580 to register resource sets, but its responsibility for performing this 581 task begins now. The Resource Server Operator may have contracted 582 with the Authorizing Party for service-level agreements to respond 583 specifically to timeliness needs and so on. This obligation can be 584 removed through PAT revocation. 586 2.3.3. Resource Server Operator-Authorization Server Operator: Respect- 587 Permissions 589 When the Resource Server successfully introspects a "bearer" RPT, the 590 Resource Server Operator gains an obligation to the Authorization 591 Server Operator to respect the permissions that the Authorization 592 Server has associated with the RPT when the Resource Server 593 subsequently allows or disallows access by the Client that presented 594 that RPT. 596 Comments: The Resource Server Operator, as a Subject that is 597 otherwise potentially not obligated to the Authorization Server 598 Operator, carries a great deal of responsibility here not to allow 599 access where the Authorization Server has not granted permission and 600 to make every effort to grant access where the Authorization Server 601 has granted permission. Its interpretation of scopes and permissions 602 is not directly auditable by the Authorization Server. Further, 603 issues can arise from the skew between permission validity periods 604 and actual access. Defining and using different RPT profiles can 605 mitigate the risk of failure or malice on the Resource Server 606 Operator's part. 608 2.3.4. Resource Server Operator-Requesting Party: Give-Accurate-Access 610 When the Resource Server responds in any fashion to a Client's access 611 request, the Resource Server Operator gains an obligation to the 612 Requesting Party to give accurate access to the protected resource 613 according to whether the Requesting Party has permission to do so. 615 Comments: The Resource Server Operator, as a Subject that is 616 otherwise potentially not obligated to the Authorization Server 617 Operator, carries a great deal of responsibility here to make every 618 effort to grant access where the Authorization Server has associated 619 authorization data to guide access. Its interpretation of scopes and 620 permissions, particularly in the case where the RPT presented by the 621 Client uses the "bearer" RPT profile, is not entirely auditable by 622 the requester or Authorization Server. Further, issues can arise 623 from the skew between permission validity periods and actual access. 625 Defining and using different RPT profiles can mitigate the risk of 626 failure on the Resource Server Operator's part. 628 Issues: The relying party traditionally always has the right of 629 refusal. The resource server may have additional authorization 630 context available only to it that suggests it should not grant 631 access, for example. Should this obligation be struck? 633 2.4. Obligations of the Authorization Server Operator 635 2.4.1. Authorization Server Operator-Authorizing Party: Follow- 636 Policies-Accurately-and-Timely 638 When the Authorization Server issues a PAT to the Resource Server and 639 as long as the PAT is valid, the Authorization Server Operator gains 640 an obligation to the Authorizing Party to adhere to the Authorizing 641 Party's policies accurately and timely in granting permissions. 643 Comments: At a later stage, the Authorization Server will require the 644 Resource Server to present the PAT whenever it uses the Authorization 645 Server's protection API on behalf of this Authorizing Party. The 646 Authorization Server Operator may have contracted with the 647 Authorizing Party for service-level agreements to respond 648 specifically to timeliness needs and so on. This obligation can be 649 removed through PAT revocation. 651 2.4.2. Authorization Server Operator-Resource Server Operator: Follow- 652 Policies-Accurately-and-Timely 654 When the Resource Server registers a requested permission at the 655 Authorization Server, the Authorization Server Operator gains an 656 obligation to the Resource Server Operator to adhere to the 657 Authorizing Party's authorization policies accurately and timely in 658 associating authorization data with RPTs presented with the 659 registered permission's ticket. 661 Comments: At a later stage, when a Client approaches the 662 Authorization Server presenting an RPT and a permission ticket, the 663 Authorization Server matches Authorizing Party policies to the 664 requested permission to drive any requests for claims and ultimate 665 authorization processes, but its responsibility for performing this 666 task begins now. 668 2.4.3. Authorization Server Operator-Requesting Party: Request-Limited- 669 Claims 671 When the Authorization Server issues an AAT to a Client and as long 672 as the AAT is valid, the Authorization Server Operator gains an 673 obligation to the Requesting Party to request only claims that 674 support the purpose of satisfying an Authorizing Party's policy. 676 Comments: At a later stage, the Authorization Server might ask the 677 Requesting Party to provide claims for specific permission purposes 678 at multiple Resource Servers and/or for multiple Authorizing Parties, 679 but its responsibility begins now. This obligation can be removed 680 through AAT revocation. 682 2.5. Obligations of the Authorizing Party 684 2.5.1. Authorizing Party-Requesting Party: Adhere-to-Terms 686 When the Authorization Server responds positively to a Client's 687 request for authorization, the Authorizing Party gains an obligation 688 to the Requesting Party using that Client to adhere to the terms 689 offered to and accepted by the Requesting Party in the form of 690 requests for claims driven by the Authorizing Party's policy at the 691 Authorization Server. 693 Comments: For example, the Authorizing User cannot subsequently 694 protest or sue the Requesting Party for resale of the user's data if 695 this was allowed by the terms of access authorization. 697 2.5.2. Authorizing Party-Authorization Server Operator: Introduce- 698 Resource-Server 700 When the Authorization Server issues a PAT to a Resource Server and 701 as long as the PAT is valid, the Authorizing Party gains an 702 obligation to the Authorization Server Operator to introduce the 703 desired Resource Server to this Authorization Server in outsourcing 704 protection of this Resource Server's resources. 706 Comments: How the Resource Server learned of the Authorization 707 Server's location is out of band for UMA; it is the Authorizing 708 Party's responsibility to check that it has been redirected to an 709 acceptable Authorization Server before the Authorization Server 710 successfully issues the PAT. This obligation can be removed through 711 PAT revocation. 713 2.5.3. Authorizing Party-Resource Server Operator: Introduce- 714 Authorization-Server 716 When the Authorization Server issues a PAT to a Resource Server and 717 as long as the PAT is valid, the Authorizing Party gains an 718 obligation to the Resource Server Operator to introduce the desired 719 Authorization Server to this Resource Server in outsourcing 720 protection of this Resource Server's resources. 722 Comments: Once the Authorization Server Operator becomes the 723 Authorizing Party's authorization proxy, the Resource Server Operator 724 begins relying on it in other, more specific ways. How the 725 Authorizing Party indicated the desired Authorization Server to the 726 host is out of band for UMA; it is the Authorizing Party's 727 responsibility to check that it has been redirected to an acceptable 728 Authorization Server before the Authorization Server successfully 729 issues the PAT. This obligation can be removed through PAT 730 revocation. 732 3. Acknowledgments 734 The current editor of this document is Eve Maler of XMLgrrl.com. The 735 following people are co-authors: 737 o Domenico Catalano, Oracle Corp. 739 o Kevin Cox, Edentiti 741 o Sal D'Agostino, IDmachines 743 o Susan Morrow, Avoco Secure 745 o Dazza Greenwood, Civics.com 747 Additional contributors to this document include the Kantara UMA Work 748 Group participants, a list of whom can be found at [UMAnitarians]. 749 The co-authors and contributors thank Scott David, Dazza Greenwood, 750 and Tom Smedinghoff for offering their legal expertise and insight in 751 the preparation of this document. 753 4. References 755 4.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [UMAcore] Hardjono, T., "User-Managed Access (UMA) Profile of OAuth 761 2.0", December 2012, 762 . 764 4.2. Informative References 766 [NSTIC] US Federal Government, "National Strategy for Trusted 767 Identities in Cyberspace", April 2011, 768 . 771 [UETA] Smedinghoff, T., "Uniform Electronic Transactions Act", 772 1999, 773 . 776 [UMAFAQ-swim] 777 US Federal Government, "UMA Frequently Asked Questions: 778 What is the UMA protocol flow?", January 2013, 779 . 782 [UMAnitarians] 783 Maler, E., "UMA Participant Roster", 2012, 784 . 787 Appendix A. Document History 789 NOTE: To be removed by RFC editor before publication as an RFC. 791 Authors' Addresses 793 Eve Maler (editor) 794 ForgeRock 796 Email: eve.maler@forgerock.com 798 Thomas Hardjono 799 MIT 801 Email: hardjono@mit.edu