idnits 2.17.00 (12 Aug 2021) /tmp/idnits36974/draft-hardt-xauth-protocol-00.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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 48 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 173: '... Client MAY be interacting with a...' RFC 2119 keyword, line 179: '...ent. The Client MUST be interacting w...' RFC 2119 keyword, line 381: '... REQUIRED....' RFC 2119 keyword, line 386: '... REQUIRED. Note the completion resp...' RFC 2119 keyword, line 391: '...he client object MUST contain either t...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 January 2020) is 845 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDC' -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Hardt, Ed. 3 Internet-Draft SignIn.Org 4 Intended status: Standards Track 27 January 2020 5 Expires: 30 July 2020 7 The XAuth Protocol 8 draft-hardt-xauth-protocol-00 10 Abstract 12 Client software often desires resources or identity claims that are 13 managed independent of the client. This protocol allows a user and/ 14 or resource owner to delegate resource authorization and/or release 15 of identity claims to an authorization server. Client software can 16 then request access to resources and/or identity claims by calling 17 the authorization server. The authorization server acquires consent 18 and authorization from the user and/or resource owner if required, 19 and then returns the authorization and identity claims that were 20 approved. This protocol can be extended to support alternative 21 client authentication mechanisms, authorizations, claims, and 22 interactions. 24 [Editor: suggestions on how to improve this are welcome!] 26 [Editor: suggestions for other names than XAuth are welcome!] 28 Note to Readers 30 Source for this draft and an issue tracker can be found at 31 https://github.com/dickhardt/hardt-xauth-protocol 32 (https://github.com/dickhardt/hardt-xauth-protocol). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 30 July 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Parties . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Handles . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.3. Reused Terms . . . . . . . . . . . . . . . . . . . . . . 5 71 2.4. Sequence . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Initiation Request JSON . . . . . . . . . . . . . . . . . . . 7 73 3.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 9 74 3.2. "client" Object . . . . . . . . . . . . . . . . . . . . . 9 75 3.3. "user" Object . . . . . . . . . . . . . . . . . . . . . . 11 76 3.4. "authorizations" Object . . . . . . . . . . . . . . . . . 11 77 3.5. "claims" Object . . . . . . . . . . . . . . . . . . . . . 12 78 3.6. Authorization Types . . . . . . . . . . . . . . . . . . . 12 79 4. Initiation Response JSON . . . . . . . . . . . . . . . . . . 12 80 4.1. "user" Object . . . . . . . . . . . . . . . . . . . . . . 13 81 4.2. "interaction" Object . . . . . . . . . . . . . . . . . . 13 82 4.3. "completion" Object . . . . . . . . . . . . . . . . . . . 14 83 5. Interaction Types . . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. "popup" Type . . . . . . . . . . . . . . . . . . . . . . 14 85 5.2. "redirect" Type . . . . . . . . . . . . . . . . . . . . . 14 86 5.3. "qrcode" Type . . . . . . . . . . . . . . . . . . . . . . 15 87 6. Completion Response JSON . . . . . . . . . . . . . . . . . . 15 88 6.1. Top Level Attributes . . . . . . . . . . . . . . . . . . 16 89 6.2. "authorizations" Object . . . . . . . . . . . . . . . . . 16 90 6.3. "claims" Object . . . . . . . . . . . . . . . . . . . . . 17 91 6.4. Access Types . . . . . . . . . . . . . . . . . . . . . . 18 92 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 8. JOSE Client Authentication . . . . . . . . . . . . . . . . . 18 94 8.1. JOSE Headers . . . . . . . . . . . . . . . . . . . . . . 19 95 8.2. JOSE Completion Token . . . . . . . . . . . . . . . . . . 21 96 8.3. JOSE Refresh Token . . . . . . . . . . . . . . . . . . . 22 97 8.4. JOSE Access Token . . . . . . . . . . . . . . . . . . . . 23 98 8.5. HTTP Authorization JOSE Header . . . . . . . . . . . . . 23 99 8.6. JOSE Token Verification . . . . . . . . . . . . . . . . . 23 100 8.7. Initiation Request . . . . . . . . . . . . . . . . . . . 23 101 8.8. Initiation Response . . . . . . . . . . . . . . . . . . . 24 102 8.9. Deletion Request . . . . . . . . . . . . . . . . . . . . 24 103 8.10. Completion Request . . . . . . . . . . . . . . . . . . . 24 104 8.11. Completion Response . . . . . . . . . . . . . . . . . . . 25 105 8.12. Bearer Token RS Access . . . . . . . . . . . . . . . . . 25 106 8.13. Proof-of-possession RS Access . . . . . . . . . . . . . . 26 107 8.14. Access Refresh . . . . . . . . . . . . . . . . . . . . . 26 108 9. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 27 109 10. AS Initiated Sequence . . . . . . . . . . . . . . . . . . . . 27 110 10.1. Initiation Token . . . . . . . . . . . . . . . . . . . . 28 111 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29 112 12. Rational . . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 114 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 115 15. Security Considerations . . . . . . . . . . . . . . . . . . . 32 116 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 16.1. Normative References . . . . . . . . . . . . . . . . . . 33 118 16.2. Informative References . . . . . . . . . . . . . . . . . 34 119 Appendix A. Document History . . . . . . . . . . . . . . . . . . 35 120 A.1. draft-hardt-xauth-protocol-00 . . . . . . . . . . . . . . 35 121 Appendix B. Comparison with OAuth 2.0 and OpenID Connect . . . . 35 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 124 1. Introduction 126 This protocol supports the widely deployed use cases supported by 127 OAuth 2.0 [RFC6749] & [RFC6750], and OpenID Connect [OIDC], an 128 extension of OAuth 2.0, as well as other extensions, and other use 129 cases that are not supported, such as requesting multiple 130 authorizations in one request. This protocol also addresses many of 131 the security issues in OAuth 2.0 by having parameters securely sent 132 directly between parties, rather than via a browser redirection. 134 The technology landscape has changed since OAuth 2.0 was initially 135 drafted. More interactions happen on mobile devices than PCs. 136 Modern browsers now directly support asymetric cryptographic 137 functions. Standards have emerged for signing and encrypting tokens 138 with rich payloads (JOSE) that are widely deployed. 140 Additional use cases are now being served with extensions to OAuth 141 2.0: OpenID Connect added support for authentication and releasing 142 identity claims; [RFC8252] added support for native apps; [RFC8628] 143 added support for smart devices; and support for [browser_based_apps] 144 is being worked on. There are numerous efforts on adding proof-of- 145 possession to resource access. 147 This protocol simplifies the overall architectural model, takes 148 advantage of today's technology landscape, provides support for all 149 the widely deployed use cases, and offers numerous extension points. 151 While this protocol is not backwards compatible with OAuth 2.0, it 152 strives to minimize the migration effort. 154 2. Protocol 156 2.1. Parties 158 * *Authorization Server* (AS) - manages Client authorization to API 159 resources and release of identity claims about the User. The AS 160 may require explicit consent from the RO or User to provide these 161 to the Client. 163 * *Client* - requests authorization to API resources, and/or 164 identity claims about the User. There are two types of Clients: 165 Registered Clients and Dynamic Clients. An AS may support only 166 one or both types. All Clients have a key to authenticate with 167 the AS. 169 * *Registered Client* - a Client that has registered with the AS and 170 has a Client ID to identify itself, and can prove it possesses a 171 key that is linked to the Client ID. The AS may have different 172 policies for what different Registered Clients can request. The 173 Client MAY be interacting with a User. 175 * *Dynamic Client* - a Client that has not been registered with the 176 AS, and each instance will generate it's own key pair so it can 177 prove it is the same instance of the Client on subsequent 178 requests. A single-page application with no server is an example 179 of a Dynamic Client. The Client MUST be interacting with a User. 181 * *User* - the person who has delegated making identity claims about 182 themselves to the AS, and is interacting with the Client. 184 * *Resource Server* (RS) - has API resources that require an access 185 token from the AS for access. 187 * *Resource Owner* (RO) - owns the RS, and has delegated RS access 188 token creation to the AS. The RO may be the same entity as the 189 User, or may be a different entity that the AS interacts with 190 independent of the Client. 192 2.2. Handles 194 Handles are strings issued by the AS to the Client, that are opaque 195 to the Client. 197 * *completion handle* - represents the client request. Presented 198 back to the AS in a completion request. 200 * *access handle* - represents the access the AS has granted the 201 Client to the RS. The Client proves possession of its key when 202 presenting an access handle to access an RS. The RS is able to 203 understand the authorizations represented by the access handle 204 directly, or through an introspection call. The RS is able to 205 verify the access handle was issued to the Client that presented 206 it. 208 * *refresh handle* - represents the access the AS has granted the 209 Client to a RS. Presented back to the AS when the Client wants a 210 fresh access token or access handle. 212 When presenting any of the above handles, the Client always proves 213 possession of its key. 215 2.3. Reused Terms 217 * *access token* - an access token as defined in [RFC6749] 218 Section 1.4. 220 * *Claims* - Claims as defined in [OIDC] Section 5. 222 * *Client ID* - an AS unique identifier for a Registered Client as 223 defined in [RFC6749] Section 2.2. 225 * *ID Token* - an ID Token as defined in [OIDC] Section 2. 227 * *Claims* - Claims as defined in [OIDC] Section 5. 229 * *NumericDate* - a NumericDate as defined in [RFC7519] Section 2. 231 2.4. Sequence 233 1. *AS Discovery* The Client discovers the AS end point, keys, 234 supported claims and authorizations, and other capabilities. 235 Some, or all of this information could be manually preconfigured, 236 or dynamically obtained. Dynamic AS discovery is out of scope of 237 this document. 239 2. *Initiation Request* (Section 8.7) The Client creates an 240 initiation request (Section 3) for authorization to API resources 241 and/or identity claims about the User and sends it with an HTTP 242 POST to the AS endpoint. 244 3. *Initiation Response* (Section 8.8) The AS processes the request 245 and determines if it needs to interact with the RO or User. If 246 interaction is not required, the AS returns a completion response 247 (Section 6). If interaction is required the AS returns an 248 initiation response (Section 4) that includes completion handle 249 and uri, and interaction instructions if the AS wants the Client 250 to start the interaction. 252 4. *Interaction* (Section 5) If the AS sent interaction instructions 253 to the Client, the Client executes them. The AS then interacts 254 with the User and/or RO to obtain authorization. The AS 255 interaction with an RO may be asynchronous, and take time to 256 complete. 258 5. *Completion Request* (Section 8.10) The Client sends the 259 completion handle to the completion uri. The Client may make the 260 completion request while waiting for the interaction to complete. 262 6. *Completion Response* (Section 8.11) When any required 263 interaction has been completed, the AS responds to the Client 264 with a completion response (Section 6) containing authorized RS 265 access tokens and User identity claims. The AS may provide 266 refresh handles and uris for each access token if they are 267 authorized. If proof-of-possession is required for accessing the 268 RS, the AS will provide access handles instead of access tokens. 269 If the AS has not completed the interaction, it will return a 270 retry response for the Client to make a new completion request. 272 7. *Resource Request* (Section 8.12 & Section 8.13) The Client uses 273 an access token with the RS, or the access handle if proof-of- 274 possession is required for access. 276 8. *Access Refresh* (Section 8.14) If the Client received a refresh 277 handle and uri, it sends the refresh handle to the refresh uri, 278 and receives a fresh access token or handle. 280 *Sequence Diagram* 281 +--------+ +---------------+ 282 | |<-(1)------- Discovery ------------------->| | 283 | | | | 284 | |--(2)------- Initiation Request ---------->| | 285 | | | | 286 | |<-(3)------- Initiation Response-----------| | 287 | | | | 288 | | +-Interaction-+ | | 289 | |--(4)-------->| User |<-------------| | 290 | | | and/or RO |<-------------| | 291 | | +-------------+ | Authorization | 292 | Client | | Server | 293 | |--(5)------- Completion Request ---------->| | 294 | | | | 295 | |<-(6)------- Completion Response ----------| | 296 | | | | 297 | | +----------+ | | 298 | |--(7)-- Resource Request -->| Resource | | | 299 | | | Server | | | 300 | |<------ Resource Response --| | | | 301 | | +----------+ | | 302 | | | | 303 | |--(8)------- Refresh Request ------------->| | 304 | | | | 305 | |<----------- Refresh Response -------------| | 306 +--------+ +---------------+ 308 3. Initiation Request JSON 310 Following is a non-normative JSON [RFC8259] document example where 311 the Client wants to interact with the User with a popup and is 312 requesting identity claims about the User and read access to the 313 User's contacts: 315 Example 1 317 { 318 "as" :"https://as.example", 319 "iat" :"1579046092", 320 "nonce" :"f6a60810-3d07-41ac-81e7-b958c0dd21e4", 321 "client": { 322 "display": { 323 "name" :"SPA Display Name", 324 "uri" :"https://spa.example/about" 325 }, 326 "interaction": { 327 "type" :"popup" 328 } 329 }, 330 "authorizations": { 331 "type" :"oauth_scope", 332 "scope" :"read_contacts" 333 }, 334 "claims": { 335 "oidc": { 336 "id_token" : { 337 "email" : { "essential" : true }, 338 "email_verified" : { "essential" : true } 339 }, 340 "userinfo" : { 341 "name" : { "essential" : true }, 342 "picture" : null 343 } 344 } 345 } 346 } 348 Following is a non-normative example where the Client has previously 349 authenticated the User, and is requesting additional authorization: 351 Example 2 353 { 354 "as" :"https://as.example", 355 "iat" :"1579046092", 356 "nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b", 357 "client": { 358 "id" : "di3872h34dkJW", 359 "interaction": { 360 "type" : "redirect", 361 "uri" : "https://web.example/return" 362 } 363 }, 364 "user": { 365 "identifiers": { 366 "oidc": { 367 "iss" :"https://as.example", 368 "sub" :"123456789" 369 } 370 } 371 }, 372 "authorizations": { 373 "type" :"oauth_scope", 374 "scope" :"read_calendar write_calendar" 375 } 376 } 378 3.1. Top Level Attributes 380 *as* - the unique string identifier for the AS. This attribute is 381 REQUIRED. 383 *iat* - the time of the request as a NumericDate. 385 *nonce* - a unique identifier for this request. This attribute is 386 REQUIRED. Note the completion response MUST contain a matching nonce 387 attribute. 389 3.2. "client" Object 391 The client object MUST contain either the client_id attribute for 392 Registered Clients, or the display object for Dynamic Clients. If 393 the Client can interact with the User, then an interaction object 394 MUST be included. 396 *client_id* - the identifier the AS has for the Registered Client. 398 *display* - the display object contains the following attributes: 400 * *name* - a string that represents the Dynamic Client 402 [Editor: a max length for the name?] 404 * *uri* - a URI representing the Dynamic Client 406 [Editor: a max length for the name?] 408 The name and uri will be displayed by the AS when prompting for 409 authorization. 411 *interaction* - the interaction object contains the type of 412 interaction the Client will provide the User. Other attributes are 413 dependent on the interaction type value. 415 * *type* - contains one of the following values. Types are listed 416 from highest to lowest fidelity. The interaction URI is the value 417 returned by the AS in the initiation response interaction object 418 Section 4.2, if a User interaction is required by the AS. 420 - *popup* - the Client will load the interaction URI in a modal 421 popup window. The AS will close the window when the 422 interaction is complete. 424 - *redirect* - the Client will redirect the user agent to the 425 interaction URI provided by the AS. The AS will redirect to 426 the redirect_uri when the interaction is completed. 428 - *qrcode* - the Client will convert the interaction URI to a QR 429 Code per [QR_Code] and display it to the User, along with a 430 text message. The User will scan the QR Code and/or follow the 431 message instructions. 433 * *redirect_uri* - this attribute is included if the type is 434 "redirect". It is the URI that the Client requests the AS to 435 redirect the User to after the AS has completed interacting with 436 the User. If the Client manages session state in URIs, then the 437 redirect_uri should contain that state. 439 * *ui_locales* - End-User's preferred languages and scripts for the 440 user interface, represented as a space-separated list of [RFC5646] 441 language tag values, ordered by preference. 443 [Editor: do we need max pixels or max chars for qrcode interaction? 444 Either passed to AS, or max specified values here?] 446 [Editor: other possible interaction models could be a "webview", 447 where the Client can display a web page, or just a "message", where 448 the client can only display a text message] 450 [Editor: we may need to include interaction types for iOS and Android 451 as the mobile OS APIs evolve.] 453 [Editor: does the Client include parameters if it wants the 454 completion response signed and/or encrypted?] 456 3.3. "user" Object 458 The user object is optional. 460 *identifiers* - the identifiers object contains one or more of the 461 following identifiers for the User: 463 * *phone_number* - contains a phone number per Section 5 of 464 [RFC3966]. 466 * *email* - contains an email address per [RFC5322]. 468 * *oidc* - is an object containing both the "iss" and "sub" 469 attributes from an OpenID Connect ID Token per [OIDC] Section 2. 471 The user and identifiers objects MAY be included to improve the user 472 experience by the AS. The AS MUST authenticate the User independent 473 of these values. 475 *discovery* - MUST contain the JSON true value. Indicates the Client 476 requests the AS to return a "discovered" attribute in the initiation 477 response if the AS has a User at the AS with one or more of the 478 identifiers. This attribute is OPTIONAL. Supporting by the AS of 479 the discovery attribute is OPTIONAL. The AS MAY return the TBD error 480 if discovery is not supported, or ignore the request. 482 3.4. "authorizations" Object 484 The optional authorizations object contains a dictionary of resource 485 objects the Client is requesting authorization to access. The 486 authorizations object may contain one or more of: 488 * *type* - one of the following values: "oauth_scope", "oauth_rich", 489 or "oauth_rich_list". See Section 3.6 for details. 491 * *scope* - a string containing the OAuth 2.0 scope per [RFC6749] 492 section 3.3. Present if type is "oauth_scope" or "oauth_rich". 494 * *authorization_details* - an authorization_details object per 495 [RAR]. Present if type is "oauth_rich". 497 * *list* - an array of objects containing "scope" and 498 "authorization_details". Present if type is "oauth_rich_list". 499 Used when requesting multiple access tokens and/or handles. 501 [Editor: details may change as the [RAR] document evolves] 503 3.5. "claims" Object 505 The optional claims object contains one or more identity claims being 506 requested. The claims may contain: 508 * *oidc* - an object that contains one or both of the following 509 objects: 511 - *userinfo* - Claims that will be returned as a JSON object 513 - *id_token* - Claims that will be included in the returned ID 514 Token. If the null value, an ID Token will be returned 515 containing no additional Claims. 517 The contents of the userinfo and id_token objects are Claims as 518 defined in [OIDC] Section 5. 520 * vc - [Editor: define how W3C Verifiable Credentials [W3C_VC] can 521 be requested.] 523 3.6. Authorization Types 525 * *oauth_scope* - an OAuth 2.0 authorization request per [RFC6749] 526 section 3.3 528 * *oauth_rich* - a rich authorization request per [RAR] 530 * *oauth_rich_list* - a list of rich authorization requests 532 4. Initiation Response JSON 534 A non-normative example of an initiation response follows: 536 { 537 "user": { 538 "discovered": true 539 }, 540 "interaction": { 541 "type" : "popup", 542 "uri" : "https://as.example/endpoint/ey5gs32..." 543 }, 544 "completion": { 545 "handle" : "eyJhb958.example.completion.handle.9yf3szM", 546 "uri" : "https://as.example/completion/ey7snHGs", 547 "wait" : "10" 548 } 549 } 551 4.1. "user" Object 553 If the initiation request included a discovery attribute, then the AS 554 MAY return a "user" object with the "discovered" property set to the 555 JSON value true if one or more of the identifiers provided in the 556 initiation request identify a User at the AS, or the JSON value false 557 if not. 559 [Editor: reference a security consideration for this functionality.] 561 4.2. "interaction" Object 563 If the AS wants the Client to start the interaction, the AS MUST 564 select one of the interaction mechanisms provided by the Client in 565 the initiation request, and include the matching attribute in the 566 interaction object: 568 * *type* - this MUST match the type provided by the Client in the 569 initiation request client.interaction object. 571 * *uri* - the URI to interact with the User per the type. This may 572 be a temporary short URL if the type is qrcode so that it is easy 573 to scan. 575 * *message* - a text string to display to the User if type is 576 qrcode. 578 [Editor: do we specify a maximum length for the uri and message so 579 that a device knows the maximum it needs to support? A smart device 580 may have limited screen real estate.] 582 4.3. "completion" Object 584 The completion object has the following attributes: 586 * *handle* - the completion handle. This attribute is REQUIRED. 588 * *uri* - the completion URI. This attribute is REQUIRED. 590 * *wait* - the amount of time in integer seconds the Client MUST 591 wait before making the completion request. This attribute is 592 OPTIONAL. 594 5. Interaction Types 596 If the AS wants the Client to initiate the interaction with the User, 597 then the AS will return an interaction object Section 4.2 so that the 598 Client can can hand off interactions with the User to the AS. The 599 Client will initiate the interaction with the User in one of the 600 following ways: 602 5.1. "popup" Type 604 The Client will create a new popup child browser window containing 605 the value of the uri attribute of the interaction object. [Editor: 606 more details on how to do this] 608 The AS will close the window when the interactions with the User are 609 complete. [Editor: confirm AS can do this still on all browsers, or 610 does Client need to close] 612 The AS MAY respond to an outstanding completion request Section 8.10 613 before the popup window has been closed. 615 5.2. "redirect" Type 617 The Client will redirect the User to the value of the uri attribute 618 of the interaction object. When the AS interactions with the User 619 are complete, the AS will redirect the User to the redirect_uri the 620 Client provided in the initiation request. 622 If the Client made a completion request when starting the 623 interaction, the AS MAY respond to the completion request 624 Section 8.10 before the User has been redirected back to the Client. 626 5.3. "qrcode" Type 628 The Client will create a [QR_Code] of the uri attribute of the 629 interaction object and display the resulting graphic and the message 630 attribute of the interaction object as a text string. 632 6. Completion Response JSON 634 Example non-normative completion response JSON document for Example 1 635 in Section 3: 637 { 638 "iat":"15790460234", 639 "nonce":"f6a60810-3d07-41ac-81e7-b958c0dd21e4", 640 "authorizations": { 641 "type" : "oauth_scope", 642 "scope" : "read_contacts", 643 "expires_in" : "3600", 644 "method" : "bearer", 645 "token" : "eyJJ2D6.example.access.token.mZf9p" 646 }, 647 "claims": { 648 "oidc": { 649 "id_token" : "eyJhbUzI1N.example.id.token.YRw5DFdbW", 650 "userinfo" : { 651 "name" : "John Doe", 652 "picture" : "https://photos.example/p/eyJzdkiO" 653 } 654 } 655 } 656 } 658 Example non-normative completion response JSON document for Example 2 659 in Section 3: 661 { 662 "iat" :"15790460234", 663 "nonce" :"0d1998d8-fbfa-4879-b942-85a88bff1f3b", 664 "authorizations": { 665 "type" : "oauth_scope", 666 "scope" : "read_calendar write_calendar", 667 "expires_in" : "3600", 668 "method" : "pop", 669 "access": { 670 "handle" : "ey.example.access.handle.9yf3szM", 671 "jwk": { 672 "x5u" : "https://as.example/jwk/VBUEOIQA82" 673 } 674 }, 675 "refresh": { 676 "handle" : "ey.example.refresh.handle.Jl4FzM", 677 "uri" : "https://as.example/refresh/eyj34" 678 } 679 } 680 } 682 Details of the JSON document: 684 6.1. Top Level Attributes 686 *iat* - the time of the response as a NumericDate. 688 *nonce* - the nonce that was included in the initiation request JSON 689 Section 3. 691 6.2. "authorizations" Object 693 There is an authorizations object in the completion response if there 694 was an authorizations object in the initiation request. 696 * *type* - the type of claim request: "oauth_scope", "oauth_rich", 697 or "oauth_rich_list". See Section 3.6 for details. 699 * *list* - an array of objects if the type was "oauth_rich_list". 700 The objects have the following attributes just as if the type was 701 "oauth_rich" 703 * *scope* - the scopes the Client was granted authorization for. 704 This will be all, or a subset, of what was requested. 706 * *authorization_details* - the authorization details granted. Only 707 returned for "oauth_rich" and "oauth_rich_list". 709 * *method* - the access method: "bearer" or "pop". See Section 6.4 710 for details. 712 * *token* - an access token for accessing the resource(s). Included 713 if the access method is "bearer". 715 * *expires_in* - an optional value specifying how many seconds until 716 the access token or handle expire. 718 * *refresh* - an optional object containing parameters required to 719 refresh an access token or handle. See refresh request 720 Section 8.14. 722 - *handle* - an refresh handle used to create the JSON refresh 723 token. 725 - *uri* - the refresh uri the Client will use to refresh. 727 * *access* - an object containing the parameters needed to access 728 resources requiring proof-of-possession. Included if the access 729 method is "pop". 731 - *handle* - the access handle. 733 - *jwk* - the jwk object to use. 735 6.3. "claims" Object 737 There is a claims object in the completion response if there was a 738 claims object in the initiation request. 740 * *oidc* 742 - *id_token* - an OpenID Connect ID Token containing the Claims 743 the User consented to be released. 745 - *userinfo* - the Claims the User consented to be released. 747 Claims are defined in [OIDC] Section 5. 749 * *vc* 751 The verified claims the user consented to be released. [Editor: 752 details TBD] 754 6.4. Access Types 756 There are two types of access to an RS: 758 * *bearer* - the AS provides a bearer access token that the Client 759 can use to access an RS per Section 8.12. 761 * *pop* - the AS provides an access handle that the Client presents 762 in a proof-of-possession RS access request per Section 8.13. 764 7. Discovery 766 The Client obtains the following metadata about the AS prior to 767 initiating a request: 769 *Endpoint* - the endpoint of the AS. 771 *"as"* - the unique string identifier for the AS. 773 *Algorithms* - the asymetric cryptographic algorithms supported by 774 the AS. 776 *Authorizations* - the authorizations the Client may request, if any. 778 *Identity Claims* - the identity claims the Client may request, if 779 any, and what public keys the claims will be signed with. 781 The client may also obtain information about how the AS will sign 782 and/or encrypt the completion response, as well as any other metadata 783 required for extensions to this protocol, as defined in those 784 extension specifications. 786 8. JOSE Client Authentication 788 The default mechanism for the Client to authenticate to the AS and 789 the RS is signing a JSON document with JWS per [RFC7515]. The 790 resulting tokens always use compact serialization. 792 It is expected that extensions to this protocol that specify a 793 different mechanism for the Client to authenticate, would over ride 794 this section. 796 The completion request JSON is signed with JWS and passed as the body 797 of the POST. 799 The completion, refresh, and access handles are signed with JWS 800 resulting in JOSE completion, refresh, and access tokens 801 respectively. These JOSE tokens are passed in the HTTP Authorization 802 header with the "JOSE" parameter per Section 8.5. 804 The Client will use the same private key to create all tokens. 806 The Client and the AS MUST both use HTTP/2 ([RFC7540]) or later, and 807 TLS 1.3 ([RFC8446]) or later, when communicating with each other. 809 [Editor: too aggressive to mandate HTTP/2 and TLS 1.3?] 811 8.1. JOSE Headers 813 A non-normative example of a JOSE header for a Registered Client 814 using a key id to identify the Client's public key: 816 { 817 "alg":"ES256", 818 "typ":"JOSE", 819 "kid":"1" 820 } 822 A non-normative example of a JOSE header for a Registered Client 823 using a certificate to assert the Client's public key: 825 { 826 "alg":"ES256", 827 "typ":"JOSE", 828 "jwk": 829 {"kty":"RSA", 830 "use":"sig", 831 "kid":"1b94c", 832 "n":"vrjOfz9Ccdgx5nQudyhdoR17V-IubWMeOZCwX_jj0hgAsz2J_pqYW08 833 PLbK_PdiVGKPrqzmDIsLI7sA25VEnHU1uCLNwBuUiCO11_-7dYbsr4iJmG0Q 834 u2j8DsVyT1azpJC_NG84Ty5KKthuCaPod7iI7w0LK9orSMhBEwwZDCxTWq4a 835 YWAchc8t-emd9qOvWtVMDC2BXksRngh6X5bUYLy6AyHKvj-nUy1wgzjYQDwH 836 MTplCoLtU-o-8SNnZ1tmRoGE9uJkBLdh5gFENabWnU5m1ZqZPdwS-qo-meMv 837 VfJb6jJVWRpl2SUtCnYG2C32qvbWbjZ_jBPD5eunqsIo1vQ", 838 "e":"AQAB", 839 "x5c": 840 ["MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJB 841 gNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYD 842 VQQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1 843 wYmVsbDAeFw0xMzAyMjEyMzI5MTVaFw0xODA4MTQyMjI5MTVaMGIxCzAJBg 844 NVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDV 845 QQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1w 846 YmVsbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL64zn8/QnH 847 YMeZ0LncoXaEde1fiLm1jHjmQsF/449IYALM9if6amFtPDy2yvz3YlRij66 848 s5gyLCyO7ANuVRJx1NbgizcAblIgjtdf/u3WG7K+IiZhtELto/A7Fck9Ws6 849 SQvzRvOE8uSirYbgmj6He4iO8NCyvaK0jIQRMMGQwsU1quGmFgHIXPLfnpn 850 fajr1rVTAwtgV5LEZ4Iel+W1GC8ugMhyr4/p1MtcIM42EA8BzE6ZQqC7VPq 851 PvEjZ2dbZkaBhPbiZAS3YeYBRDWm1p1OZtWamT3cEvqqPpnjL1XyW+oyVVk 852 aZdklLQp2Btgt9qr21m42f4wTw+Xrp6rCKNb0CAwEAATANBgkqhkiG9w0BA 853 QUFAAOCAQEAh8zGlfSlcI0o3rYDPBB07aXNswb4ECNIKG0CETTUxmXl9KUL 854 +9gGlqCz5iWLOgWsnrcKcY0vXPG9J1r9AqBNTqNgHq2G03X09266X5CpOe1 855 zFo+Owb1zxtp3PehFdfQJ610CDLEaS9V9Rqp17hCyybEpOGVwe8fnk+fbEL 856 2Bo3UPGrpsHzUoaGpDftmWssZkhpBJKVMJyf/RuP2SmmaIzmnw9JiSlYhzo 857 4tpzd5rFXhjRbg4zW9C+2qok+2+qDM1iJ684gPHMIY8aLWrdgQTxkumGmTq 858 gawR+N5MDtdPTEQ0XfIBc2cJEUyMTY5MPvACWpkA6SdS4xSvdXK3IVfOWA=="] 859 } 860 } 862 [Editor: the jwk above was copy and pasted from the JWK example. 863 Replace? ] 865 The certificate could be signed by the AS, allowing the AS to verify 866 the signature using the AS public key, or the certificate could be 867 signed by a private key the AS has bound to the Registered Client, 868 allowing each instance of the Registered Client to have its own 869 asymetric key pair. 871 A non-normative example of a JOSE header for a Dynamic Client 872 including the public key generated by the Client that matches its its 873 private key: 875 { 876 "alg":"ES256", 877 "typ":"JOSE", 878 "jwk":{ 879 "kty":"EC", 880 "crv":"P-256", 881 "x":"Kgl5DJSgLyV-G32osmLhFKxJ97FoMW0dZVEqDG-Cwo4", 882 "y":"GsL4mOM4x2e6iON8BHvRDQ6AgXAPnw0m0SfdlREV7i4" 883 } 884 } 886 A non-normative example of a JOSE Access Token JOSE header for a 887 Client accessing an RS that requires proof-of-possession: 889 { 890 "alg":"ES256", 891 "typ":"JOSE", 892 "jwk":{ 893 "x5u":"https://as.example/jwk/VBUEOIQA82" 894 } 895 } 897 The "jwk" object in a JOSE access token Section 8.4 MUST be the AS 898 jwk object the AS provided with the access handle. 900 This decouples how the AS communicates the Client's public key to the 901 RS from how the AS asserts the Client's public key. The RS can have 902 a consistent mechanism assert the Client's public key across all 903 Clients. 905 One advantage of this is the AS can create a certificate of a Dynamic 906 Client's public key, and pass it by value or reference to the Client 907 to present to the RS. 909 All JOSE headers MUST have: + the "alg" attribute. + the "typ" 910 attribute set to "jose". + either a "kid" or "jwk" attribute. 912 [Editor: should we use indicate the type of token (completion, 913 refresh, access) using "typ" or "cty"?] 915 8.2. JOSE Completion Token 917 A non-normative example of a payload follows: 919 { 920 "as" :"https://as.example", 921 "type" :"completion", 922 "iat" :"1579046092", 923 "jti" :"f6d72254-4f23-417f-b55e-14ad323b1dc1", 924 "handle":"eyJhb958.example.completion.handle.9yf3szM" 925 } 927 The payload of the completion token contains: 929 *as* - the unique string identifier for the AS. 931 *type* - the string "completion", indicating the type of token. 933 *iat* - the time the completion token was created as a NumericDate. 935 *jti* - a unique identifier for the completion token per [RFC7519] 936 section 4.1.7. 938 *handle* the completion handle the AS provided the Client in the 939 initiation response Section 4. 941 8.3. JOSE Refresh Token 943 A non-normative example of a payload follows: 945 { 946 "as" :"https://as.example", 947 "type" :"refresh", 948 "iat" :"1579049876", 949 "jti" :"4342046d-83c4-4725-8c72-e9a49245f791", 950 "handle":"eyJhb958.example.refresh.handle.9yf3szM" 951 } 953 The payload of the completion token contains: 955 *as* - the unique string identifier for the AS. 957 *type* - the string "refresh", indicating the type of token. 959 *iat* - the time the JOSE refresh token was created as a NumericDate. 961 *jti* - a unique identifier for the JOSE refresh token. 963 *handle* the refresh handle the AS provided the Client in the 964 completion response Section 6 or access refresh response 965 Section 8.14. 967 8.4. JOSE Access Token 969 The "jwk" object in a JOSE access token header MUST be set to the 970 "jwk" value the AS provided for the access handle. 972 A non-normative example of a payload follows: 974 { 975 "type" :"access", 976 "iat" :"1579046092", 977 "jti" :"5ef47057-08f9-4763-be8d-162824d43dfb", 978 "handle":"eyJhb958.example.access.handle.9yf3szM" 979 } 981 The payload of the JOSE access token contains: 983 *type* - the string "access", indicating the type of token. 985 *iat* - the time the JOSE access token was created as a NumericDate. 987 *jti* - a unique identifier for the JOSE access token. 989 *handle* the access handle the AS provided the Client in the 990 completion response Section 6 or access refresh response 991 Section 8.14. 993 8.5. HTTP Authorization JOSE Header 995 The Client authenticates requests by setting the HTTP Authorization 996 header to include the "JOSE" parameter, followed by one or more space 997 characters, followed by the appropriate JOSE token. 999 A non-normative example: 1001 Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW 1003 The JOSE completion token, JOSE refresh token, and the JOSE access 1004 token are all passed in this manner. 1006 8.6. JOSE Token Verification 1008 TBD 1010 8.7. Initiation Request 1012 The Client creates a JSON document per Section 3, signs it using JWS 1013 [RFC7515], and sends the JWS token to the AS end point using HTTP 1014 POST, with a content-type of application/jose. 1016 * *Payload Encryption* 1018 The AS may require the initiation request to be encrypted. If so, 1019 the JWS token is encrypted per JWE [RFC7516] using the public key and 1020 algorithm specified by the AS. 1022 8.8. Initiation Response 1024 If no interaction is required the AS will return a completion 1025 response per Section 8.11, otherwise the AS will return an initiation 1026 response per Section 4. 1028 If the AS wants the Client to start the interaction, an interaction 1029 object will be returned in the response. 1031 * *Error Responses* 1033 The AS MAY respond with one of the following errors defined in 1034 Section 9: 1036 TBD 1038 8.9. Deletion Request 1040 The Client MAY delete an outstanding request using the completion 1041 token by making an HTTP DELETE call to the completion uri, setting 1042 the HTTP Authorization header per Section 8.5 with the JOSE 1043 completion token. 1045 A non-normative deletion request example: 1047 DELETE /completion/ey7snHGs HTTP/2 1048 Host: as.example 1049 Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW 1051 * *Error Responses* 1053 The AS MAY respond with one of the following errors defined in 1054 Section 9: 1056 TBD 1058 8.10. Completion Request 1060 The Client makes an HTTP GET call to the completion uri, setting the 1061 HTTP Authorization header per Section 8.5 with the JOSE completion 1062 token. 1064 A non-normative completion request example: 1066 GET /completion/ey7snHGs HTTP/2 1067 Host: as.example 1068 Authorization: JOSE eyJhb.example.completion.token.haDwskpFDBW 1070 8.11. Completion Response 1072 The AS verifies the JOSE completion token, and then provides a 1073 response according to what the User and/or RO have authorized if 1074 required. If no signature or encryption was required, the AS will 1075 respond with a JSON document with content-type set to application/ 1076 json. 1078 * *Response Signing* 1080 The AS MAY sign the response with a JWS per [RFC7515] and the private 1081 key matching the public key the AS defined as its completion response 1082 signing key. The AS will respond with the content-type set to 1083 application/jose. 1085 * *Response Encryption* 1087 The AS MAY encrypt the response using the public key provided by the 1088 Client, using JWE per [RFC7516]. The AS will respond with the 1089 content-type set to application/jose. 1091 * *Error Responses* 1093 The AS MAY respond with one of the following errors defined in 1094 Section 9: 1096 TBD 1098 8.12. Bearer Token RS Access 1100 If the access method in the completion response authorizations object 1101 Section 6.2 was "bearer", then the Client accesses the RS per 1102 Section 2.1 of [RFC6750] 1104 A non-normative example of the HTTP request headers follows: 1106 GET /calendar HTTP/2 1107 Host: calendar.example 1108 Authorization: bearer eyJJ2D6.example.access.token.mZf9pTSpA 1110 * *Error Responses* 1111 TBD 1113 8.13. Proof-of-possession RS Access 1115 If the access method in the completion response authorizations object 1116 Section 6.2 was "pop", then the Client creates a JOSE access token 1117 per Section 8.4 for each call to the RS, setting the HTTP 1118 Authorization header per Section 8.5 with the JOSE access token. 1120 A non-normative example of the HTTP request headers follows: 1122 GET /calendar HTTP/2 1123 Host: calendar.example 1124 Authorization: JOSE eyJhbG.example.JOSE.access.token.kwwQb958 1126 * *Error Responses* 1128 TBD 1130 8.14. Access Refresh 1132 If the Client received a refresh handle and uri from the AS in the 1133 initiation response, and it wants a fresh access token or handle, it 1134 creates a JOSE refresh token per Section 8.3. setting the HTTP 1135 Authorization header per Section 8.5 with the JOSE refresh token. 1136 The AS will then respond with a refresh response. 1138 * *Refresh Response* 1140 A non-normative example refresh response with an access handle: 1142 { 1143 "type" : "oauth_scope", 1144 "scope" : "read_calendar write_calendar", 1145 "expires_in" : "3600", 1146 "method" : "pop", 1147 "access": { 1148 "handle" : "ey.example.access.handle.9yf3iWszM", 1149 "jwk": { 1150 "x5u" : "https://as.example/jwk/VBUEOIQA82" 1151 } 1152 }, 1153 "refresh": { 1154 "handle" : "ey.example.refresh.handle.4SkjIi", 1155 "uri" : "https://as.example/refresh/eyJl4FzM" 1156 } 1157 } 1158 The refresh response is the same as the authorizations object 1159 Section 6.2 in the completion response. 1161 If a new refresh handle and/or refresh uri is returned, the Client 1162 MUST use the new refresh handle and/or refresh uri 1164 [Editor: are there other results relevant for [RAR]?] 1166 * *Error Responses* 1168 The AS MAY respond with one of the following errors defined in 1169 Section 9: 1171 TBD 1173 9. Error Messages 1175 \[Editor: return "wait" time in completion response when AS wants Client to wait before retying a completion request. 1176 The Client MUST generate a fresh completion token when retrying the completion request. 1177 ] 1179 TBD 1181 10. AS Initiated Sequence 1183 [Editor: AS initiated flows have been challenging to implement as 1184 OAuth 2.0 did not directly support them, so deployments bounced back 1185 and forth between the Client and AS to create a Client initiated 1186 flow. Here is a proposal to support AS initiated: authentication; 1187 just-in-time (JIT) provisioning; and authorization] 1189 In this sequence the User starts at the AS, and then based on User 1190 input, the AS redirects the User to a Client, passing an initiation 1191 token Section 10.1, and then the Client retrieves authorizations and/ 1192 or identity claims about the User. The Client MUST be a Registered 1193 Client. The sequence follows: 1195 1. The User is interacting at the AS and wants to use the Client, 1196 and provide the Client identity claims and/or authorizations from 1197 the AS that the Client has pre-configured. 1199 2. The AS creates a completion handle and uri representing the 1200 identity claims and authorizations to be provided to the Client. 1201 The AS creates an initiation token containing the AS identifier, 1202 the completion handle, and the completion uri. 1204 3. The AS redirects the User to a URI the Client has configured to 1205 accept initiation tokens, passing the initiation token as a query 1206 parameters with the name "token". 1208 4. The Client verifies the initiation token. 1210 5. The Client makes a completion request per Section 8.10. 1212 6. The AS responds with a completion response JSON document 1213 Section 6 per Section 8.11. 1215 The Client now has the User identity claims and/or authorizations. 1216 If Client policy permits, the Client can perform JIT provisioning if 1217 the User is new to the Client. 1219 *AS Initiated Sequence Diagram* 1221 +--------+ +-------------+ +---------------+ 1222 | | | | | | 1223 | | | User |-------(1)-->| | 1224 | | | | | | 1225 | | +-------------+ | (2) | 1226 | | /\ | | 1227 | Client |<--- initiation ---/ \-------------(3)---| Authorization | 1228 | | token | Server | 1229 | (4) | | | 1230 | | | | 1231 | |--(5)------- Completion Request --------->| | 1232 | | | | 1233 | |<-(6)------- Completion Response ---------| | 1234 | | | | 1235 +--------+ +---------------+ 1237 10.1. Initiation Token 1239 A non-normative example of an initiation token payload follows: 1241 { 1242 "as": "https://as.example", 1243 "completion": { 1244 "handle" : "eyJhb958.example.completion.handle.9yf3szM", 1245 "uri" : "https://as.example/completion/ey7snHGs" 1246 } 1247 } 1249 * *as* - the "as" identifier for the AS. This attribute is 1250 REQUIRED. 1252 * *completion* - the completion object has the following attributes: 1254 - *handle* - the completion handle. This attribute is REQUIRED. 1256 - *uri* - the completion URI. This attribute is REQUIRED. 1258 The initiation token is signed with JWS and uses the compact 1259 serialization. 1261 11. Extensibility 1263 This standard can be extended in a number of areas: 1265 * *Client Authentication Mechanisms* 1267 An extension could define other mechanisms for the Client to 1268 authenticate and replace JOSE in Section 8 with Mutual TLS or HTTP 1269 Signing. Constrained environments could use CBOR [RFC7049] instead 1270 of JSON, and COSE [RFC8152] instead of JOSE, and CoAP [RFC8323] 1271 instead of HTTP/2. 1273 * *Initiation Request* 1275 An additional top level object could be added to the initiation 1276 request payload if the AS can manage delegations other than 1277 authorizations or claims, or some other functionality. 1279 * *"client" Object* 1281 Additional information about the Client that the AS would require 1282 related to an extension. 1284 * *"user" Object* 1286 Additional information about the Client that the AS would require 1287 related to an extension. 1289 * *"authorizations" Object* 1291 Additional types of authorizations in addition to OAuth 2.0 scopes 1292 and RAR. 1294 * *"claims" Object* 1296 Additional types of identity claims in addition to OpenID Connect 1297 claims and Verified Credentials. 1299 * *Interaction* 1300 Additional mechanisms for the Client to start an interaction with the 1301 User. 1303 * *Access Methods* 1305 Additional mechanisms for the Client to present authorization to a 1306 resource. 1308 [Editor: do we specify access token / handle introspection in this 1309 document, or leave that to an extension?] 1311 [Editor: do we specify access token / handle revocation in this 1312 document, or leave that to an extension?] 1314 12. Rational 1316 1. *Why is there only one mechanism for the Client to authenticate 1317 with the AS? Why not support other mechanisms?* 1319 Having choices requires implementers to understand which choice 1320 is preferable for them. Having one default mechanism in the 1321 document for the Client to authenticate simplifies most 1322 implementations. Extensions can specify other mechanisms that 1323 are preferable in specific environments. 1325 2. *Why is the default Client authentication JOSE rather than 1326 MTLS?* 1328 MTLS cannot be used today by a Dynamic Client. MTLS requires 1329 the application to have access below what is typically the 1330 application layer, that is often not available on some 1331 platforms. JOSE is done at the application layer. Many AS 1332 deployments will be an application behind a proxy performing 1333 TLS, and there are risks in the proxy passing on the results of 1334 MTLS. 1336 3. *Why is the default Client authentication JOSE rather than HTTP 1337 signing?* 1339 There is currently no widely deployed open standard for HTTP 1340 signing. Additionally, HTTP signing requires passing all the 1341 relevant parts of the HTTP request to downstream services within 1342 an AS that may need to independently verify the Client identity. 1344 4. *What are the advantages of using JOSE for the Client to 1345 authenticate to the AS and a resource?* 1346 Both Registered Clients and Dynamic Clients can have a private 1347 key, eliminating the public Client issues in OAuth 2.0, as a 1348 Dynamic Client can create an ephemeral key pair. Using 1349 asymetric cryptography also allows each instance of a Registered 1350 Client to have its own private key if it can obtain a 1351 certificate binding its public key to the public key the AS has 1352 for the Client. Signed tokens can be passed to downstream 1353 components in a AS or RS to enable independent verification of 1354 the Client and its request. The AS Initiated Sequence 1355 Section 10 requires a URL safe parameter, and JOSE is URL safe. 1357 5. *Why does the AS not return parameters to the Client in the 1358 redirect url?* 1360 Passing parameters via a browser redirection is the source of 1361 many of the security risks in OAuth 2.0. It also presents a 1362 challenge for smart devices. In this protocol, the redirection 1363 from the Client to the AS is to enable the AS to interact with 1364 the User, and the redirection back to the Client is to hand back 1365 interaction control to the Client if the redirection was a full 1366 browser redirect. Unlike OAuth 2.0, the identity of the Client 1367 is independent of the URI the AS redirects to. 1369 6. *Why is there not a UserInfo endpoint as there is with OpenID 1370 Connect?* 1372 In OpenID Connect, obtaining claims over the redirect or the 1373 Token Endpoint are problematic. The redirect is limited in 1374 size, and is not secure. The Token Endpoint is intended to 1375 return tokens, and is limited by the "application/x-www-form- 1376 urlencoded" format. A UserInfo endpoint returns "application/ 1377 json", and can return rich claims, just as the completion uri in 1378 this protocol. 1380 [Editor: is there some other reason to have the UserInfo 1381 endpoint? What are industry best practices now? ] 1383 7. *Why is there still a Client ID? Could we not use a fingerprint 1384 of the public key to identify the Client?* 1386 Some AS deployments do not allow calls from Registered Clients, 1387 and provide different functionality to different Clients. A 1388 permanent identifier for the Client is needed for the Client 1389 developer and the AS admin to ensure they are referring to the 1390 same Client. The Client ID was used in OAuth 2.0, and it served 1391 the same purpose. 1393 8. *Why have both claims and authorizations?* 1394 There are use cases for each that are independent: 1395 authenticating a user vs granting access to a resource. A 1396 request for an authorization returns an access token or handle, 1397 while a request for a claim returns the claim. 1399 9. *Why specify HTTP/2 or later and TLS 1.3 or later for Client and 1400 AS communication in ?*Section 8 1402 Knowing the AS supports HTTP/2 enables a Client to set up a 1403 connection faster. HTTP/2 will be more efficient when Clients 1404 have large numbers of access tokens and are frequently 1405 refreshing them at the AS as there will be less network traffic. 1406 Mandating TLS 1.3 similarly improves the performance and 1407 security of Clients and AS when setting up a TLS connection. 1409 10. *Why do some of the JSON objects only have one child, such as 1410 the identifiers object in the user object in the initiation 1411 request?* 1413 It is difficult to forecast future use cases. Having more 1414 resolution may mean the difference between a simple extension, 1415 and a convoluted extension. 1417 11. *Why is the "iss" included in the "oidc" identifier object? 1418 Would the "sub" not be enough for the AS to identify the User?* 1420 The AS may use another AS to authenticate Users. The "iss" and 1421 "sub" combination is required to uniquely identify the User for 1422 any AS. 1424 13. Acknowledgments 1426 This draft derives many of its concepts from Justin Richer's 1427 Transactional Authorization draft [TxAuth]. 1429 Additional thanks to Justin Richer for his strong critique of earlier 1430 drafts. 1432 14. IANA Considerations 1434 [ JOSE parameter for Authorization HTTP header ] 1436 TBD 1438 15. Security Considerations 1440 TBD 1442 16. References 1444 16.1. Normative References 1446 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1447 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1448 . 1450 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1451 DOI 10.17487/RFC5322, October 2008, 1452 . 1454 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1455 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1456 September 2009, . 1458 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1459 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1460 . 1462 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1463 Framework: Bearer Token Usage", RFC 6750, 1464 DOI 10.17487/RFC6750, October 2012, 1465 . 1467 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1468 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1469 2015, . 1471 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1472 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1473 . 1475 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1476 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1477 . 1479 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1480 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1481 DOI 10.17487/RFC7540, May 2015, 1482 . 1484 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1485 Interchange Format", STD 90, RFC 8259, 1486 DOI 10.17487/RFC8259, December 2017, 1487 . 1489 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1490 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1491 . 1493 [OIDC] Sakimora, N., Bradley, J., Jones, M., de Medeiros, B., and 1494 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 1495 . 1497 16.2. Informative References 1499 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1500 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1501 October 2013, . 1503 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 1504 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 1505 . 1507 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1508 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1509 . 1511 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1512 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1513 Application Protocol) over TCP, TLS, and WebSockets", 1514 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1515 . 1517 [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, 1518 "OAuth 2.0 Device Authorization Grant", RFC 8628, 1519 DOI 10.17487/RFC8628, August 2019, 1520 . 1522 [browser_based_apps] 1523 Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based 1524 Apps", September 2019, . 1527 [RAR] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 1528 Rich Authorization Requests", January 2020, 1529 . 1531 [W3C_VC] Sporny, M., Noble, G., and D. Chadwick, "Verifiable 1532 Credentials Data Model 1.0", November 2019, 1533 . 1535 [QR_Code] "ISO/IEC 18004:2015 - Information technology - Automatic 1536 identification and data capture techniques - QR Code bar 1537 code symbology specification", February 2015, 1538 . 1540 [TxAuth] Richer, J., "Transactional Authorization", December 2019, 1541 . 1544 Appendix A. Document History 1546 A.1. draft-hardt-xauth-protocol-00 1548 * Initial version 1550 Appendix B. Comparison with OAuth 2.0 and OpenID Connect 1552 *Changed Features* 1554 The major differences between this protocol and OAuth 2.0 and OpenID 1555 Connect are: 1557 * The Client uses a private key to authenticate in this protocol 1558 instead of the client secret in OAuth 2.0 and OpenID Connect. 1560 * The Client initiates the protocol by making a signed request 1561 directly to the AS instead of redirecting the User to the AS. 1563 * The Client does not receive any parameters from a redirection of 1564 the User back from the AS. 1566 * Refreshing an access token requires creating a refresh token from 1567 a refresh handle, rather than an authenticated call with a refresh 1568 token. 1570 * The Client can request identity claims to be returned independent 1571 of the ID Token. There is no UserInfo endpoint to query claims as 1572 there is in OpenID Connect. 1574 *Preserved Features* 1576 * This protocol reuses the OAuth 2.0 scopes, Client IDs, and access 1577 tokens of OAuth 2.0. 1579 * This protocol reuses the Client IDs, Claims and ID Token of OpenID 1580 Connect. 1582 * No change is required by the Client or the RS for existing APIs. 1584 Author's Address 1586 Dick Hardt (editor) 1587 SignIn.Org 1588 United States 1590 Email: dick.hardt@gmail.com