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
