<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6749 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC6750 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml">
]>


<rfc ipr="trust200902" docName="draft-hardt-oauth-mutual-02" category="info">

  <front>
    <title abbrev="I-D">Reciprocal OAuth</title>

    <author initials="D." surname="Hardt" fullname="Dick Hardt">
      <organization>Amazon</organization>
      <address>
        <email>dick.hardt@gmail.com</email>
      </address>
    </author>

    <date year="2018" month="January" day="16"/>

    
    
    

    <abstract>


<t>There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seemless experience for the user to grant access to a pair of protected resources.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>In the usual three legged, authorization code grant, the OAuth flow enables a resource owner (user) to enable a client (party A) to be granted authorization to access a protected resource (party B). If party A also has a protected resource that the user would like to let party B access, then a complete OAuth flow, but in the reverse direction, must be performed.</t>

<t>Reciprocal OAuth enables party A to obtain constent from the user to grant access to a protected resource at party A, and to short circuit the OAuth flow by passing an authorization code to party B using the acces token party A obtained from party B to provide party B the context of the user. This simplifies the user experience for each party to obtain acces tokens from the other.</t>

<section anchor="terminology" title="Terminology">

<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”,
“SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119
<xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="reciprocal-authorization-flow" title="Reciprocal Authorization Flow">

<t>The reciprocal authorization flow starts after the client (party A) has obtained an access token from the authorization server (party B) per <xref target="RFC6749"/> 4.1 Authorization Code Grant.</t>

<section anchor="user-consent" title="User Consent">
<t>Party A obtains consent from the user to grant access to protected resources at party A. The consent represents the scopes party B had preconfigured at party A.</t>

</section>
<section anchor="reciprocal-authorization-code" title="Reciprocal Authorization Code">
<t>Party A generates an authorization code representing the access granted to party B by the user. Party A then makes a request to party B’s token endpoint authenticating per <xref target="RFC6749"/> 2.3 and sending the following parameters using the “application/x-www-form-urlencoded” format per <xref target="RFC6749"/> Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:</t>

<t>grant_type
         REQUIRED.  Value MUST be set to “urn:ietf:params:oauth:grant-type:reciprocal”.</t>

<t>code
         REQUIRED.  The authorization code generated by party A.</t>

<t>client_id
         REQUIRED, party A’a client ID.</t>

<t>access_token
         REQUIRED, the access token obtained from Party B. Used to provide user context. 
         [DH: security concern passing the access token in the body?]</t>

<t>For example, the client makes the following HTTP request using TLS
   (with extra line breaks for display purposes only):</t>

<figure><artwork><![CDATA[
 POST /token HTTP/1.1
 Host: server.example.com
 Authorization: Basic ej4hsyfishwssjdusisdhkjsdksusdhjkjsdjk
 Content-Type: application/x-www-form-urlencoded

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3reciprocal&code=hasdyubasdjahsbdkjbasd&client_id=example.com&access_token=sadadojsadlkjasdkljxxlkjdas
]]></artwork></figure>

<t>Party B MUST then verify the access token was granted to the client identified by the client_id.</t>

<t>Party B MUST respond with either an HTTP 200 (OK) response if the request is valid, or an HTTP 400 “Bad Request” if it is not.</t>

<t>Party B then plays the role of the client to make an access token request per <xref target="RFC6749"/> 4.1.3.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>TBD.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>TBD.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC6749;
&RFC6750;


    </references>



<section anchor="document-history" title="Document History">

<section anchor="draft-hardt-oauth-mutual-00" title="draft-hardt-oauth-mutual-00">

<t><list style="symbols">
  <t>Initial version.</t>
</list></t>

</section>
<section anchor="draft-hardt-oauth-mutual-01" title="draft-hardt-oauth-mutual-01">

<t><list style="symbols">
  <t>renamed to Reciprocal OAuth</t>
  <t>clarified user consent in reciprocal flow</t>
  <t>changed authentication to be client authentication per <xref target="RFC6749"/> 2.3</t>
</list></t>

</section>
<section anchor="draft-hardt-oauth-mutual-02" title="draft-hardt-oauth-mutual-02">

<t><list style="symbols">
  <t>changed grant type to URI</t>
  <t>added valid request response codes in 2.2</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAAxUXloAA41X/W8aNxj+/f4Ki6pdK3HXkGZdixRtENIFLS1ZSjZN01SZ
swHDcWa2L4RW/d/3vPbdcYREWaUW9/x+v8/74TiOI6dcJrvsWqZqbXTKMzbq
FW4e8cnEyNsuG8aDSOg05ytQCcOnLp5zI1ysOcjiVeEKnsVHx5HgDhTHR513
8VEn7ryNUnyYabPtMpVPdQTxXeZMYd3x0dF7MEQkQJtuxOKI4Y/KbZcNEnZB
4v2XoHSg0mXjozYznquv3Cmdd1lvxb/q3F/IFVcZbAR54k38ZUZfklSvoijX
ZgWWWwl17PrD2XGn8748vv3pZHf88agbRWRvTR7Fccz4xDrDUxdF47k0knH8
dWolLdvMZc44K6w0bM4tjmuuDNNThnA6mTopmJFWFyYFtZtzxza6yATL1BIy
NC7/LaR1jKcgsPRF8nTOtIOihP05V5kMKWHTTG9AsF0rpCnbMpnzCS5BGNSD
dWZ4DlEszZTMmzL5A+a0A7nKZ16Gym+lsbJiIrsUSBmHf0IoijfQQUYkB3Ap
bSH3VxqxsVKuMpIi79bSwJZUMsT0IVubJj4euSTkYaWEyGQUPWPD3BktipTM
iqJhXooGGHEyUrJMzmZStFlAWQkYlmohg+a259hFtuFCpZXpTQ5bX5LFr3xm
QsTr+L5cc+O2rOcvJ6VgmL2vk3wLXj6UhUpI/1XChvA9SGQ8s7oC1CGPx1Ed
zH1AZdKVUvqlXu8qoRSlsMZ10+02mxQOuffSUPEeAgKJ95FtsxUKllxDGqko
pEhYFEWP5r8yH3boieOKIp5bR8GaGr16CgCHnvLKmR5SmQuis4itY6kyaaHc
/SxOtqC3lkBNwD1MPgRU0SlshX1vBK6WCFPlQrAftnjDKx5iN/pWQVL9CQLg
pZN3jtBbuZiw8VxZZhVirqbKV3/p/L2q8AUfpO3i1jDJ7mIX2gIK4BkbS7NS
uc70bFsWALShVRcrWaF7KbcAhxGWtT7efB632uGXfRr58/X57zfD6/NBqx21
Pl/0Li/poz9UFJ8vRjeXg91px3k2+vjx/NPg3F9+7P0FGZSe1uhqPBx96l22
Qo/0ZaEQG7M20pcGbJQ2NWqC/8DN/tkV65y0qfsyasrRt29le/7+nfxstpre
XjY/IN2+HwMsNcl+wj0irENkUUdTJ0MDOiheKrM62zzfQZLgUId+XzTSeEu9
oSpeKhDmbad58v07O0k69ww+I/j9SqCnGkIGbwgLZ6gPmBNd7cHO+rr5X2Xz
0JzZVQ2hUNbCjEQa6BTAaFO9rou2jzgISJMgnqpZYSgYOzne4keTQb7VLswk
2iamv32kBGsr9srP1u2zUaIo5109VfJ9N1vxZdmsw/zcMf1QpU7mYq0VBasg
Foe56VXeT9Vx8sb3FpgkKpOmOgN4PDU32EMAHttoGC2+RlWn3qnXd/Fms4mp
PcaFyVDWcFK0WFgiDrT11mvScwfvNgptC20Z6wqWC2oMxEs60Eduxh/id1Vn
vhiPr2pXyRW3jSdabLGfYPXxgfuCzUD6Tcj/qYo7YewPnhWS+cqf0Gz2wWoV
Ju8q6aZd76Dt+oWu60XFJKq7K6sWARYyybEHNYwP6iMM2hIIIrTlCkgkydfg
FyUOxbUryh/qOTscBK6Aky8+uw8xNrAUELDfwwN++gkVnmh2cl9aZQuHq7Xk
vwcXXcQrLQziTQSpNHk9Xw60lbmivPz8D43JD9Tc7zgN3Xaz9QTs7sNsL8MB
aOPLz2TLSw8TmGY4hnwOBUbypfWjQyi7zjiCW5i1thCq82z7KqCCsasRUv46
GEfyX3eSTri50NZ1yyaWlCb6Tdnf7tV2l/W5VSmTi5O53U6VnW+sXQiYaMV8
ubBiaQucFnRcLIOAM4olcDQmHLEna6U0dwfjU4Dz+ZsewRM/AaA4eIjidwfS
5292KH1Bsk7RzMW2mODfBZ/biVgu6PyiBtxpw9sXTUCdWi640Av8ZMsFeJbZ
4u4OR8Etcll2t36oI9+CEDs13R7iYMP3elkj8QAbahfLgKg6W21Xck8DOuRa
oymF5Cua+9ROPUzwgmIvR7+9KomwsalpucAF/GATuOWZwvqrd1wn4Gr10eOv
A1WLuJQnzrVr6PfOEawCRo3GzlsuNqUf8IowfDAsK/0PDMPkjZ96bNj71PND
D7EwHhOI7rg/8MO+ly5zvcmkmEnaYuob2v0nPF0SzaBccdiFsg7vSz+YHn+Z
HoEbrwW8XzC0aL2FxuQJng7xGEnvT5/Bg9dxjEBwExJZNQ8/YFXe3EZo/yDa
Oc9n5bOgGkPhXTCpI3rv7oER9YTNx1FDU9gRqEBIy831EHd4xOHGw6LOU40f
Kh1L1h8nEBT9B47qOEEaEAAA

-->

</rfc>

