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
