False info in the introduction

[Nat Sakimura]

Currently, it says:

However, the request URI mechanisms also has some downsides. The client needs to maintain and expose request objects. This might look easy on first sight, but the client needs to be able to handle inbound requests from the authorization server and, potentially, store a large number of objects in its database including the need to properly clean them up.

It also means the availability and latency of the authorization process at the authorization server depends on the availability and latency of the client’s backend.

Moreover, in order to dereference the request_uri parameter the authorization has to make outbound HTTP requests, which brings with it all the potential problems of server-side request forgery.

They are all false. The request object can be at the Authorization Server or at the Client or at a Third Party.

In addition, Push Request Object pattern is useful not only in the case of pushing it to AS but also a Third Party.

[Brian Campbell]

Yes, the request object **can** be at the Authorization Server or at the Client or even at a Third Party. But there’s not currently a standardized interoperable way to get the request object hosted anywhere. And without that, it really does fall on the client. This ‘Push Request Object' work is an attempt at standardizing an interoperable way for a client to push a request object to an AS.

[Torsten Lodderstedt]

text proposal to fix Issue #258

→ <<cset fdb28fc9fb62>>

[Torsten Lodderstedt]

text proposal to resolve Issue #258

→ <<cset fbaca58ae8ab>>

[Torsten Lodderstedt]

unintentionally closed by Bitbucket

[Torsten Lodderstedt]

PR #138

[Torsten Lodderstedt]

fixed