You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
§2.5.3 Receive a Callback After Interaction: Editor's note:
The callback information could alternatively be combined with other methods like "redirect", essentially putting everything in the "callback" object into the field for the other objects. However, this would require each method to define its own set of rules about how callbacks can be used, and we would want them all to be consistent with each other with clear information about how the AS is supposed to respond to all of these.
So if the object is there, you do the redirect on completion, if the object isn't there (it's a boolean, like today), you don't redirect when you're done. Previous versions of this specification used this structure, but it was abandoned in favor of the current setup to allow for different combinations of user interaction methods at the same time while still keeping a consistent security model. OAuth 2's "grant_type" model has proved to be limiting in unanticipated ways since it requires an entirely new grant type to be invented any time there is a new combination of aspects, or it requires each grant type to have many of the same optionalities. Combining these fields back into one, in this way, would allow a client to declare that it expects a callback in response to one kind of interaction method but not others, and include multiple combinations at once. For example, if a client wants to allow a user to redirect to the AS and back on the same device, or to use a usercode on a secondary device without a callback, and the client wants to offer both modes simultaneously.
This could alternately be accomplished by allowing the client to "bundle" interaction parameters together, if desirable - for example, if "interact" were an array, the client would accept any combination represented by one object. This example binds the "callback" only to the first "redirect" method, and second (short) "redirect" and "user_code" method do not use a callback.
It's not clear what a response to such an array would be. Would the AS pick one of these bundles? Would it be allowed to respond to any or all of them? Could an AS use different URIs for each bundle? (This seems likely, at least.) Would there be a security problem if the AS used the same URI for both bundles, since one requires a front channel redirect and the other does not?
The text was updated successfully, but these errors were encountered:
§2.5.3 Receive a Callback After Interaction: Editor's note:
The callback information could alternatively be combined with other methods like "redirect", essentially putting everything in the "callback" object into the field for the other objects. However, this would require each method to define its own set of rules about how callbacks can be used, and we would want them all to be consistent with each other with clear information about how the AS is supposed to respond to all of these.
So if the object is there, you do the redirect on completion, if the object isn't there (it's a boolean, like today), you don't redirect when you're done. Previous versions of this specification used this structure, but it was abandoned in favor of the current setup to allow for different combinations of user interaction methods at the same time while still keeping a consistent security model. OAuth 2's "grant_type" model has proved to be limiting in unanticipated ways since it requires an entirely new grant type to be invented any time there is a new combination of aspects, or it requires each grant type to have many of the same optionalities. Combining these fields back into one, in this way, would allow a client to declare that it expects a callback in response to one kind of interaction method but not others, and include multiple combinations at once. For example, if a client wants to allow a user to redirect to the AS and back on the same device, or to use a usercode on a secondary device without a callback, and the client wants to offer both modes simultaneously.
This could alternately be accomplished by allowing the client to "bundle" interaction parameters together, if desirable - for example, if "interact" were an array, the client would accept any combination represented by one object. This example binds the "callback" only to the first "redirect" method, and second (short) "redirect" and "user_code" method do not use a callback.
It's not clear what a response to such an array would be. Would the AS pick one of these bundles? Would it be allowed to respond to any or all of them? Could an AS use different URIs for each bundle? (This seems likely, at least.) Would there be a security problem if the AS used the same URI for both bundles, since one requires a front channel redirect and the other does not?
The text was updated successfully, but these errors were encountered: