Darren, >> 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. precondition_uri seems to address a requirement for optional human interaction when an app starts accessing a protected resource. A solution that changes the token response can only add the human interaction: a) if OAuth is used for direct authentication/authorization of the app; and b) at the instant in time when the app does its direct OAuth flow. I'm note sure a requirement for human interaction will necessarily be tied to either of those conditions, which is why an independent OAuth2 flow for the human interaction is appealing. >> 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)? The server provides a user-authorization URI in step 2 which can encode details about the initial token. A new token issued in the second OAuth2 flow can encode the ToS acknowledgement along with details from the initial token. OAuth2 needs a way to identity an existing token when making a subsequent OAuth2 flow -- not just for this example, but when an app asks for extra permissions. The spec might not need to explicitly define this if, as in this example, the server can dynamically provide a user-authz URI. It would be helpful in other circumstances, though. It probable requires a token_id that is separate from the token. -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
