Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Jul 2018 17:22:37 +0200

Hi Dick,

I gave you draft a read and came up with the following questions:

Section 2: How does Party A know it is supposed to conduct a reciprocal OAuth flow if Party B does not indicate so in the authorization response?

Section 3

Party A is supposed to call the token endpoint of Party B using an authorization code generated by Party A. How does Party B interpret this code? Or does it just send this code back to Party A to obtain its access token for A?

Party B uses the access token issued to Party A in the first part of the flow (ordinary OAuth code flow) to identify the respective user account with Party B. Since the AS consumes its access token as an RS, does Party A need to include a certain scope in the code flow request in order to enable this part of the flow?

How is the AS of Party B supposed to determine the token endpoint of Party A’s AS?

I think a figure of the overall process would help to understand the concept. 

kind regards,
Torsten. 

> Am 24.05.2018 um 22:28 schrieb [email-masked]:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
> 
>        Title           : Reciprocal OAuth
>        Author          : Dick Hardt
> 	Filename        : draft-ietf-oauth-reciprocal-00.txt
> 	Pages           : 4
> 	Date            : 2018-05-24
> 
> Abstract:
>   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 seamless experience for the user to
>   grant access to a pair of protected resources.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Jul 2018 12:00:56 -0400

Thanks for the review Torsten. All good points to be clarified in the doc.
Responses inserted ...

On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Section 2: How does Party A know it is supposed to conduct a reciprocal
> OAuth flow if Party B does not indicate so in the authorization response?
>

Out of band configuration. Will clarify in next version.

>
> Section 3
>
> Party A is supposed to call the token endpoint of Party B using an
> authorization code generated by Party A. How does Party B interpret this
> code? Or does it just send this code back to Party A to obtain its access
> token for A?
>

Yes, per last sentence in Section 3. What language would clarify that?

>
> Party B uses the access token issued to Party A in the first part of the
> flow (ordinary OAuth code flow) to identify the respective user account
> with Party B. Since the AS consumes its access token as an RS, does Party A
> need to include a certain scope in the code flow request in order to enable
> this part of the flow?
>

Party A is using its own access token for context. Party B is not accessing
the user context / account.

> How is the AS of Party B supposed to determine the token endpoint of Party

Same as Party A learns Party B's token endpoint.

In practice, the flow could be started by either party. Both can initiate
and complete. I'll clarify in the next version.

> I think a figure of the overall process would help to understand the

It is pretty much the same as OAuth with one extra flow. I can add if that
would help.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 17 Jul 2018 14:56:46 -0400

Hi Dick,

I too reviewed the document, and had similar questions in mind.
I agree with Torsten, a figure would make it easier to follow and
understand.

Regards,
 Rifaat

On Tue, Jul 17, 2018 at 12:01 PM Dick Hardt <[email-masked]> wrote:

> Party A is using its own access token for context. Party B is not
> accessing the user context / account.
>
>
>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 17 Jul 2018 15:14:27 -0400

Thanks for the feedback!

I'll break out my ASCII art skills.

On Tue, Jul 17, 2018 at 2:56 PM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

>> Thanks for the review Torsten. All good points to be clarified in the
>> doc. Responses inserted ...
>>
>> It is pretty much the same as OAuth with one extra flow. I can add if
>> that would help.
>>
>>
>>>
>>> kind regards,
>>> Torsten.
>>>