idnits 2.17.1 draft-ietf-oauth-dyn-reg-16.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 6, 2014) is 3724 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) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group J. Richer 3 Internet-Draft The MITRE Corporation 4 Intended status: Standards Track M. Jones 5 Expires: August 10, 2014 Microsoft 6 J. Bradley 7 Ping Identity 8 M. Machulak 9 Newcastle University 10 P. Hunt 11 Oracle Corporation 12 February 6, 2014 14 OAuth 2.0 Dynamic Client Registration Core Protocol 15 draft-ietf-oauth-dyn-reg-16 17 Abstract 19 This specification defines mechanisms used to dynamically register 20 OAuth 2.0 clients at authorization servers. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 10, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 60 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Relationship between Grant Types and Response Types . . . 9 62 3. Software Statement . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Client Registration Endpoint . . . . . . . . . . . . . . . . . 10 64 4.1. Client Registration Request . . . . . . . . . . . . . . . 11 65 4.2. Client Registration Response . . . . . . . . . . . . . . . 13 66 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.1. Client Information Response . . . . . . . . . . . . . . . 13 68 5.2. Client Registration Error Response . . . . . . . . . . . . 15 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 6.1. OAuth Registration Client Metadata Registry . . . . . . . 16 71 6.1.1. Registration Template . . . . . . . . . . . . . . . . 17 72 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 17 73 6.2. OAuth Token Endpoint Authentication Methods Registry . . . 18 74 6.2.1. Registration Template . . . . . . . . . . . . . . . . 18 75 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 19 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 80 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 22 81 A.1. Open versus Protected Dynamic Client Registration . . . . 22 82 A.1.1. Open Dynamic Client Registration . . . . . . . . . . . 22 83 A.1.2. Protected Dynamic Client Registration . . . . . . . . 22 84 A.2. Registration Without or With Software Statements . . . . . 22 85 A.2.1. Registration Without a Software Statement . . . . . . 22 86 A.2.2. Registration With a Software Statement . . . . . . . . 22 87 A.3. Registration by the Client or the Developer . . . . . . . 23 88 A.3.1. Registration by the Client . . . . . . . . . . . . . . 23 89 A.3.2. Registration by the Developer . . . . . . . . . . . . 23 90 A.4. Client ID per Client Instance or per Client Software . . . 23 91 A.4.1. Client ID per Client Software Instance . . . . . . . . 23 92 A.4.2. Client ID Shared between all Instances of Client 93 Software . . . . . . . . . . . . . . . . . . . . . . . 23 94 A.5. Stateful or Stateless Registration . . . . . . . . . . . . 23 95 A.5.1. Stateful Client Registration . . . . . . . . . . . . . 24 96 A.5.2. Stateless Client Registration . . . . . . . . . . . . 24 97 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 98 Appendix C. Document History . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 101 1. Introduction 103 In order for an OAuth 2.0 client to utilize an OAuth 2.0 104 authorization server, the client needs specific information to 105 interact with the server, including an OAuth 2.0 Client ID to use at 106 that server. This specification describes how an OAuth 2.0 client 107 can be dynamically registered with an authorization server to obtain 108 this information. 110 As part of the registration process, this specification also defines 111 a mechanism for the client to present the authorization server with a 112 set of metadata, such as a set of valid redirection URIs. This 113 metadata can either be communicated in a self-asserted fashion or as 114 a set of metadata called a software statement, which can be signed; 115 in the case of a signed software statement, the signer is vouching 116 for the validity of the data about the client. 118 The mechanisms defined in this specification can be used either for a 119 client to dynamically register itself with authorization servers or 120 for a client developer to programmatically register the client with 121 authorization servers. 123 1.1. Notational Conventions 125 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 126 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 127 document are to be interpreted as described in [RFC2119]. 129 Unless otherwise noted, all the protocol parameter names and values 130 are case sensitive. 132 1.2. Terminology 134 This specification uses the terms "Access Token", "Refresh Token", 135 "Authorization Code", "Authorization Grant", "Authorization Server", 136 "Authorization Endpoint", "Client", "Client Identifier", "Client 137 Secret", "Protected Resource", "Resource Owner", "Resource Server", 138 "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749] 139 and uses the term "Claim" defined by JSON Web Token (JWT) [JWT]. 141 This specification defines the following terms: 143 Client Developer The person or organization that builds a client 144 software package and prepares it for distribution. A client 145 developer obtains a software statement from a software publisher, 146 or self-generates one for the purposes of facilitating client 147 registration. 149 Client Instance A deployed instance of a piece of client software. 150 Multiple instances of the same piece of client software MAY use 151 the same Client ID value at an authorization server, provided that 152 the Redirection URI values and potentially other values dictated 153 by authorization server policy are the same for all instances. 155 Client Software Software implementing an OAuth 2.0 client. 157 Client Registration Endpoint OAuth 2.0 endpoint through which a 158 client can be registered at an authorization server. The means by 159 which the URL for this endpoint is obtained are out of scope for 160 this specification. 162 Initial Access Token OAuth 2.0 access token optionally issued by an 163 Authorization Server and used to authorize calls to the client 164 registration endpoint. The type and format of this token are 165 likely service-specific and are out of scope for this 166 specification. The means by which the authorization server issues 167 this token as well as the means by which the registration endpoint 168 validates this token are out of scope for this specification. 170 Deployment Organization An administrative security domain under 171 which, a software API is deployed and protected by an OAuth 2.0 172 framework. In simple cloud deployments, the software API 173 publisher and the deployment organization may be the same. In 174 other scenarios, a software publisher may be working with many 175 different deployment organizations. 177 Software API Deployment A deployment instance of a software API that 178 is protected by OAuth 2.0 in a particular deployment organization 179 domain. For any particular software API, there may be one or more 180 deployments. A software API deployment typically has an 181 associated OAuth 2.0 authorization server endpoint as well as a 182 client registration endpoint. The means by which endpoints are 183 obtained (discovery) are out of scope for this specification. 185 Software API Publisher The organization that defines a particular 186 web accessible API that may deployed in one or more deployment 187 environments. A publisher may be any commercial, public, private, 188 or open source organization that is responsible for publishing and 189 distributing software that may be protected via OAuth 2.0. A 190 software API publisher may issue software statements which client 191 developers use to distribute with their software to facilitate 192 registration. In some cases a software API publisher and a client 193 developer may be the same organization. 195 Software Statement A JSON Web Token (JWT) [JWT] that asserts 196 metadata values about the client software. The JWT MUST be signed 197 and contain an "iss" (issuer) claim if its metadata values are 198 being attested to by the issuer; if the metadata values are not 199 being attested to, the JWT MAY be unsigned. This can be used by 200 the registration system to qualify clients for eligibility to 201 register. It may also be accepted by some authorization servers 202 directly as a Client ID value, without prior registration. 204 1.3. Protocol Flow 206 +--------(A)- Initial Access Token (OPTIONAL) 207 | 208 | +----(B)- Software Statement (OPTIONAL) 209 | | 210 v v 211 +-----------+ +---------------+ 212 | |--(C)- Client Registration Request -->| Client | 213 | Client or | | Registration | 214 | Developer |<-(D)- Client Information Response ---| Endpoint | 215 | | +---------------+ 216 +-----------+ 218 Figure 1: Abstract Dynamic Client Registration Flow 220 The abstract OAuth 2.0 client dynamic registration flow illustrated 221 in Figure 1 describes the interaction between the client or developer 222 and the endpoint defined in this specification. This figure does not 223 demonstrate error conditions. This flow includes the following 224 steps: 226 (A) Optionally, the client or developer is issued an initial access 227 token giving access to the client registration endpoint. The 228 method by which the initial access token is issued to the client 229 or developer is out of scope for this specification. 231 (B) Optionally, the client or developer is issued a software 232 statement for use with the client registration endpoint. The 233 method by which the software statement is issued to the client or 234 developer is out of scope for this specification. 236 (C) The client or developer calls the client registration endpoint 237 with its desired registration metadata, optionally including the 238 initial access token from (A) if one is required by the 239 authorization server. 241 (D) The authorization server registers the client and returns the 242 client's registered metadata, a client identifier that is unique 243 at the server, a set of client credentials such as a client secret 244 if applicable for this client, and possibly other values. 246 2. Client Metadata 248 Clients have a set of metadata values associated with their unique 249 client identifier at an authorization server, such as the list of 250 valid redirect URIs. 252 The client metadata values are used in two ways: 254 o as input values to registration requests, and 256 o as output values in registration responses. 258 These client metadata values are defined by this specification: 260 redirect_uris Array of redirect URIs for use in redirect-based flows 261 such as the authorization code and implicit grant types. It is 262 RECOMMENDED that clients using these flows register this 263 parameter, and an authorization server SHOULD require registration 264 of valid redirect URIs for all clients that use these grant types 265 to protect against token and credential theft attacks. 267 token_endpoint_auth_method The requested authentication method for 268 the token endpoint. Values defined by this specification are: 270 * "none": The client is a public client as defined in OAuth 2.0 271 and does not have a client secret. 273 * "client_secret_post": The client uses the HTTP POST parameters 274 defined in OAuth 2.0 section 2.3.1. 276 * "client_secret_basic": the client uses HTTP Basic defined in 277 OAuth 2.0 section 2.3.1 279 Additional values can be defined via the IANA OAuth Token Endpoint 280 Authentication Methods Registry Section 6.2. Absolute URIs can 281 also be used as values for this parameter without being 282 registered. If unspecified or omitted, the default is 283 "client_secret_basic", denoting HTTP Basic Authentication Scheme 284 as specified in Section 2.3.1 of OAuth 2.0. 286 grant_types Array of OAuth 2.0 grant types that the Client may use. 287 These grant types are defined as follows: 289 * "authorization_code": The Authorization Code Grant described in 290 OAuth 2.0 Section 4.1 292 * "implicit": The Implicit Grant described in OAuth 2.0 Section 293 4.2 295 * "password": The Resource Owner Password Credentials Grant 296 described in OAuth 2.0 Section 4.3 298 * "client_credentials": The Client Credentials Grant described in 299 OAuth 2.0 Section 4.4 301 * "refresh_token": The Refresh Token Grant described in OAuth 2.0 302 Section 6. 304 * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer 305 Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. 307 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 308 Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles 309 [OAuth.SAML2]. 311 Authorization Servers MAY allow for other values as defined in 312 grant type extensions to OAuth 2.0. The extension process is 313 described in OAuth 2.0 Section 2.5. If the token endpoint is used 314 in the grant type, the value of this parameter MUST be the same as 315 the value of the "grant_type" parameter passed to the token 316 endpoint defined in the extension. 318 response_types Array of the OAuth 2.0 response types that the Client 319 may use. These response types are defined as follows: 321 * "code": The Authorization Code response described in OAuth 2.0 322 Section 4.1. 324 * "token": The Implicit response described in OAuth 2.0 Section 325 4.2. 327 Authorization servers MAY allow for other values as defined in 328 response type extensions to OAuth 2.0. The extension process is 329 described in OAuth 2.0 Section 2.5. If the authorization endpoint 330 is used by the grant type, the value of this parameter MUST be the 331 same as the value of the "response_type" parameter passed to the 332 authorization endpoint defined in the extension. 334 Authorization servers MUST accept all fields in this list. 335 Extensions and profiles of this specification MAY expand this list. 336 For instance, the [OAuth.Registration.Metadata] specification defines 337 additional client metadata values. The authorization server MUST 338 ignore any client metadata values sent by the Client that it does not 339 understand. 341 Client metadata values can either be communicated directly in the 342 body of a registration request, as described in Section 4.1, or 343 included as claims in a software statement, as described in 344 Section 3. If the same client metadata name is present in both 345 locations, the value in the software statement SHOULD take 346 precedence. 348 2.1. Relationship between Grant Types and Response Types 350 The "grant_types" and "response_types" values described above are 351 partially orthogonal, as they refer to arguments passed to different 352 endpoints in the OAuth protocol. However, they are related in that 353 the "grant_types" available to a client influence the 354 "response_types" that the client is allowed to use, and vice versa. 355 For instance, a "grant_types" value that includes 356 "authorization_code" implies a "response_types" value that includes 357 "code", as both values are defined as part of the OAuth 2.0 358 authorization code grant. As such, a server supporting these fields 359 SHOULD take steps to ensure that a client cannot register itself into 360 an inconsistent state. 362 The correlation between the two fields is listed in the table below. 364 +-----------------------------------------------+-------------------+ 365 | grant_types value includes: | response_types | 366 | | value includes: | 367 +-----------------------------------------------+-------------------+ 368 | authorization_code | code | 369 | implicit | token | 370 | password | (none) | 371 | client_credentials | (none) | 372 | refresh_token | (none) | 373 | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | 374 | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | 375 +-----------------------------------------------+-------------------+ 377 Extensions and profiles of this document that introduce new values to 378 either the "grant_types" or "response_types" parameter MUST document 379 all correspondences between these two parameter types. 381 3. Software Statement 383 A Software Statement is a JSON Web Token (JWT) [JWT] that asserts 384 metadata values about the client software. The JWT MUST be signed 385 and contain an "iss" (issuer) claim if its metadata values are being 386 attested to by the issuer; if the metadata values are not being 387 attested to, the JWT MAY be unsigned. This can be used by the 388 registration system to qualify clients for eligibility to register. 389 It may also be accepted by some authorization servers directly as a 390 Client ID value, without prior registration. 392 To obtain a software statement, a client developer may generate a 393 client specific JWT, or a client developer may register with a 394 software API publisher to obtain a software statement. The statement 395 is typically distributed with all copies of a client application. 397 The criteria by which authorization servers determine whether to 398 trust and utilize the information in a software statement is beyond 399 the scope of this specification. 401 If the authorization server determines that the claims in a software 402 statement uniquely identify a piece of software, the same Client ID 403 value MAY be returned for all dynamic registrations using that 404 software statement. However, authorization servers MAY alternatively 405 return a unique Client ID value for each dynamic registration of a 406 piece of software. 408 In some cases, authorization servers MAY choose to accept a software 409 statement value directly as a Client ID in an authorization request, 410 without a prior dynamic client registration having been performed. 411 The circumstances under which an authorization server would do so, 412 and the specific software statement characteristics required in this 413 case, are beyond the scope of this specification. 415 4. Client Registration Endpoint 417 The client registration endpoint is an OAuth 2.0 endpoint defined in 418 this document that is designed to allow a client to be registered 419 with the authorization server. The client registration endpoint MUST 420 accept HTTP POST messages with request parameters encoded in the 421 entity body using the "application/json" format. The client 422 registration endpoint MUST be protected by a transport-layer security 423 mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] 424 and/or TLS 1.0 [RFC2246] and MAY support additional transport-layer 425 mechanisms meeting its security requirements. When using TLS, the 426 Client MUST perform a TLS/SSL server certificate check, per RFC 6125 427 [RFC6125]. 429 The client registration endpoint MAY be an OAuth 2.0 protected 430 resource and accept an initial access token in the form of an OAuth 431 2.0 [RFC6749] access token to limit registration to only previously 432 authorized parties. The method by which the initial access token is 433 obtained by the registrant is generally out-of-band and is out of 434 scope for this specification. The method by which the initial access 435 token is verified and validated by the client registration endpoint 436 is out of scope for this specification. 438 To support open registration and facilitate wider interoperability, 439 the client registration endpoint SHOULD allow initial registration 440 requests with no authorization (which is to say, with no OAuth 2.0 441 access token in the request). These requests MAY be rate-limited or 442 otherwise limited to prevent a denial-of-service attack on the client 443 registration endpoint. 445 The client registration endpoint MUST ignore all parameters it does 446 not understand. 448 4.1. Client Registration Request 450 This operation registers a new client to the authorization server. 451 The authorization server assigns this client a unique client 452 identifier, optionally assigns a client secret, and associates the 453 metadata given in the request with the issued client identifier. The 454 request includes any client metadata parameters being specified for 455 the client during the registration. The authorization server MAY 456 provision default values for any items omitted in the client 457 metadata. 459 Client metadata values may also be provided in a software statement, 460 as described in Section 3. Software statements are included in 461 registration requests using this registration parameter: 463 software_statement A software statement containing client metadata 464 values about the client software as claims. 466 To register, the client or developer sends an HTTP POST to the client 467 registration endpoint with a content type of "application/json". The 468 HTTP Entity Payload is a JSON [RFC4627] document consisting of a JSON 469 object and all parameters as top-level members of that JSON object. 471 For example, if the server supports open registration (with no 472 initial access token), the client could send the following 473 registration request to the client registration endpoint: 475 The following is a non-normative example request not using an initial 476 access token (with line wraps within values for display purposes 477 only): 479 POST /register HTTP/1.1 480 Content-Type: application/json 481 Accept: application/json 482 Host: server.example.com 484 { 485 "redirect_uris":[ 486 "https://client.example.org/callback", 487 "https://client.example.org/callback2"], 488 "token_endpoint_auth_method":"client_secret_basic", 489 "example_extension_parameter": "example_value" 490 } 492 Alternatively, if the server supports authorized registration, the 493 developer or the client will be provisioned with an initial access 494 token (the method by which the initial access token is obtained is 495 out of scope for this specification). The developer or client sends 496 the following authorized registration request to the client 497 registration endpoint. Note that the initial access token sent in 498 this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth 499 2.0 token type could be used by an authorization server. 501 The following is a non-normative example request using an initial 502 access token (with line wraps within values for display purposes 503 only): 505 POST /register HTTP/1.1 506 Content-Type: application/json 507 Accept: application/json 508 Authorization: Bearer ey23f2.adfj230.af32-developer321 509 Host: server.example.com 511 { 512 "redirect_uris":["https://client.example.org/callback", 513 "https://client.example.org/callback2"], 514 "token_endpoint_auth_method":"client_secret_basic", 515 "example_extension_parameter": "example_value" 516 } 518 In the following example, some registration parameters are conveyed 519 as claims in a software statement (with line wraps within values for 520 display purposes only): 522 POST /register HTTP/1.1 523 Content-Type: application/json 524 Accept: application/json 525 Host: server.example.com 527 { 528 "redirect_uris":[ 529 "https://client.example.org/callback", 530 "https://client.example.org/callback2" 531 ], 532 "software_statement":"eyJhbGciOiJFUzI1NiJ9. 533 eyJpc3Mi[...omitted for brevity...]. 534 J9l-ZhwP[...omitted for brevity...]", 535 "extension_parameter":"foo" 536 } 538 4.2. Client Registration Response 540 Upon successful registration, the authorization server generates a 541 new client identifier for the client. This client identifier MUST be 542 unique at the server and MUST NOT be in use by any other client. The 543 server responds with an HTTP 201 Created code and a body of type 544 "application/json" with content as described in Section 5.1. 546 Upon an unsuccessful registration, the authorization server responds 547 with an error, as described in Section 5.2. 549 5. Responses 551 The following responses are sent in response to registration 552 requests. 554 5.1. Client Information Response 556 The response contains the client identifier as well as the client 557 secret, if the client is a confidential client. The response MAY 558 contain additional fields as specified by extensions to this 559 specification. 561 client_id REQUIRED. Unique client identifier. It MUST NOT be 562 currently valid for any other distinct registered client. It MAY 563 be the same as the Client ID value used by other instances of this 564 client, provided that the Redirection URI values and potentially 565 other values dictated by authorization server policy are the same 566 for all instances. 568 client_secret OPTIONAL. The client secret. If issued, this MUST be 569 unique for each "client_id". This value is used by confidential 570 clients to authenticate to the token endpoint as described in 571 OAuth 2.0 [RFC6749] Section 2.3.1. 573 client_id_issued_at OPTIONAL. Time at which the Client Identifier 574 was issued. The time is represented as the number of seconds from 575 1970-01-01T0:0:0Z as measured in UTC until the date/time. 577 client_secret_expires_at REQUIRED if "client_secret" is issued. 578 Time at which the "client_secret" will expire or 0 if it will not 579 expire. The time is represented as the number of seconds from 580 1970-01-01T0:0:0Z as measured in UTC until the date/time. 582 Additionally, the Authorization Server MUST return all registered 583 metadata about this client, including any fields provisioned by the 584 authorization server itself. The authorization server MAY reject or 585 replace any of the client's requested metadata values submitted 586 during the registration or update requests and substitute them with 587 suitable values. 589 The response is an "application/json" document with all parameters as 590 top-level members of a JSON object [RFC4627]. 592 If a software statement was used as part of the registration, its 593 value SHOULD be returned in the response and its value MUST be 594 returned if the authorization server supports registration management 595 operations [OAuth.Registration.Management] that would require its 596 presence in subsequent operations. Client metadata elements used 597 from the software statement MUST also be returned directly as top- 598 level client metadata values in the registration response (possibly 599 with different values, since the values requested and the values used 600 may differ). 602 Following is a non-normative example response: 604 HTTP/1.1 200 OK 605 Content-Type: application/json 606 Cache-Control: no-store 607 Pragma: no-cache 609 { 610 "client_id":"s6BhdRkqt3", 611 "client_secret": "cf136dc3c1fc93f31185e5885805d", 612 "client_id_issued_at":2893256800, 613 "client_secret_expires_at":2893276800, 614 "redirect_uris":[ 615 "https://client.example.org/callback", 616 "https://client.example.org/callback2"], 617 "grant_types": ["authorization_code", "refresh_token"], 618 "token_endpoint_auth_method": "client_secret_basic", 619 "example_extension_parameter": "example_value" 620 } 622 5.2. Client Registration Error Response 624 When an OAuth 2.0 error condition occurs, such as the client 625 presenting an invalid initial access token, the authorization server 626 returns an error response appropriate to the OAuth 2.0 token type. 628 When a registration error condition occurs, the authorization server 629 returns an HTTP 400 status code (unless otherwise specified) with 630 content type "application/json" consisting of a JSON object [RFC4627] 631 describing the error in the response body. 633 The JSON object contains two members: 635 error Single ASCII error code string. 637 error_description Human-readable ASCII text description of the error 638 used for debugging. 640 This specification defines the following error codes: 642 invalid_redirect_uri The value of one or more "redirect_uris" is 643 invalid. 645 invalid_client_metadata The value of one of the client metadata 646 fields is invalid and the server has rejected this request. Note 647 that an Authorization server MAY choose to substitute a valid 648 value for any requested parameter of a client's metadata. 650 invalid_software_statement The software statement presented is 651 invalid. 653 unapproved_software_statement The software statement presented is 654 not approved for use with this authorization server. 656 Following is a non-normative example of an error response (with line 657 wraps for display purposes only): 659 HTTP/1.1 400 Bad Request 660 Content-Type: application/json 661 Cache-Control: no-store 662 Pragma: no-cache 664 { 665 "error":"invalid_redirect_uri", 666 "error_description":"The redirect URI http://sketchy.example.com 667 is not allowed for this server." 668 } 670 6. IANA Considerations 672 6.1. OAuth Registration Client Metadata Registry 674 This specification establishes the OAuth Registration Client Metadata 675 registry. 677 OAuth registration client metadata values are registered with a 678 Specification Required ([RFC5226]) after a two-week review period on 679 the oauth-ext-review@ietf.org mailing list, on the advice of one or 680 more Designated Experts. However, to allow for the allocation of 681 values prior to publication, the Designated Expert(s) may approve 682 registration once they are satisfied that such a specification will 683 be published. 685 Registration requests must be sent to the oauth-ext-review@ietf.org 686 mailing list for review and comment, with an appropriate subject 687 (e.g., "Request to register OAuth Registration Client Metadata name: 688 example"). 690 Within the review period, the Designated Expert(s) will either 691 approve or deny the registration request, communicating this decision 692 to the review list and IANA. Denials should include an explanation 693 and, if applicable, suggestions as to how to make the request 694 successful. 696 IANA must only accept registry updates from the Designated Expert(s) 697 and should direct all requests for registration to the review mailing 698 list. 700 6.1.1. Registration Template 702 Client Metadata Name: The name requested (e.g., "example"). This 703 name is case sensitive. Names that match other registered names 704 in a case insensitive manner SHOULD NOT be accepted. 706 Client Metadata Description: 707 Brief description of the metadata value (e.g., "Example 708 description"). 710 Change controller: For Standards Track RFCs, state "IETF". For 711 others, give the name of the responsible party. Other details 712 (e.g., postal address, email address, home page URI) may also be 713 included. 715 Specification document(s): Reference to the document(s) that specify 716 the token endpoint authorization method, preferably including a 717 URI that can be used to retrieve a copy of the document(s). An 718 indication of the relevant sections may also be included but is 719 not required. 721 6.1.2. Initial Registry Contents 723 The initial contents of the OAuth Registration Client Metadata 724 registry are: 726 o Client Metadata Name: "redirect_uris" 727 o Client Metadata Description: Array of redirect URIs for use in 728 redirect-based flows 729 o Change controller: IESG 730 o Specification document(s): [[ this document ]] 732 o Client Metadata Name: "token_endpoint_auth_method" 733 o Client Metadata Description: Requested authentication method for 734 the token endpoint 735 o Change controller: IESG 736 o Specification document(s): [[ this document ]] 738 o Client Metadata Name: "grant_types" 739 o Client Metadata Description: Array of OAuth 2.0 grant types that 740 the Client may use 741 o Change controller: IESG 742 o Specification document(s): [[ this document ]] 743 o Client Metadata Name: "response_types" 744 o Client Metadata Description: Array of the OAuth 2.0 response types 745 that the Client may use 746 o Change controller: IESG 747 o Specification document(s): [[ this document ]] 749 6.2. OAuth Token Endpoint Authentication Methods Registry 751 This specification establishes the OAuth Token Endpoint 752 Authentication Methods registry. 754 Additional values for use as "token_endpoint_auth_method" metadata 755 values are registered with a Specification Required ([RFC5226]) after 756 a two-week review period on the oauth-ext-review@ietf.org mailing 757 list, on the advice of one or more Designated Experts. However, to 758 allow for the allocation of values prior to publication, the 759 Designated Expert(s) may approve registration once they are satisfied 760 that such a specification will be published. 762 Registration requests must be sent to the oauth-ext-review@ietf.org 763 mailing list for review and comment, with an appropriate subject 764 (e.g., "Request to register token_endpoint_auth_method value: 765 example"). 767 Within the review period, the Designated Expert(s) will either 768 approve or deny the registration request, communicating this decision 769 to the review list and IANA. Denials should include an explanation 770 and, if applicable, suggestions as to how to make the request 771 successful. 773 IANA must only accept registry updates from the Designated Expert(s) 774 and should direct all requests for registration to the review mailing 775 list. 777 6.2.1. Registration Template 779 Token Endpoint Authorization Method Name: The name requested (e.g., 780 "example"). This name is case sensitive. Names that match other 781 registered names in a case insensitive manner SHOULD NOT be 782 accepted. 784 Change controller: For Standards Track RFCs, state "IETF". For 785 others, give the name of the responsible party. Other details 786 (e.g., postal address, email address, home page URI) may also be 787 included. 789 Specification document(s): Reference to the document(s) that specify 790 the token endpoint authorization method, preferably including a 791 URI that can be used to retrieve a copy of the document(s). An 792 indication of the relevant sections may also be included but is 793 not required. 795 6.2.2. Initial Registry Contents 797 The initial contents of the OAuth Token Endpoint Authentication 798 Methods registry are: 800 o Token Endpoint Authorization Method Name: "none" 801 o Change controller: IESG 802 o Specification document(s): [[ this document ]] 804 o Token Endpoint Authorization Method Name: "client_secret_post" 805 o Change controller: IESG 806 o Specification document(s): [[ this document ]] 808 o Token Endpoint Authorization Method Name: "client_secret_basic" 809 o Change controller: IESG 810 o Specification document(s): [[ this document ]] 812 7. Security Considerations 814 Since requests to the client registration endpoint result in the 815 transmission of clear-text credentials (in the HTTP request and 816 response), the Authorization Server MUST require the use of a 817 transport-layer security mechanism when sending requests to the 818 registration endpoint. The server MUST support TLS 1.2 RFC 5246 819 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support additional 820 transport-layer mechanisms meeting its security requirements. When 821 using TLS, the Client MUST perform a TLS/SSL server certificate 822 check, per RFC 6125 [RFC6125]. 824 For clients that use redirect-based grant types such as 825 "authorization_code" and "implicit", authorization servers SHOULD 826 require clients to register their "redirect_uris". Requiring clients 827 to do so can help mitigate attacks where rogue actors inject and 828 impersonate a validly registered client and intercept its 829 authorization code or tokens through an invalid redirect URI. 831 Public clients MAY register with an authorization server using this 832 protocol, if the authorization server's policy allows them. Public 833 clients use a "none" value for the "token_endpoint_auth_method" 834 metadata field and are generally used with the "implicit" grant type. 835 Often these clients will be short-lived in-browser applications 836 requesting access to a user's resources and access is tied to a 837 user's active session at the authorization server. Since such 838 clients often do not have long-term storage, it's possible that such 839 clients would need to re-register every time the browser application 840 is loaded. Additionally, such clients may not have ample opportunity 841 to unregister themselves using the delete action before the browser 842 closes. To avoid the resulting proliferation of dead client 843 identifiers, an authorization server MAY decide to expire 844 registrations for existing clients meeting certain criteria after a 845 period of time has elapsed. 847 Since different OAuth 2.0 grant types have different security and 848 usage parameters, an authorization server MAY require separate 849 registrations for a piece of software to support multiple grant 850 types. For instance, an authorization server might require that all 851 clients using the "authorization_code" grant type make use of a 852 client secret for the "token_endpoint_auth_method", but any clients 853 using the "implicit" grant type do not use any authentication at the 854 token endpoint. In such a situation, a server MAY disallow clients 855 from registering for both the "authorization_code" and "implicit" 856 grant types simultaneously. Similarly, the "authorization_code" 857 grant type is used to represent access on behalf of an end user, but 858 the "client_credentials" grant type represents access on behalf of 859 the client itself. For security reasons, an authorization server 860 could require that different scopes be used for these different use 861 cases, and as a consequence it MAY disallow these two grant types 862 from being registered together by the same client. In all of these 863 cases, the authorization server would respond with an 864 "invalid_client_metadata" error response. 866 8. References 868 8.1. Normative References 870 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 871 (JWT)", draft-ietf-oauth-json-web-token (work in 872 progress), January 2014. 874 [OAuth.JWT] 875 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 876 (JWT) Profile for OAuth 2.0 Client Authentication and 877 Authorization Grants", draft-ietf-oauth-jwt-bearer (work 878 in progress), December 2013. 880 [OAuth.Registration.Management] 881 Richer, J., Jones, M., Bradley, J., Machulak, M., and P. 882 Hunt, "OAuth 2.0 Dynamic Client Registration Management 883 Protocol", draft-ietf-oauth-dyn-reg-management (work in 884 progress), February 2014. 886 [OAuth.SAML2] 887 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 888 Profile for OAuth 2.0 Client Authentication and 889 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 890 in progress), December 2013. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, March 1997. 895 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 896 RFC 2246, January 1999. 898 [RFC4627] Crockford, D., "The application/json Media Type for 899 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 901 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 902 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 903 May 2008. 905 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 906 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 908 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 909 Verification of Domain-Based Application Service Identity 910 within Internet Public Key Infrastructure Using X.509 911 (PKIX) Certificates in the Context of Transport Layer 912 Security (TLS)", RFC 6125, March 2011. 914 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 915 RFC 6749, October 2012. 917 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 918 Framework: Bearer Token Usage", RFC 6750, October 2012. 920 8.2. Informative References 922 [OAuth.Registration.Metadata] 923 Richer, J., Jones, M., Bradley, J., Machulak, M., and P. 924 Hunt, "OAuth 2.0 Dynamic Client Registration Metadata", 925 draft-ietf-oauth-dyn-reg-metadata (work in progress), 926 February 2014. 928 Appendix A. Use Cases 930 This appendix describes different ways that this specification can be 931 utilized, including describing some of the choices that may need to 932 be made. Some of the choices are independent and can be used in 933 combination, whereas some of the choices are interrelated. 935 A.1. Open versus Protected Dynamic Client Registration 937 A.1.1. Open Dynamic Client Registration 939 Authorization servers that support open registration allow 940 registrations to be made with no initial access token. This allows 941 all client software to register with the authorization server. 943 A.1.2. Protected Dynamic Client Registration 945 Authorization servers that support protected registration require 946 that an initial access token be used when making registration 947 requests. While the method by which a client or developer receives 948 this initial access token and the method by which the authorization 949 server validates this initial access token are out of scope for this 950 specification, a common approach is for the developer to use a manual 951 pre-registration portal at the authorization server that issues an 952 initial access token to the developer. 954 A.2. Registration Without or With Software Statements 956 A.2.1. Registration Without a Software Statement 958 When a software statement is not used in the registration request, 959 the authorization server must be willing to use client metadata 960 values without them being signed (and thereby attested to) by any 961 authority. (Note that this choice is independent of the Open versus 962 Protected choice, and that an initial access token is another 963 possible form of attestation.) 965 A.2.2. Registration With a Software Statement 967 A software statement can be used in a registration request to provide 968 attestation for a set of client metadata values for a piece of client 969 software by an authority. This can be useful when the authorization 970 server wants to restrict registration to client software attested to 971 by a set of authorities or when it wants to know that multiple 972 registration requests refer to the same piece of client software. 974 A.3. Registration by the Client or the Developer 976 A.3.1. Registration by the Client 978 In some use cases, client software will dynamically register itself 979 with an authorization server to obtain a Client ID and other 980 information needed to interact with the authorization server. In 981 this case, no Client ID for the authorization server is packaged with 982 the client software. 984 A.3.2. Registration by the Developer 986 In some cases, the developer (or development software being used by 987 the developer) will pre-register the client software with the 988 authorization server or a set of authorization servers. In this 989 case, the Client ID value(s) for the authorization server(s) can be 990 packaged with the client software. 992 A.4. Client ID per Client Instance or per Client Software 994 A.4.1. Client ID per Client Software Instance 996 In some cases, each deployed instance of a piece of client software 997 will dynamically register and obtain distinct Client ID values. This 998 can be advantageous, for instance, if the code flow is being used, as 999 it also enables each client instance to have its own client secret. 1000 This can be useful for native clients, which cannot maintain the 1001 secrecy of a client secret value packaged with the software, but 1002 which may be able to maintain the secrecy of a per-instance client 1003 secret. 1005 A.4.2. Client ID Shared between all Instances of Client Software 1007 In some cases, each deployed instance of a piece of client software 1008 will share a common Client ID value. For instance, this is often the 1009 case for native client using implicit flow, when no client secret is 1010 involved. Particular authorization servers might choose, for 1011 instance, to maintain a mapping between software statement values and 1012 Client ID values, and return the same Client ID value for all 1013 registration requests for a particular piece of software. The 1014 circumstances under which an authorization server would do so, and 1015 the specific software statement characteristics required in this 1016 case, are beyond the scope of this specification. 1018 A.5. Stateful or Stateless Registration 1019 A.5.1. Stateful Client Registration 1021 In some cases, authorization servers will maintain state about 1022 registered clients, typically indexing this state using the Client ID 1023 value. This state would typically include the client metadata values 1024 associated with the client registration, and possibly other state 1025 specific to the authorization server's implementation. When stateful 1026 registration is used, operations to support retrieving and/or 1027 updating this state may be supported, as described in the 1028 [OAuth.Registration.Management] specification. 1030 A.5.2. Stateless Client Registration 1032 In some cases, authorization servers will be implemented in a manner 1033 the enables them to not maintain any local state about registered 1034 clients. One means of doing this is to encode all the registration 1035 state in the returned Client ID value, and possibly encrypting the 1036 state to the authorization server to maintain the confidentiality and 1037 integrity of the state. 1039 Appendix B. Acknowledgments 1041 The authors thank the OAuth Working Group, the User-Managed Access 1042 Working Group, and the OpenID Connect Working Group participants for 1043 their input to this document. In particular, the following 1044 individuals have been instrumental in their review and contribution 1045 to various versions of this document: Amanda Anganes, Derek Atkins, 1046 Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, 1047 George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten 1048 Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat 1049 Sakimura, Christian Scholz, and Hannes Tschofenig. 1051 Appendix C. Document History 1053 [[ to be removed by the RFC editor before publication as an RFC ]] 1055 -16 1057 o Replaced references to draft-jones-oauth-dyn-reg-metadata and 1058 draft-jones-oauth-dyn-reg-management with 1059 draft-ietf-oauth-dyn-reg-metadata and 1060 draft-ietf-oauth-dyn-reg-management. 1062 o Addressed review comments by Phil Hunt and Tony Nadalin. 1064 -15 1065 o Partitioned the Dynamic Client Registration specification into 1066 core, metadata, and management specifications. This built on work 1067 first published as draft-richer-oauth-dyn-reg-core-00 and 1068 draft-richer-oauth-dyn-reg-management-00. 1070 o Added the ability to use Software Statements. This built on work 1071 first published as draft-hunt-oauth-software-statement-00 and 1072 draft-hunt-oauth-client-association-00. 1074 o Created the IANA OAuth Registration Client Metadata registry for 1075 registering Client Metadata values. 1077 o Defined Client Instance term and stated that multiple instances 1078 can use the same Client ID value under certain circumstances. 1080 o Rewrote the introduction. 1082 o Rewrote the Use Cases appendix. 1084 -14 1086 o Added software_id and software_version metadata fields 1088 o Added direct references to RFC6750 errors in read/update/delete 1089 methods 1091 -13 1093 o Fixed broken example text in registration request and in delete 1094 request 1096 o Added security discussion of separating clients of different grant 1097 types 1099 o Fixed error reference to point to RFC6750 instead of RFC6749 1101 o Clarified that servers must respond to all requests to 1102 configuration endpoint, even if it's just an error code 1104 o Lowercased all Terms to conform to style used in RFC6750 1106 -12 1108 o Improved definition of Initial Access Token 1110 o Changed developer registration scenario to have the Initial Access 1111 Token gotten through a normal OAuth 2.0 flow 1113 o Moved non-normative client lifecycle examples to appendix 1115 o Marked differentiating between auth servers as out of scope 1117 o Added protocol flow diagram 1119 o Added credential rotation discussion 1121 o Called out Client Registration Endpoint as an OAuth 2.0 Protected 1122 Resource 1124 o Cleaned up several pieces of text 1126 -11 1128 o Added localized text to registration request and response 1129 examples. 1131 o Removed "client_secret_jwt" and "private_key_jwt". 1133 o Clarified "tos_uri" and "policy_uri" definitions. 1135 o Added the OAuth Token Endpoint Authentication Methods registry for 1136 registering "token_endpoint_auth_method" metadata values. 1138 o Removed uses of non-ASCII characters, per RFC formatting rules. 1140 o Changed "expires_at" to "client_secret_expires_at" and "issued_at" 1141 to "client_id_issued_at" for greater clarity. 1143 o Added explanatory text for different credentials (Initial Access 1144 Token, Registration Access Token, Client Credentials) and what 1145 they're used for. 1147 o Added Client Lifecycle discussion and examples. 1149 o Defined Initial Access Token in Terminology section. 1151 -10 1153 o Added language to point out that scope values are service-specific 1155 o Clarified normative language around client metadata 1157 o Added extensibility to token_endpoint_auth_method using absolute 1158 URIs 1160 o Added security consideration about registering redirect URIs 1162 o Changed erroneous 403 responses to 401's with notes about token 1163 handling 1165 o Added example for initial registration credential 1167 -09 1169 o Added method of internationalization for Client Metadata values 1171 o Fixed SAML reference 1173 -08 1175 o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and 1176 x509_encryption_uri into a single jwks_uri parameter 1178 o Renamed grant_type to grant_types since it's a plural value 1180 o Formalized name of "OAuth 2.0" throughout document 1182 o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example 1183 grant types 1185 o Added response_types parameter and explanatory text on its use 1186 with and relationship to grant_types 1188 -07 1190 o Changed registration_access_url to registration_client_uri 1192 o Fixed missing text in 5.1 1194 o Added Pragma: no-cache to examples 1196 o Changed "no such client" error to 403 1198 o Renamed Client Registration Access Endpoint to Client 1199 Configuration Endpoint 1201 o Changed all the parameter names containing "_url" to instead use 1202 "_uri" 1204 o Updated example text for forming Client Configuration Endpoint URL 1206 -06 1207 o Removed secret_rotation as a client-initiated action, including 1208 removing client secret rotation endpoint and parameters. 1210 o Changed _links structure to single value registration_access_url. 1212 o Collapsed create/update/read responses into client info response. 1214 o Changed return code of create action to 201. 1216 o Added section to describe suggested generation and composition of 1217 Client Registration Access URL. 1219 o Added clarifying text to PUT and POST requests to specify JSON in 1220 the body. 1222 o Added Editor's Note to DELETE operation about its inclusion. 1224 o Added Editor's Note to registration_access_url about alternate 1225 syntax proposals. 1227 -05 1229 o changed redirect_uri and contact to lists instead of space 1230 delimited strings 1232 o removed operation parameter 1234 o added _links structure 1236 o made client update management more RESTful 1238 o split endpoint into three parts 1240 o changed input to JSON from form-encoded 1242 o added READ and DELETE operations 1244 o removed Requirements section 1246 o changed token_endpoint_auth_type back to 1247 token_endpoint_auth_method to match OIDC who changed to match us 1249 -04 1251 o removed default_acr, too undefined in the general OAuth2 case 1253 o removed default_max_auth_age, since there's no mechanism for 1254 supplying a non-default max_auth_age in OAuth2 1256 o clarified signing and encryption URLs 1258 o changed token_endpoint_auth_method to token_endpoint_auth_type to 1259 match OIDC 1261 -03 1263 o added scope and grant_type claims 1265 o fixed various typos and changed wording for better clarity 1267 o endpoint now returns the full set of client information 1269 o operations on client_update allow for three actions on metadata: 1270 leave existing value, clear existing value, replace existing value 1271 with new value 1273 -02 1275 o Reorganized contributors and references 1277 o Moved OAuth references to RFC 1279 o Reorganized model/protocol sections for clarity 1281 o Changed terminology to "client register" instead of "client 1282 associate" 1284 o Specified that client_id must match across all subsequent requests 1286 o Fixed RFC2XML formatting, especially on lists 1288 -01 1290 o Merged UMA and OpenID Connect registrations into a single document 1292 o Changed to form-parameter inputs to endpoint 1294 o Removed pull-based registration 1296 -00 1298 o Imported original UMA draft specification 1300 Authors' Addresses 1302 Justin Richer 1303 The MITRE Corporation 1305 Email: jricher@mitre.org 1307 Michael B. Jones 1308 Microsoft 1310 Email: mbj@microsoft.com 1311 URI: http://self-issued.info/ 1313 John Bradley 1314 Ping Identity 1316 Email: ve7jtb@ve7jtb.com 1318 Maciej Machulak 1319 Newcastle University 1321 Email: m.p.machulak@ncl.ac.uk 1322 URI: http://ncl.ac.uk/ 1324 Phil Hunt 1325 Oracle Corporation 1327 Email: phil.hunt@yahoo.com