idnits 2.17.1 draft-tschofenig-oauth-hotk-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 14, 2014) is 3717 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: '4' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 729, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-19 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-10 == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-14 == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-signature-19 ** Obsolete normative reference: RFC 5246 (ref. '8') (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-04 == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-13 -- Obsolete informational reference (is this intentional?): RFC 5849 (ref. '13') (Obsoleted by RFC 6749) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bradley 3 Internet-Draft Ping Identity 4 Intended status: Standards Track P. Hunt 5 Expires: July 18, 2014 Oracle Corporation 6 T. Nadalin 7 Microsoft 8 H. Tschofenig 10 January 14, 2014 12 The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage 13 draft-tschofenig-oauth-hotk-03.txt 15 Abstract 17 OAuth 2.0 deployments currently rely on bearer tokens for securing 18 access to protected resources. Bearer tokens require Transport Layer 19 Security to be used between an OAuth client and the resource server 20 when presenting the access token. The security model is based on 21 proof-of-possession: access token storage and transfer has to be done 22 with care to prevent leakage. 24 There are, however, use cases that require a more active involvement 25 of the OAuth client for an increased level of security, particularly 26 to secure against token leakage. This document specifies an OAuth 27 security framework using the holder-of-the-key concept, which 28 requires the OAuth client when presenting an OAuth access token to 29 also demonstrate knowledge of keying material that is bound to the 30 token. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 18, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 69 3.1. Binding a Key to an Access Token . . . . . . . . . . . . 4 70 3.1.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . 4 71 3.1.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 7 72 3.2. Accessing a Protected Resource . . . . . . . . . . . . . 9 73 3.2.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . 9 74 3.2.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 11 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 4.1. Security Threats . . . . . . . . . . . . . . . . . . . . 12 77 4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 12 78 4.3. Summary of Recommendations . . . . . . . . . . . . . . . 13 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 14 81 5.2. The 'hotk' JSON Web Token Claims . . . . . . . . . . . . 15 82 5.3. The 'hotk' OAuth Access Token Type . . . . . . . . . . . 15 83 5.4. Profile Registry . . . . . . . . . . . . . . . . . . . . 15 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 7.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 At the time of writing the OAuth 2.0 [3] and accompanying protocols 93 offer one main security mechanism to access protected resources, 94 namely the bearer token. In [12] a bearer token is defined as 95 A security token with the property that any party in possession of 96 the token (a "bearer") can use the token in any way that any other 97 party in possession of it can. Using a bearer token does not 98 require a bearer to prove possession of cryptographic key 99 material. 101 The bearer token meets the security needs of number of use cases 102 OAuth had been designed for. There are, however, scenarios that 103 require stronger security properties and ask for active participation 104 of the OAuth client software in form of cryptographic computations 105 when presenting an access token to a resource server. 107 This specification defines a new security mechanism for usage with 108 OAuth that combines various existing specifications to offer enhanced 109 security properties for OAuth. The incredients for this security 110 solution are: 112 1. A mechanism for dynamic key distribution. 114 2. Data elements to bind emphemeral keying material to an access 115 token. For the access token we assume a JSON Web Token (JWT) [6] 116 in this specification to specify a complete solution. Future 117 specifications may make this functionality available to other 118 access token formats as well. 120 3. A mechanism to allow the OAuth client to demonstrate a proof of 121 possession. 123 The rest of the document describes how these different components 124 work together. 126 2. Terminology 128 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 129 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 130 specification are to be interpreted as described in [1]. 132 3. Protocol Specification 134 To describe the architecture of the proposed security mechanism it is 135 best to start by looking at the main OAuth 2.0 protocol exchange 136 sequence. Figure 1 shows the abstract OAuth 2.0 protocol exchanges 137 graphically. The exchange in this document will focus on two 138 interactions, namely 140 1. to allow the client to obtain the ephemeral asymmetric 141 credentails in step (D) 143 2. to use the obtained asymmetric credentials for the interaction 144 with the resource server in step (E) 146 +--------+ +---------------+ 147 | |--(A)- Authorization Request ->| Resource | 148 | | | Owner | 149 | |<-(B)-- Authorization Grant ---| | 150 | | +---------------+ 151 | | 152 | | +---------------+ 153 | |--(C)-- Authorization Grant -->| Authorization | 154 | Client | | Server | 155 | |<-(D)----- Access Token -------| | 156 | | +---------------+ 157 | | 158 | | +---------------+ 159 | |--(E)----- Access Token ------>| Resource | 160 | | | Server | 161 | |<-(F)--- Protected Resource ---| | 162 +--------+ +---------------+ 164 Figure 1: Abstract OAuth 2.0 Protocol Flow 166 3.1. Binding a Key to an Access Token 168 OAuth 2.0 offers different ways to obtain an access token, namely 169 using authorization grants and using a refresh token. The core OAuth 170 specification defines four authorization grants, see Section 1.3 of 171 [3], and [11] adds an assertion-based authorization grant to that 172 list. 174 This document extends the communication with the token endpoint. The 175 token endpoint, which is described in Section 3.2 of [3], is used 176 with every authorization grant except for the implicit grant type. 177 In the implicit grant type the access token is issued directly. 179 Two types of keying material can be bound to an access token, namely 180 symmetric keys and asymmetric keys, and we explain them in separate 181 sub-sections. 183 3.1.1. Symmetric Keys 185 In case a symmetric key shall be bound to an access token then the 186 following procedure is applicable. In the request message from the 187 OAuth client to the authorization server the following parameters 188 MUST be included: 190 token_type: REQUIRED. For the symmetric holder-of-the-key variant 191 the value MUST be set to "hotk-sk". 193 profile: REQUIRED. The profile parameter provides information about 194 what mechanisms the client supports to provide proof of 195 possession of the key towards a resource server. The value 196 MUST be taken from the algorithm registry created in 197 Section 5.4. Algorithm names are case-sensitive. If the 198 client supports more than one profile then each individual 199 value MUST be separated by a comma. 201 For example, the client makes the following HTTP request using TLS 202 (extra line breaks are for display purposes only): 204 POST /token HTTP/1.1 205 Host: server.example.com 206 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 207 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 209 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 210 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 211 &token_type=hotk-sk 212 &profile=jws,mac 214 Example Request to the Authorization Server 216 If the access token request is valid and authorized, the 217 authorization server issues an access token and optionally a refresh 218 token. If the request client authentication failed or is invalid, 219 the authorization server returns an error response as described in 220 Section 5.2 of [3]. 222 The authorization server MUST include the following parameters in a 223 successful response, if it supports any of the profiles listed by the 224 client. 226 id: REQUIRED. An ephemeral and unique key identifier. The 227 authorization server MUST NOT select the same key identifier 228 twice within the lifetime of the access token, which is 229 indicated by the 'expires_in' parameter. 231 key: REQUIRED. A fresh and unique shared symmetric secret with 232 sufficient entrophy. 234 profile: REQUIRED. The profile parameter provides further 235 information about how the client has to provide proof of 236 possession of the key with the resource server. The 237 authorization server chooses a value from the list of supported 238 mechanisms supported by the client. 240 For example: 242 HTTP/1.1 200 OK 243 Content-Type: application/json 244 Cache-Control: no-store 246 { 247 "access_token":"SlAV.....32hkKG", 248 "token_type":"hotk-sk", 249 "expires_in":3600, 250 "refresh_token":"8xLOxBtZp8", 251 "id":"client12345@example.com", 252 "key":"adijq39jdlaska9asud", 253 "profile":"jws" 254 } 256 The content of the 'access_token' MUST contain 257 the key identifier value in the 'hotk' element, 258 as shown in the example below. 260 {"typ":"JWT", 261 "alg":"HS256" 262 } 263 . 264 {"iss":"authorization-server-id", 265 "exp":1300819380, 266 "hotk":"client12345@example.com" 267 } 268 . 269 bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC 271 DISCUSSION: Should we put the encrypted key into the access token? 272 This would make the mechanism more similar to a Kerberos-based 273 scheme. 275 The key identifier, the key, and the profile name MUST NOT include 276 characters other than: 278 %x20-21 / %x23-5B / %x5D-7E 279 ; Any printable ASCII character except for <"> and <\> 281 3.1.2. Asymmetric Keys 283 In case an asymmetric key shall be bound to an access token then the 284 following procedure is applicable. In the request message from the 285 OAuth client to the authorization server the following parameters 286 MUST be included: 288 token_type: REQUIRED. For the asymmetric holder-of-the-key variant 289 the value MUST be set to "hotk-pk". 291 pk_info: REQUIRED. This field contains information about the public 292 key the client would like to bind to the access token in the 293 JSON Web Key format. The public key is "application/x-www- 294 form-urlencoded" encoded. 296 For example, the client makes the following HTTP request using TLS 297 (extra line breaks are for display purposes only): 299 POST /token HTTP/1.1 300 Host: server.example.com 301 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 302 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 304 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 305 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 306 &token_type=hotk-pk 307 &pk_info=eZQQYbYS6WxS...lxlOB 309 whereby the content of the pk_info field represents the following 310 structure: 312 {"keys": 313 [ 314 {"alg":"RSA", 315 "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 316 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 317 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 318 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 319 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 320 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 321 "exp":"AQAB", 322 "kid":"2011-04-29"} 323 ] 324 } 326 Example Request to the Authorization Server 328 If the access token request is valid and authorized, the 329 authorization server issues an access token and optionally a refresh 330 token. If the request client authentication failed or is invalid, 331 the authorization server returns an error response as described in 332 Section 5.2 of [3]. 334 The authorization server also places information about the public key 335 used by the client into the access token to create the binding 336 between the two. The new token type, called 'hotk-pk', is placed 337 into the 'token_type' parameter. 339 An example of a successful response is shown below: 341 HTTP/1.1 200 OK 342 Content-Type: application/json;charset=UTF-8 343 Cache-Control: no-store 344 Pragma: no-cache 346 { 347 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 348 "token_type":"hotk-pk", 349 "expires_in":3600, 350 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 351 } 353 whereby the content of the 'access_token' field, for example, 354 contains an encoded JWT with the following raw structure: 356 {"typ":"JWT", 357 "alg":"HS256"} 358 . 359 {"iss":"authorization-server-id", 360 "exp":1300819380, 361 "hotk": {"keys": 362 [ 363 {"alg":"RSA", 364 "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 365 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 366 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 367 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 368 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 369 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 370 "exp":"AQAB", 371 "kid":"2011-04-29"} 372 ] 373 } 374 } 375 . 376 bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC 378 Example Response from the Authorization Server 380 3.2. Accessing a Protected Resource 382 Accessing a protected resource depends on the chosen credential type. 384 3.2.1. Symmetric Keys 386 When a symmetric key was used as a holder-of-the-key then the client 387 has to demonstrate possession of the key that corresponds to the key 388 identifier found in the access token. 390 This specification defines three ways for providing this proof of 391 possession, which are indicated as profiles in Section 3.1.1: 393 jws: When the 'jws' profile is chosen then the client MUST compute 394 the following string by concatenating together, in order, the 395 following HTTP request elements: 397 1. The HTTP request method in upper case. For example: "HEAD", 398 "GET", "POST", etc. 400 2. The HTTP request-URI as defined by Section 5.1.2 of [2]. 402 3. The hostname included in the HTTP request using the "Host" 403 request header field in lower case. 405 4. The port as included in the HTTP request using the "Host" 406 request header field. If the header field does not include a 407 port, the default value for the scheme MUST be used (e.g., 80 408 for HTTP and 443 for HTTPS). 410 5. The value of the "ext" "Authorization" request header field 411 attribute if one was included in the request, otherwise, an 412 empty string. 414 Each element is followed by a new line character (%x0A) including 415 the last element and even when an element value is an empty 416 string. The resulting value MUST be put into the "request" 417 element of a JSON document that is then subject to JWS processing 418 [7]. The resulting JWS structure is put into the body of the HTTP 419 request. A receiving authorization server MUST use the value in 420 the 'kid' structure to identify the shared key and then use that 421 key to verify the keyed message digest. Additionally, the content 422 of the 'request' field needs to be verified against the HTTP 423 header information. If any of these verification steps fail then 424 the request to the protected resource MUST fail with a "401 425 Unauthorized" error message back to the OAuth client. 427 The following example shows and the corresponding encoding in a 428 JWS structure: 430 1) HTTP Request 432 POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q HTTP/1.1 433 Host: example.com 435 2) JWS Document 437 {"typ":"HOTK-SK", 438 "alg":"HS256", 439 "kid":"client12345@example.com", 440 "timestamp":"2012-07-15T10:20:00.000-05:00" } 441 . 442 {"request":"POST/request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3= 443 2+qexample.com80"} 444 . 445 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 447 JWS Example 449 mac: When the 'mac' profile is chosen then the client MUST follow 450 the description in [10]. 452 3.2.2. Asymmetric Keys 454 The client accesses protected resources by presenting the access 455 token to the resource server. It does so via a Transport Layer 456 Security (TLS) secured channel. Since the client had previously 457 bound a public key to an access token it selects this key for usage 458 with TLS as described in [5]. 460 The resource server validates the access token and ensure it has not 461 expired and that its scope covers the requested resource. 462 Additionally, the resource server verifies that the public key 463 presented during the TLS handshake corresponds to the public key that 464 is contained in the access token. 466 Note that this step confirms that the client is in possession of the 467 private key corresponding to the public key previously bound to the 468 access token. Information about the client authentication may be 469 contained in the token in case the authorization server added this 470 information when it authenticated the client. 472 4. Security Considerations 473 4.1. Security Threats 475 The following list presents several common threats against protocols 476 utilizing some form of tokens. This list of threats is based on NIST 477 Special Publication 800-63 [14]. We exclude a discussion of threats 478 related to any form of registration and authentication. 480 Token manufacture/modification: An attacker may craft a fake token 481 or modify the token content (such as the authentication or 482 attribute statements), causing a resource server to grant 483 inappropriate access to the attacker. For example, an attacker 484 may modify the token to extend the validity period or the scope to 485 have extended access to information. 487 Token disclosure: Tokens may contain authentication and attribute 488 statements that include sensitive information. 490 Token redirect: An attacker uses a token generated for consumption 491 by one resource server to gain access to a different resource 492 server that mistakenly believes the token to be for it. 494 Token reuse: An attacker attempts to use a token that has already 495 been used with that resource server in the past. 497 4.2. Threat Mitigation 499 A large range of threats can be mitigated by protecting the contents 500 of the access token by using a digital signature or a Message 501 Authentication Code (MAC). Consequently, the token integrity 502 protection MUST be sufficient to prevent the token from being 503 modified. 505 To deal with token redirect, it is important for the authorization 506 server to include the identity of the intended recipients (the 507 audience), typically a single resource server (or a list of resource 508 servers), in the token. Restricting the use of the token to a 509 specific scope is also RECOMMENDED. 511 The authorization server MUST implement and use TLS. Which 512 version(s) ought to be implemented will vary over time, and depend on 513 the widespread deployment and known security vulnerabilities at the 514 time of implementation. At the time of this writing, TLS version 1.2 515 [8] is the most recent version. The client MUST validate the TLS 516 certificate chain when making requests to protected resources, 517 including checking the Certificate Revocation List (CRL) [9]. 519 For the interaction between the client and the resource server this 520 specification requires a TLS extension for usage with out-of-band 521 validation [5] to be used that allows clients to present raw public 522 keys for asymmetric holder-of-the-key usage. 524 With the usage of the holder-of-the-key concept it is not possible 525 for any party other than the legitimate client to use an access token 526 and to re-use it without knowing the corresponding asymmetric key 527 pair. This mechanism prevents against token disclosure. 529 With the usage of the asymmetric holder-of-the-key concept the 530 following deployment consideration needs to be taken into 531 consideration. In some deployments, including those utilizing load 532 balancers, the TLS connection to the resource server terminates prior 533 to the actual server that provides the resource. This could leave 534 the token unprotected between the front end server where the TLS 535 connection terminates and the back end server that provides the 536 resource. 538 Client implementations must be carefully implemented to avoid leaking 539 the ephemeral credentials (either the private key from the asymmetric 540 credential or the shared secret). 542 Token replay is also not possible since an eavesdropper will also 543 have to obtain the corresponding private key or shared secret that is 544 bound to the access token. Nevertheless, it is good practice to 545 limit the lifetime of the access token and therefore the lifetime of 546 associated key. 548 4.3. Summary of Recommendations 550 The following three items represent the main recommendations: 552 Safeguard the private key/shared secret: Client implementations MUST 553 ensure that the ephemeral private key / shared secret is not 554 leaked to third parties, since those will be able to use the 555 access token together with the keying material to gain access to 556 protected resources. 558 Switch keying material regularly: Clients can at any time create a 559 new ephemeral credential and associate it with an access token. 560 For example, a client presents a new public key when requesting an 561 access token with the help of a refresh token. Nevertheless, the 562 lifetime of these access token may be longer than the lifetime of 563 bearer tokens. 565 Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens 566 that contain an audience restriction, scoping their use to the 567 intended relying party or set of relying parties. 569 5. IANA Considerations 571 This document requires IANA to take the following actions. 573 5.1. OAuth Parameters Registration 575 This specification registers the following parameters in the OAuth 576 Parameters Registry established by [3]. 578 Parameter name: pk_info 580 Parameter usage location: token request 582 Change controller: IETF 584 Specification document(s): [[ this document ]] 586 Related information: None 588 Parameter name: token_type 590 Parameter usage location: token request, token response, 591 authorization response 593 Change controller: IETF 595 Specification document(s): [[ this document ]] 597 Related information: None 599 Parameter name: profile 601 Parameter usage location: token request, token response, 602 authorization response 604 Change controller: IETF 606 Specification document(s): [[ this document ]] 608 Related information: None 610 Parameter name: id 612 Parameter usage location: token response, authorization response 614 Change controller: IETF 616 Specification document(s): [[ this document ]] 617 Related information: None 619 Parameter name: key 621 Parameter usage location: token response, authorization response 623 Change controller: IETF 625 Specification document(s): [[ this document ]] 627 Related information: None 629 5.2. The 'hotk' JSON Web Token Claims 631 [6] established the IANA JSON Web Token Claims registry for reserved 632 JWT Claim Names and this document adds the 'hotk' name to that 633 registry. 635 5.3. The 'hotk' OAuth Access Token Type 637 Section 11.1 of [3] defines the OAuth Access Token Type Registry and 638 this document adds another token type to this registry. 640 Type name: hotk 642 Additional Token Endpoint Response Parameters: (none) 644 HTTP Authentication Scheme(s): Holder of the key confirmation using 645 TLS 647 Change controller: IETF 649 Specification document(s): [[ this document ]] 651 5.4. Profile Registry 653 This document asks IANA to create a registry for profiles of 654 symmetric key-based holder-of-the-key mechanisms. The policy for 655 adding new entries to the registry is "Specification Required". IANA 656 is asked to populate the registry with the following values: 658 o Profile name: jws 660 o Change controller: IETF 662 o Specification document(s): [[ this document ]] 664 o Profile name: mac 665 o Change controller: IETF 667 o Specification document(s): [[ this document ]] 669 6. Acknowledgements 671 The author would like to thank the OAuth working group and 672 participants of the Internet Identity Workshop for their discussion 673 input that lead to this document. 675 7. References 677 7.1. Normative References 679 [1] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 683 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 684 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 686 [3] Hardt, D., "The OAuth 2.0 Authorization Framework", draft- 687 ietf-oauth-v2-31 (work in progress), August 2012. 689 [4] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 690 key-19 (work in progress), December 2013. 692 [5] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 693 T. Kivinen, "Using Raw Public Keys in Transport Layer 694 Security (TLS) and Datagram Transport Layer Security 695 (DTLS)", draft-ietf-tls-oob-pubkey-10 (work in progress), 696 October 2013. 698 [6] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 699 (JWT)", draft-ietf-oauth-json-web-token-14 (work in 700 progress), December 2013. 702 [7] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 703 Signature (JWS)", draft-ietf-jose-json-web-signature-19 704 (work in progress), December 2013. 706 [8] Dierks, T. and E. Rescorla, "The Transport Layer Security 707 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 709 [9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 710 Housley, R., and W. Polk, "Internet X.509 Public Key 711 Infrastructure Certificate and Certificate Revocation List 712 (CRL) Profile", RFC 5280, May 2008. 714 [10] Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 715 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- 716 oauth-v2-http-mac-04 (work in progress), July 2013. 718 7.2. Informative References 720 [11] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 721 "Assertion Framework for OAuth 2.0 Client Authentication 722 and Authorization Grants", draft-ietf-oauth-assertions-13 723 (work in progress), December 2013. 725 [12] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 726 Framework: Bearer Token Usage", draft-ietf- 727 oauth-v2-bearer-23 (work in progress), August 2012. 729 [13] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 730 April 2010. 732 [14] Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., 733 and E. Nabbus, "NIST Special Publication 800-63-1, 734 INFORMATION SECURITY", December 2008. 736 Authors' Addresses 738 John Bradley 739 Ping Identity 741 Email: ve7jtb@ve7jtb.com 743 Phil Hunt 744 Oracle Corporation 746 Email: phil.hunt@yahoo.com 748 Tony Nadalin 749 Microsoft 751 Email: tonynad@microsoft.com 753 Hannes Tschofenig 755 Email: Hannes.Tschofenig@gmx.net 756 URI: http://www.tschofenig.priv.at