James, > 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.
Technically what I've proposed reverses the order of operations. Doing so allows for redirect decisions to be made by the provider on a case-by-case basis. As a result, I would submit that with the changes I'm suggesting, OAuth direct flows are much more flexible and could even be used in place of a Web Server, Native and User-Agent client profiles. >>> 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 As an OAuth 2 provider and consumer as well as someone who's preparing to build the DiSo interactions my proposal was based on, I would prefer a single flow that addresses what I feel will be a increasingly common set of requirements rather than combining two flows designed for two distinct purposes. -- darren bounds [email protected] _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
