Thanks for the feedback! I'll break out my ASCII art skills.
On Tue, Jul 17, 2018 at 2:56 PM, Rifaat Shekh-Yusef <rifaat.i...@gmail.com> 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 <dick.ha...@gmail.com> 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 < >> tors...@lodderstedt.net> 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 internet-dra...@ietf.org: >>> > >>> > >>> > 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 >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth