Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Neil Madden <[e-mail]>]

I believe just client_id would be sufficient for us, so I'd support a compromise position in which that is the only additional query parameter allowed.

-- Neil

> On 16 Jan 2020, at 13:40, John Bradley <[e-mail]> wrote:
> 
> I agree with the IESG reasoning that merging is problimatic.  Once we
> allow that given a unknown list of possible paramaters with diffrent
> security properties it would be quite difficult to specify safely.
> 
> Query paramaters can still be sent outside the JAR, but if they are in
> the OAuth registry the AS MUST ignore them.
> 
> Puting the iss in the JWE headder addresses the encryption issue without
> merging.
> 
> I understand that some existing servers have dependencys on getting the
> clientID as a query paramater.
> 
> Is that the only paramater that people have a issue with as oposed to a
> nice to have?
> 
> Would allowing the AS to not ignore the clientID as a query paramater as
> long as it matches the one inside the JAR, basicly the same as Connect
> request object but for just the one paramater make life easier for the
> servers?
> 
> I am not promising a change but gathering info before proposing something.
> 
> John B.
> 
> 
> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote:
>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote:
>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote:
>>>> Well, embedding a client_id claim in the JWE header in order to
>>>> achieve "request parameters outside the request object should not be
>>>> referred to" is like "putting the cart before the horse". Why do we
>>>> have to avoid using the traditional client_id request parameter so
>>>> stubbornly?
>>>> 
>>>> The last paragraph of Section 3.2.1
>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says
>>>> as follows.
>>>> 
>>>>    /A client MAY use the "client_id" request parameter to identify
>>>>    itself when sending requests to the token endpoint.  In the
>>>>    "authorization_code" "grant_type" request to the token endpoint,
>>>>    *an unauthenticated client MUST send its "client_id" to prevent
>>>>    itself from inadvertently accepting a code intended for a client
>>>>    with a different "client_id".*  This protects the client from
>>>>    substitution of the authentication code.  (It provides no
>>>>    additional security for the protected resource.)/
>>>> 
>>>> 
>>>> If the same reasoning applies, a client_id must always be sent with
>>>> request / request_uri because client authentication is not performed
>>>> at the authorization endpoint. In other words, */an unauthenticated
>>>> client (every client is unauthenticated at the authorization endpoint)
>>>> MUST send its "client_id" to prevent itself from inadvertently
>>>> accepting a request object for a client with a different "client_id"./*
>>>> 
>>> Identifying the client in JAR request_uri requests can be really useful
>>> so that an AS which requires request_uri registration to prevent DDoS
>>> attacks and other checks can do those without having to index all
>>> request_uris individually. I mentioned this before.
>>> 
>>> I really wonder what the reasoning of the IESG reviewers was to insist
>>> on no params outside the JAR JWT / request_uri.
>>> 
>>> I'm beginning to realise this step of the review process isn't
>>> particularly transparent to WG members.
>> Could you expand on that a bit more?  My understanding is that the IESG
>> ballot mail gets copied to the WG precisely so that there is transparency,
>> e.g., the thread starting at
>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
>> Which admittely is from almost three years ago, but that's the earliest
>> that I found that could be seen as the source of this behavior.
>> 
>> -Ben
>> 
>> P.S. some other discussion at
>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
>> so on.
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth