Subject: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

From: Танги Ле Пенс <[email-masked]>
Date: Thu, 25 Jul 2019 20:57:15 +0300

In https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it 
is stated that an error is to be returned when the object request is 
invalid. These errors are "invalid_request_uri" and 
"invalid_request_object".

However, to which redirect URI redirect in the following cases:
* the request object is invalid (eg. invalid signature), should we still 
use client_id/redirect_uri of the invalid request object?
* the request URI could not be reached
* the request object is encrypted and cannot be decrypted (bad key)

Would it be acceptable to use the "client_id" and "redirect_uri" request 
query parameters in such a case? Although it contradicts the current 
specification which states that they shall not be used, and it would 
defeat confidentiality when using encryption.

Another option is not redirecting and displaying the error message on 
the AS, like when the client_id is unknown for instance.

Also I don't get the example in 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2 :

      https://server.example.com/authorize?
        response_type=code%20id_token
        &client_id=s6BhdRkqt3
        &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
        %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
        &state=af0ifjsldkj

in regards to the following statement in 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :

    The client MAY send the parameters included in the request object
    duplicated in the query parameters as well for the backward
    compatibility etc.  However, the authorization server supporting this
    specification MUST only use the parameters included in the request
    object.

My understanding is that "response_type", "client_id" and "state" will 
be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add 
them to the example?

Maybe I've missed something?

Regards,

-- 
Tangui

---

From: Filip Skokan <[email-masked]>
Date: Thu, 25 Jul 2019 20:14:25 +0200

See my reply inline.

S pozdravem,
*Filip Skokan*

> * the request object is encrypted and cannot be decrypted (bad key)

FS: if the client_id & redirect_uri combination is valid (the uri is valid
for that client) - yes, its fine to use those (dtto state). this applies to
all three

> defeat confidentiality when using encryption.

FS: how would it defeat confidentiality?

> the AS, like when the client_id is unknown for instance.

FS: also an acceptable outcome, one with no caveats

> be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to add

FS: they will only be ignored IF they are also part of the request object
so i believe its fine to have them part of this example.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Танги Ле Пенс <[email-masked]>
Date: Thu, 25 Jul 2019 21:48:04 +0300

Filip, thank you for your reply. Additional remarks inline.

On 25.07.2019 21:14, Filip Skokan wrote:
> See my reply inline.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс 
> <tangui.lepense=[email-masked] 
> <mailto:[email-masked]..org>> wrote:
>
>     In
>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
> FS: if the client_id & redirect_uri combination is valid (the uri is 
> valid for that client) - yes, its fine to use those (dtto state). this 
> applies to all three

It doesn't apply to an encrypted object that cannot be decrypted.

> FS: how would it defeat confidentiality?
If you use a JWE in the first place, it's so that the parameters cannot 
be read on the wire.
> FS: also an acceptable outcome, one with no caveats

Except degraded UI for the end user, if we assume that an error on the 
client side is easier to manage that a cryptic error on the AS with no 
link back to the client. Also, the client could have a retry strategy 
(it might just be that the request object at the request object URI is 
expired, due to network latency, etc.).

So if my understanding is correct, it's up to the implementer to make a 
decision on this point? Couldn't it lead to incompatibility, divergent 
implementations?

>     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2
>     <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2>
>     :
>
>             &request_uri=https%3A%2F%2Ftfp.example.org
>     <http://2Ftfp.example.org>%2Frequest.jwt
> FS: they will only be ignored IF they are also part of the request 
> object so i believe its fine to have them part of this example.

It's seems ambiguous to me when reading the specification. 
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4 states 
that:

A Request Object (Section 2.1  <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is used to provide authorization
    request parameters for an OAuth 2.0 authorization request.  It MUST
    contains all the OAuth 2.0 [RFC6749  <https://tools.ietf.org/html/rfc6749>] authorization request parameters
    including extension parameters.

So there'd be no such thing as "client_id" and "redirect_uri" as query 
parameters, and other parameters members of the request object in my 
interpretation.

In OpenID Connect you can indeed have both, the request object's 
parameters having precedence over query parameters 
(https://openid.net/specs/openid-connect-core-1_0.html#RequestObject):

When the request parameter is used, the OpenID Connect request parameter 
values contained in the JWT supersede those passed using the OAuth 2.0 
request syntax. However, parameters MAY also be passed using the OAuth 
2.0 request syntax even when a Request Object is used; this would 
typically be done to enable a cached, pre-signed (and possibly 
pre-encrypted) Request Object value to be used containing the fixed 
request parameters, while parameters that can vary with each request, 
such as state and nonce, are passed as OAuth 2.0 parameters.

What do you think?

>     [email-masked] <mailto:[email-masked]>

---

From: Filip Skokan <[email-masked]>
Date: Fri, 26 Jul 2019 12:58:52 +0200

John, Nat,

Tangui raises a good point I have missed,

draft 14 of jwsreq (JAR) introduced this language

> compatibility etc.
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *

Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter.  The Authorization

> compatibility etc.
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *

Nat, John, everyone - *does this mean a JAR compliant AS ignores everything
outside of the request object while OIDC Request Object one merges the two
with the ones in the request object being used over ones that are not?* The
OIDC language also includes sections which make sure that some required
arguments are still passed outside of the request with the same value to
make sure the request is "valid" OAuth 2.0 request, something which an
example in the JAR spec does not do. Not having this language means that
existing authorization request pipelines can't simply be extended with e.g.
a middleware, they need to branch their codepaths.

Thank you for clarifying this in advance. I think if either the behaviour
is the same as in OIDC or different this should be called out in the
language to avoid confusion, especially since this already exists in OIDC
and likely isn't going to be read in isolation since its even called out to
be already in place in OIDC.

S pozdravem,
*Filip Skokan*

On Thu, 25 Jul 2019 at 20:48, Танги Ле Пенс <[email-masked]> wrote:

> >     <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2>
> >     :
> >
> A Request Object (Section 2.1  <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is
> used to provide authorization
>     contains all the OAuth 2.0 [RFC6749  <
> https://tools.ietf.org/html/rfc6749>] authorization request parameters