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

[Dick Hardt <[e-mail]>]

Thanks for the feedback!

I'll break out my ASCII art skills.

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

> 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 <[e-mail]> wrote:
>
>> 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 <
>> [e-mail]> wrote:
>>
>>> 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?
>>>
>>
>> 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 A’s AS?
>>>
>>
>> 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
>>> concept.
>>>
>>
>> It is pretty much the same as OAuth with one extra flow. I can add if
>> that would help.
>>
>>
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> > Am 24.05.2018 um 22:28 schrieb [e-mail]:
>>> >
>>> >
>>> > 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
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>