idnits 2.17.1 draft-tschofenig-oauth-hotk-02.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 (February 25, 2013) is 4078 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: '10' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 736, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-06 ** Obsolete normative reference: RFC 2616 (ref. '4') (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-signature-08 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-02 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-07 ** Obsolete normative reference: RFC 5246 (ref. '8') (Obsoleted by RFC 8446) == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-08 == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-10 -- Obsolete informational reference (is this intentional?): RFC 5849 (ref. '14') (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: August 29, 2013 Oracle Corporation 6 T. Nadalin 7 Microsoft 8 H. Tschofenig 9 Nokia Siemens Networks 10 February 25, 2013 12 The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage 13 draft-tschofenig-oauth-hotk-02.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 August 29, 2013. 49 Copyright Notice 51 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Binding a Key to an Access Token . . . . . . . . . . . . . 5 70 3.1.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . 6 71 3.1.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 8 72 3.2. Accessing a Protected Resource . . . . . . . . . . . . . . 10 73 3.2.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . 10 74 3.2.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 4.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 13 77 4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 13 78 4.3. Summary of Recommendations . . . . . . . . . . . . . . . . 14 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 16 81 5.2. The 'hotk' JSON Web Token Claims . . . . . . . . . . . . . 17 82 5.3. The 'hotk' OAuth Access Token Type . . . . . . . . . . . . 17 83 5.4. Profile Registry . . . . . . . . . . . . . . . . . . . . . 17 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 At the time of writing the OAuth 2.0 [1] and accompanying protocols 93 offer one main security mechanism to access protected resources, 94 namely the bearer token. In [11] a bearer token is defined as 96 A security token with the property that any party in possession of 97 the token (a "bearer") can use the token in any way that any other 98 party in possession of it can. Using a bearer token does not 99 require a bearer to prove possession of cryptographic key 100 material. 102 The bearer token meets the security needs of number of use cases 103 OAuth had been designed for. There are, however, scenarios that 104 require stronger security properties and ask for active participation 105 of the OAuth client software in form of cryptographic computations 106 when presenting an access token to a resource server. 108 This specification defines a new security mechanism for usage with 109 OAuth that combines various existing specifications to offer enhanced 110 security properties for OAuth. The incredients for this security 111 solution are: 113 1. A mechanism for dynamic key distribution. 115 2. Data elements to bind emphemeral keying material to an access 116 token. For the access token we assume a JSON Web Token (JWT) [2] 117 in this specification to specify a complete solution. Future 118 specifications may make this functionality available to other 119 access token formats as well. 121 3. A mechanism to allow the OAuth client to demonstrate a proof of 122 possession. 124 The rest of the document describes how these different components 125 work together. 127 2. Terminology 129 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 130 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 131 specification are to be interpreted as described in [3]. 133 3. Protocol Specification 135 To describe the architecture of the proposed security mechanism it is 136 best to start by looking at the main OAuth 2.0 protocol exchange 137 sequence. Figure 1 shows the abstract OAuth 2.0 protocol exchanges 138 graphically. The exchange in this document will focus on two 139 interactions, namely 141 1. to allow the client to obtain the ephemeral asymmetric 142 credentails in step (D) 144 2. to use the obtained asymmetric credentials for the interaction 145 with the resource server in step (E) 147 +--------+ +---------------+ 148 | |--(A)- Authorization Request ->| Resource | 149 | | | Owner | 150 | |<-(B)-- Authorization Grant ---| | 151 | | +---------------+ 152 | | 153 | | +---------------+ 154 | |--(C)-- Authorization Grant -->| Authorization | 155 | Client | | Server | 156 | |<-(D)----- Access Token -------| | 157 | | +---------------+ 158 | | 159 | | +---------------+ 160 | |--(E)----- Access Token ------>| Resource | 161 | | | Server | 162 | |<-(F)--- Protected Resource ---| | 163 +--------+ +---------------+ 165 Figure 1: Abstract OAuth 2.0 Protocol Flow 167 3.1. Binding a Key to an Access Token 169 OAuth 2.0 offers different ways to obtain an access token, namely 170 using authorization grants and using a refresh token. The core OAuth 171 specification defines four authorization grants, see Section 1.3 of 172 [1], and [12] adds an assertion-based authorization grant to that 173 list. 175 This document extends the communication with the token endpoint. The 176 token endpoint, which is described in Section 3.2 of [1], is used 177 with every authorization grant except for the implicit grant type. 178 In the implicit grant type the access token is issued directly. 180 Two types of keying material can be bound to an access token, namely 181 symmetric keys and asymmetric keys, and we explain them in separate 182 sub-sections. 184 3.1.1. Symmetric Keys 186 In case a symmetric key shall be bound to an access token then the 187 following procedure is applicable. In the request message from the 188 OAuth client to the authorization server the following parameters 189 MUST be included: 191 token_type: REQUIRED. For the symmetric holder-of-the-key variant 192 the value MUST be set to "hotk-sk". 194 profile: REQUIRED. The profile parameter provides information about 195 what mechanisms the client supports to provide proof of 196 possession of the key towards a resource server. The value 197 MUST be taken from the algorithm registry created in 198 Section 5.4. Algorithm names are case-sensitive. If the 199 client supports more than one profile then each individual 200 value MUST be separated by a comma. 202 For example, the client makes the following HTTP request using TLS 203 (extra line breaks are for display purposes only): 205 POST /token HTTP/1.1 206 Host: server.example.com 207 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 208 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 210 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 211 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 212 &token_type=hotk-sk 213 &profile=jws,mac 215 Example Request to the Authorization Server 217 If the access token request is valid and authorized, the 218 authorization server issues an access token and optionally a refresh 219 token. If the request client authentication failed or is invalid, 220 the authorization server returns an error response as described in 221 Section 5.2 of [1]. 223 The authorization server MUST include the following parameters in a 224 successful response, if it supports any of the profiles listed by the 225 client. 227 id: REQUIRED. An ephemeral and unique key identifier. The 228 authorization server MUST NOT select the same key identifier 229 twice within the lifetime of the access token, which is 230 indicated by the 'expires_in' parameter. 232 key: REQUIRED. A fresh and unique shared symmetric secret with 233 sufficient entrophy. 235 profile: REQUIRED. The profile parameter provides further 236 information about how the client has to provide proof of 237 possession of the key with the resource server. The 238 authorization server chooses a value from the list of supported 239 mechanisms supported by the client. 241 For example: 243 HTTP/1.1 200 OK 244 Content-Type: application/json 245 Cache-Control: no-store 247 { 248 "access_token":"SlAV.....32hkKG", 249 "token_type":"hotk-sk", 250 "expires_in":3600, 251 "refresh_token":"8xLOxBtZp8", 252 "id":"client12345@example.com", 253 "key":"adijq39jdlaska9asud", 254 "profile":"jws" 255 } 257 The content of the 'access_token' MUST contain 258 the key identifier value in the 'hotk' element, 259 as shown in the example below. 261 {"typ":"JWT", 262 "alg":"HS256" 263 } 264 . 265 {"iss":"authorization-server-id", 266 "exp":1300819380, 267 "hotk":"client12345@example.com" 268 } 269 . 270 bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC 272 DISCUSSION: Should we put the encrypted key into the access token? 273 This would make the mechanism more similar to a Kerberos-based 274 scheme. 276 The key identifier, the key, and the profile name MUST NOT include 277 characters other than: 279 %x20-21 / %x23-5B / %x5D-7E 280 ; Any printable ASCII character except for <"> and <\> 282 3.1.2. Asymmetric Keys 284 In case an asymmetric key shall be bound to an access token then the 285 following procedure is applicable. In the request message from the 286 OAuth client to the authorization server the following parameters 287 MUST be included: 289 token_type: REQUIRED. For the asymmetric holder-of-the-key variant 290 the value MUST be set to "hotk-pk". 292 pk_info: REQUIRED. This field contains information about the public 293 key the client would like to bind to the access token in the 294 JSON Web Key format. The public key is "application/ 295 x-www-form-urlencoded" encoded. 297 For example, the client makes the following HTTP request using TLS 298 (extra line breaks are for display purposes only): 300 POST /token HTTP/1.1 301 Host: server.example.com 302 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 303 Content-Type: application/x-www-form-urlencoded;charset=UTF-8 305 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA 306 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 307 &token_type=hotk-pk 308 &pk_info=eZQQYbYS6WxS...lxlOB 310 whereby the content of the pk_info field represents the following 311 structure: 313 {"keys": 314 [ 315 {"alg":"RSA", 316 "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 317 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 318 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 319 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 320 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 321 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 322 "exp":"AQAB", 323 "kid":"2011-04-29"} 324 ] 325 } 327 Example Request to the Authorization Server 329 If the access token request is valid and authorized, the 330 authorization server issues an access token and optionally a refresh 331 token. If the request client authentication failed or is invalid, 332 the authorization server returns an error response as described in 333 Section 5.2 of [1]. 335 The authorization server also places information about the public key 336 used by the client into the access token to create the binding 337 between the two. The new token type, called 'hotk-pk', is placed 338 into the 'token_type' parameter. 340 An example of a successful response is shown below: 342 HTTP/1.1 200 OK 343 Content-Type: application/json;charset=UTF-8 344 Cache-Control: no-store 345 Pragma: no-cache 347 { 348 "access_token":"2YotnFZFE....jr1zCsicMWpAA", 349 "token_type":"hotk-pk", 350 "expires_in":3600, 351 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 352 } 354 whereby the content of the 'access_token' field, for example, 355 contains an encoded JWT with the following raw structure: 357 {"typ":"JWT", 358 "alg":"HS256"} 359 . 360 {"iss":"authorization-server-id", 361 "exp":1300819380, 362 "hotk": {"keys": 363 [ 364 {"alg":"RSA", 365 "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 366 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 367 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 368 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 369 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 370 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 371 "exp":"AQAB", 372 "kid":"2011-04-29"} 373 ] 374 } 375 } 376 . 377 bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC 379 Example Response from the Authorization Server 381 3.2. Accessing a Protected Resource 383 Accessing a protected resource depends on the chosen credential type. 385 3.2.1. Symmetric Keys 387 When a symmetric key was used as a holder-of-the-key then the client 388 has to demonstrate possession of the key that corresponds to the key 389 identifier found in the access token. 391 This specification defines three ways for providing this proof of 392 possession, which are indicated as profiles in Section 3.1.1: 394 jws: When the 'jws' profile is chosen then the client MUST compute 395 the following string by concatenating together, in order, the 396 following HTTP request elements: 398 1. The HTTP request method in upper case. For example: "HEAD", 399 "GET", "POST", etc. 401 2. The HTTP request-URI as defined by Section 5.1.2 of [4]. 403 3. The hostname included in the HTTP request using the "Host" 404 request header field in lower case. 406 4. The port as included in the HTTP request using the "Host" 407 request header field. If the header field does not include a 408 port, the default value for the scheme MUST be used (e.g., 80 409 for HTTP and 443 for HTTPS). 411 5. The value of the "ext" "Authorization" request header field 412 attribute if one was included in the request, otherwise, an 413 empty string. 415 Each element is followed by a new line character (%x0A) including 416 the last element and even when an element value is an empty 417 string. The resulting value MUST be put into the "request" 418 element of a JSON document that is then subject to JWS processing 419 [5]. The resulting JWS structure is put into the body of the HTTP 420 request. A receiving authorization server MUST use the value in 421 the 'kid' structure to identify the shared key and then use that 422 key to verify the keyed message digest. Additionally, the content 423 of the 'request' field needs to be verified against the HTTP 424 header information. If any of these verification steps fail then 425 the request to the protected resource MUST fail with a "401 426 Unauthorized" error message back to the OAuth client. 428 The following example shows and the corresponding encoding in a 429 JWS structure: 431 1) HTTP Request 433 POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q HTTP/1.1 434 Host: example.com 436 2) JWS Document 438 {"typ":"HOTK-SK", 439 "alg":"HS256", 440 "kid":"client12345@example.com", 441 "timestamp":"2012-07-15T10:20:00.000-05:00" } 442 . 443 {"request":"POST/request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3= 444 2+qexample.com80"} 445 . 446 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 448 JWS Example 450 mac: When the 'mac' profile is chosen then the client MUST follow 451 the description in [6]. 453 3.2.2. Asymmetric Keys 455 The client accesses protected resources by presenting the access 456 token to the resource server. It does so via a Transport Layer 457 Security (TLS) secured channel. Since the client had previously 458 bound a public key to an access token it selects this key for usage 459 with TLS as described in [7]. 461 The resource server validates the access token and ensure it has not 462 expired and that its scope covers the requested resource. 463 Additionally, the resource server verifies that the public key 464 presented during the TLS handshake corresponds to the public key that 465 is contained in the access token. 467 Note that this step confirms that the client is in possession of the 468 private key corresponding to the public key previously bound to the 469 access token. Information about the client authentication may be 470 contained in the token in case the authorization server added this 471 information when it authenticated the client. 473 4. Security Considerations 475 4.1. Security Threats 477 The following list presents several common threats against protocols 478 utilizing some form of tokens. This list of threats is based on NIST 479 Special Publication 800-63 [13]. We exclude a discussion of threats 480 related to any form of registration and authentication. 482 Token manufacture/modification: An attacker may craft a fake token 483 or modify the token content (such as the authentication or 484 attribute statements), causing a resource server to grant 485 inappropriate access to the attacker. For example, an attacker 486 may modify the token to extend the validity period or the scope to 487 have extended access to information. 489 Token disclosure: Tokens may contain authentication and attribute 490 statements that include sensitive information. 492 Token redirect: An attacker uses a token generated for consumption 493 by one resource server to gain access to a different resource 494 server that mistakenly believes the token to be for it. 496 Token reuse: An attacker attempts to use a token that has already 497 been used with that resource server in the past. 499 4.2. Threat Mitigation 501 A large range of threats can be mitigated by protecting the contents 502 of the access token by using a digital signature or a Message 503 Authentication Code (MAC). Consequently, the token integrity 504 protection MUST be sufficient to prevent the token from being 505 modified. 507 To deal with token redirect, it is important for the authorization 508 server to include the identity of the intended recipients (the 509 audience), typically a single resource server (or a list of resource 510 servers), in the token. Restricting the use of the token to a 511 specific scope is also RECOMMENDED. 513 The authorization server MUST implement and use TLS. Which 514 version(s) ought to be implemented will vary over time, and depend on 515 the widespread deployment and known security vulnerabilities at the 516 time of implementation. At the time of this writing, TLS version 1.2 517 [8] is the most recent version. The client MUST validate the TLS 518 certificate chain when making requests to protected resources, 519 including checking the Certificate Revocation List (CRL) [9]. 521 For the interaction between the client and the resource server this 522 specification requires a TLS extension for usage with out-of-band 523 validation [7] to be used that allows clients to present raw public 524 keys for asymmetric holder-of-the-key usage. 526 With the usage of the holder-of-the-key concept it is not possible 527 for any party other than the legitimate client to use an access token 528 and to re-use it without knowing the corresponding asymmetric key 529 pair. This mechanism prevents against token disclosure. 531 With the usage of the asymmetric holder-of-the-key concept the 532 following deployment consideration needs to be taken into 533 consideration. In some deployments, including those utilizing load 534 balancers, the TLS connection to the resource server terminates prior 535 to the actual server that provides the resource. This could leave 536 the token unprotected between the front end server where the TLS 537 connection terminates and the back end server that provides the 538 resource. 540 Client implementations must be carefully implemented to avoid leaking 541 the ephemeral credentials (either the private key from the asymmetric 542 credential or the shared secret). 544 Token replay is also not possible since an eavesdropper will also 545 have to obtain the corresponding private key or shared secret that is 546 bound to the access token. Nevertheless, it is good practice to 547 limit the lifetime of the access token and therefore the lifetime of 548 associated key. 550 4.3. Summary of Recommendations 552 The following three items represent the main recommendations: 554 Safeguard the private key/shared secret: Client implementations MUST 555 ensure that the ephemeral private key / shared secret is not 556 leaked to third parties, since those will be able to use the 557 access token together with the keying material to gain access to 558 protected resources. 560 Switch keying material regularly: Clients can at any time create a 561 new ephemeral credential and associate it with an access token. 562 For example, a client presents a new public key when requesting an 563 access token with the help of a refresh token. Nevertheless, the 564 lifetime of these access token may be longer than the lifetime of 565 bearer tokens. 567 Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens 568 that contain an audience restriction, scoping their use to the 569 intended relying party or set of relying parties. 571 5. IANA Considerations 573 This document requires IANA to take the following actions. 575 5.1. OAuth Parameters Registration 577 This specification registers the following parameters in the OAuth 578 Parameters Registry established by [1]. 580 Parameter name: pk_info 582 Parameter usage location: token request 584 Change controller: IETF 586 Specification document(s): [[ this document ]] 588 Related information: None 590 Parameter name: token_type 592 Parameter usage location: token request, token response, 593 authorization response 595 Change controller: IETF 597 Specification document(s): [[ this document ]] 599 Related information: None 601 Parameter name: profile 603 Parameter usage location: token request, token response, 604 authorization response 606 Change controller: IETF 608 Specification document(s): [[ this document ]] 610 Related information: None 612 Parameter name: id 614 Parameter usage location: token response, authorization response 615 Change controller: IETF 617 Specification document(s): [[ this document ]] 619 Related information: None 621 Parameter name: key 623 Parameter usage location: token response, authorization response 625 Change controller: IETF 627 Specification document(s): [[ this document ]] 629 Related information: None 631 5.2. The 'hotk' JSON Web Token Claims 633 [2] established the IANA JSON Web Token Claims registry for reserved 634 JWT Claim Names and this document adds the 'hotk' name to that 635 registry. 637 5.3. The 'hotk' OAuth Access Token Type 639 Section 11.1 of [1] defines the OAuth Access Token Type Registry and 640 this document adds another token type to this registry. 642 Type name: hotk 644 Additional Token Endpoint Response Parameters: (none) 646 HTTP Authentication Scheme(s): Holder of the key confirmation using 647 TLS 649 Change controller: IETF 651 Specification document(s): [[ this document ]] 653 5.4. Profile Registry 655 This document asks IANA to create a registry for profiles of 656 symmetric key-based holder-of-the-key mechanisms. The policy for 657 adding new entries to the registry is "Specification Required". IANA 658 is asked to populate the registry with the following values: 660 o Profile name: jws 661 o Change controller: IETF 663 o Specification document(s): [[ this document ]] 665 o Profile name: mac 667 o Change controller: IETF 669 o Specification document(s): [[ this document ]] 671 6. Acknowledgements 673 The author would like to thank the OAuth working group and 674 participants of the Internet Identity Workshop for their discussion 675 input that lead to this document. 677 7. References 679 7.1. Normative References 681 [1] Hardt, D., "The OAuth 2.0 Authorization Framework", 682 draft-ietf-oauth-v2-31 (work in progress), August 2012. 684 [2] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 685 (JWT)", draft-ietf-oauth-json-web-token-06 (work in progress), 686 December 2012. 688 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 689 Levels", BCP 14, RFC 2119, March 1997. 691 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 692 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 693 HTTP/1.1", RFC 2616, June 1999. 695 [5] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature 696 (JWS)", draft-ietf-jose-json-web-signature-08 (work in 697 progress), December 2012. 699 [6] Richer, J., Mills, W., and H. Tschofenig, "OAuth 2.0 Message 700 Authentication Code (MAC) Tokens", 701 draft-ietf-oauth-v2-http-mac-02 (work in progress), 702 November 2012. 704 [7] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. 705 Kivinen, "Out-of-Band Public Key Validation for Transport Layer 706 Security (TLS)", draft-ietf-tls-oob-pubkey-07 (work in 707 progress), February 2013. 709 [8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 710 Protocol Version 1.2", RFC 5246, August 2008. 712 [9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 713 R., and W. Polk, "Internet X.509 Public Key Infrastructure 714 Certificate and Certificate Revocation List (CRL) Profile", 715 RFC 5280, May 2008. 717 [10] Jones, M., "JSON Web Key (JWK)", 718 draft-ietf-jose-json-web-key-08 (work in progress), 719 December 2012. 721 7.2. Informative References 723 [11] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: 724 Bearer Token Usage", draft-ietf-oauth-v2-bearer-23 (work in 725 progress), August 2012. 727 [12] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 728 "Assertion Framework for OAuth 2.0", 729 draft-ietf-oauth-assertions-10 (work in progress), 730 January 2013. 732 [13] Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E. 733 Nabbus, "NIST Special Publication 800-63-1, INFORMATION 734 SECURITY", December 2008. 736 [14] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 737 April 2010. 739 Authors' Addresses 741 John Bradley 742 Ping Identity 744 Email: ve7jtb@ve7jtb.com 746 Phil Hunt 747 Oracle Corporation 749 Email: phil.hunt@yahoo.com 751 Tony Nadalin 752 Microsoft 754 Email: tonynad@microsoft.com 756 Hannes Tschofenig 757 Nokia Siemens Networks 758 Linnoitustie 6 759 Espoo 02600 760 Finland 762 Phone: +358 (50) 4871445 763 Email: Hannes.Tschofenig@gmx.net 764 URI: http://www.tschofenig.priv.at