Thanks James. Comments are inline. > It sounds like you want to use OAuth2 to insert an human/HTML interaction > into a app/Atom exchange.
The proposal was designed to provide a single flow that would accommodate 0 or more human interaction requirements. Additionally, the scope should not limited to access protected feed but rather any protected resource. While the example usecase illustrated access to a protected feed, you can imagine this being used in more traditional flow scenarios, such as that of the Web Server client profile. For example, if a user has already negotiated an access token in the proposed manner, additional access tokens *could* be granted on the user's behalf without the requirement of a redirect. > OAuth2 can do that. > > You also want to use a direct OAuth2 flow for access control to the feed. > > Your "precondition_uri" addition to the token response is an attempt to > combine the 2 OAuth2 flows. I'd say it's an attempt to create a new flow that's more flexible and suitable for the type of interactions DiSo requires. > An alternative would be to run the 2 OAuth2 flows sequentially. > 1. app use a direct OAuth2 flow (eg the assertion flow) to get a token; > 2. app tries to get feed with token, but server demands a user-delegation > OAuth2 flow; > 3. app redirects user to service; Terms of Service are shown; user redirected > back; > 4. app tries to get feed again, which succeeds this time. > > This example illustrates that OAuth2 discovery needs to let a service > explicitly indicate whether a direct and/or user-delegation flow is required. > For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters: > 'user-uri' and 'token-uri'. If only one is present, only the corresponding > mode > is useful in this interaction. Interesting. > Another interesting facet of this example is what token the app uses > at step 4. Is it the token the app got in the first OAuth2 flow (step 1), > or the token from the second OAuth2 flow (step 3)? > > Presumably the second token overrides the first. > In this example, however, it may be sufficient to keep using the first token. > OAuth2 doesn’t need to make returning a token mandatory -- it is not > always required in a user-delegation flow. Also, when the user delegation flow is executed (step 3), how does the provider associate acknowledgement of the ToS with the assertion grant (step 1)? -- darren bounds dar...@cliqset.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
