I’m increasingly thinking that we should push back on the IESG and go back to
the semantics that the working group approved. We can use the client_id
example with an encrypted request object to motivate the (Connect-compatible)
syntax and semantics.
-- Mike
From: Vladimir Dzhuvinov <vladi...@connect2id.com>
Sent: Wednesday, January 15, 2020 1:03 PM
To: Takahiko Kawasaki <t...@authlete.com>
Cc: John Bradley <ve7...@ve7jtb.com>; Mike Jones <michael.jo...@microsoft.com>;
IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR)
vs OIDC request object
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.
Vladimir
Best Regards,
Taka
On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov
<vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote:
John, thanks, much appreciated!
On 11/01/2020 21:36, John Bradley wrote:
Yes JAR is not prohibiting paramater replication in the header.
I will see if i can add something in final edits to call that out.
John B.
On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
Thanks Mike for the rfc7519
section-5.3<https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this
parameter replication be used for client_id or the client_id ass "iss" even
though it isn't explicitly mentioned in the JAR spec?
On 11/01/2020 02:58, John Bradley wrote:
Right we just don't say to put the iss there in OIDC if it's symetricly
encrypted.
OIDC doesn't have the symmetric key selection issue, I suppose that why the
possibility to replicate params to the JWE header isn't mentioned at all. OIDC
requires the top-level query params to represent a valid OAuth 2.0 request, and
there client_id is required. If the client_id is present the client
registration together with any present client_secret can be retrieved.
I reread the JAR spec, this is the only place that mentions handling of
symmetric JWE.
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
(b) Verifying that the symmetric key for the JWE encryption is the
correct one if the JWE is using symmetric encryption.
Vladimir
On Fri, Jan 10, 2020, 9:41 PM Mike Jones
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote:
The technique of replicating JWT claims that need to be publicly visible in an
encrypted JWT in the header is defined at
https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks to Dick Hardt for
bringing this need to my attention as we were finishing the JWT spec.)
-- Mike
From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
Of John Bradley
Sent: Friday, January 10, 2020 2:15 PM
To: Vladimir Dzhuvinov <vladi...@connect2id.com<mailto:vladi...@connect2id.com>>
Cc: IETF oauth WG <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs
OIDC request object
The intent was to do that, but specs change once the OAuth WG and IESG get
there hands on them.
Being backwards compatible with OIDC is not a compelling argument to the IESG.
We were mostly thinking of asymmetric encryption.
Specifying puting the issuer and or the audience in the headder has come up in
the past but probably is not documented.
John B
On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
<vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote:
Yes, putting the client_id into the JWE header is a way around the need
to have the client_id outside the JWE as top-level authZ request parameter.
Unfortunately this work around isn't mentioned anywhere, I just checked
the most recent draft-ietf-oauth-jwsreq-20.
Our DDoS attack mitigation (for OIDC request_uri) also relies on the
presence of client_id as top-level parameter, together with requiring
RPs to register their request_uri's (so that we don't need to build and
store an index of all request_uri's). I just had a look at "DDoS Attack
on the Authorization Server" and also realised the request_uri
registration isn't explicitly mentioned as attack prevention ("the
server should (a) check that the value of "request_uri" parameter does
not point to an unexpected location").
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0>
To be honest, I feel quite bad about the situation with JAR we are in
now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other
OIDC bits that later became general purpose OAuth 2.0 specs.
I find it unfortunate I didn't notice this when I was reviewing the spec
in the past.
Vladimir
On 10/01/2020 22:39, Filip Skokan wrote:
> Vladimir,
>
> For that very case the payload claims may be repeated in the JWE protected
> header. An implementation wanting to handle this may look for iss/client_id
> there.
>
> Odesláno z iPhonu
>
>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>> <vladi...@connect2id.com<mailto:vladi...@connect2id.com>>:
>>
>> I just realised there is one class of JARs where it's practially
>> impossible to process the request if merge isn't supported:
>>
>> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
>> for that and specs a method for deriving the shared key from the
>> client_secret:
>>
>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0>
>>
>> If the JAR is encrypted with the client_secret, and there is no
>> top-level client_id parameter, there's no good way for the OP to find
>> out which client_secret to get to try to decrypt the JWE. Unless the OP
>> keeps an index of all issued client_secret's.
>>
>>
>> OP servers which require request_uri registration
>> (require_request_uri_registration=true) and don't want to index all
>> registered request_uri's, also have no good way to process a request_uri
>> if the client_id isn't present as top-level parameter.
>>
>>
>> Vladimir
>>
>>
>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>
>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>>>>> <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>:
>>>> I think Torsten is speculating that is not a feature people use.
>>> I’m still trying to understand the use case for merging signed and unsigned
>>> parameters. Nat once explained a use case, where a client uses parameters
>>> signed by a 3rd party (some „certification authority“) in combination with
>>> transaction-specific parameters. Is this being done in the wild?
>>>
>>> PS: PAR would work with both modes.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
