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=40mail...@dmarc.ietf.org
<mailto:40mail...@dmarc.ietf..org>> wrote:
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)
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.
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.
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.
Another option is not redirecting and displaying the error message on
the AS, like when the client_id is unknown for instance.
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?
Also I don't get the example in
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>
:
https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Ftfp.example.org
<http://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?
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?
Maybe I've missed something?
Regards,
--
Tangui
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
