Thank you Justin for pointing this out. We had the exact same issue when
we implemented encrypted JAR - and ended up requiring the client_id. In
the absence of a client_id as top level parameter symmetric encryption
cannot be handled because there's no good way to find out the
client_client secret
That’s already kind of dealt with in JWE by having claims required for
decryption duplicated in the JWE header.
Odesláno z iPhonu
> 10. 10. 2019 v 19:01, Justin Richer :
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa
In a related note, JAR currently allows “client_id” to be optional for exactly
the reason of it being included in the request object. However, it falls into
the same issue where you can’t decrypt the request object without knowing which
client’s keys to use, and you can’t know which client you’r
Thanks for the response. My concern is that interpretation of the requirement
to “authenticate the client” could be interpreted in the FAPI draft’s sense,
which is to say validating the signature on the request object and not doing
anything else.
The problem comes from the fact that we’re effec
> If several of these are sent, they need to be consistent.
Given that client authentication precedes processing the rest of the
request, if several client authentication methods are provided (header +
secret or secret + assertion, etc) you generally reject the request, don't
you?
Then there's th
So in doing an implementation of this, I ran into this problem as well.
Specifically, we need to know which client we’re dealing with to fully validate
the encrypted request object as well as perform the authentication. Currently,
things are a little underspecified, and part of that comes from t
Hi Torsten,
>2.3.1.5. Request entity too large
>
> If the request size was beyond the upper bound that the authorization
> server allows, the authorization server shall return a "413 Request
> Entity Too Large" HTTP error response.
"413 Request Entity Too Large" should be changed to "413 P
To be clear, PAR is not the same as XYZ. Both are going to be inputs into the
conversation under txauth, and there are similarities, but they shouldn’t be
conflated.
In PAR, the result has to be a URI because that’s what JAR defines as the
input. With XYZ, you get returned two things: a transac
That's certainly an option that could be considered. Trying to reuse some
of JAR with request_uri makes a certain amount of sense. But maybe it's
more baggage than it's worth.
On Mon, Sep 30, 2019, 9:59 AM Torsten Lodderstedt
wrote:
> What if PAR would use another parameter? It could even return
I think you did call it an API in the first place? :)
endpoint is fine too though
I believe Aaron's main point was that calling this REST is a bit of a
stretch
On Mon, Sep 30, 2019 at 9:57 AM Torsten Lodderstedt
wrote:
> I wouldn't call it an API. What about just calling it an "HTTP endpoint"?
What if PAR would use another parameter? It could even return the actual
authorization URL.
> On 30. Sep 2019, at 08:45, Brian Campbell
> wrote:
>
>
>
> On Thu, Sep 26, 2019 at 10:50 AM Justin Richer wrote:
>> If, for whatever reason, it is required that this value is
>> actually a URI, is
I wouldn't call it an API. What about just calling it an "HTTP endpoint"?
> On 30. Sep 2019, at 07:52, Brian Campbell wrote:
>
>
>
> On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki wrote:
> > The pushed authorization request endpoint shall be a RESTful API
>
> I would drop the term RESTful and
On Thu, Sep 26, 2019 at 10:50 AM Justin Richer wrote:
> If, for whatever reason, it is required that this value is
> actually a URI, is there some expected namespace to use other than
> "example"? I worry that if all the examples in the spec are just
> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" t
I can understand the request URI being a URI that the client is providing
the AS, but why would the client's request URI be at the AS?
As Justin has explained it in the past, the AS is returning a handle to the
transaction. The only party that understands that handle as far as I know
is the AS. It
So although for this spec, request_uri is just an opaque string, it is
defined more generally in
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
* Absolute URI from which the Request Object (Section 2.1) can be obtained*
And in section 5.2 as:
> *The "request_uri" val
If I understand the proposal correctly, the request URI is opaque to the
client. Correct?
If so, why not just treat it as an opaque string?
If I were implementing the protocol, I would have the blob be a signed
token so that I could verify the integrity before making a database call.
It much easi
Yes, the request object is JWT-based, but the request URI is not. In other
words, you can post a JWT but what you get back is a URI, not the JWT itself.
The request URI was always meant to be a reference, and originally it was
explicitly a reference to a signed request object.
— Justin
On Sep
> The URI is intended to be a reference not a value. If the client could send a
> JWT it would just send a request object instead of a request URI in the first
> place. So the intent is that it’s random, and maybe we should just say that
> explicitly.
I thought this language was explicitly to a
Aaron, some comments inline.
— Justin
On Sep 26, 2019, at 8:30 AM, Aaron Parecki
mailto:aa...@parecki.com>> wrote:
Hi Torsten,
I'm very glad to see this draft, I think it's definitely needed in
this space. Here are some of my thoughts on the draft.
"request_uri": "urn:example:bwc4JK-ESC0w8acc
I find this to be an implementation detail, an optimization. As a matter of
fact depending on the Request Object flavor the AS implements a second round of
validation may be required.
Odesláno z iPhonu
> 23. 9. 2019 v 20:46, Janak Amarasena :
>
___
> Am 23.09.2019 um 20:46 schrieb Janak Amarasena :
>
>
> Hi,
>
>> Why do you think so?
>
> This is because I feel that validating the authorization request is part of
> the authorization process and doing the validation is the responsibility of
> the authorization endpoint.
>
>
>> I w
Hi,
Why do you think so?
This is because I feel that validating the authorization request is part of
the authorization process and doing the validation is the responsibility of
the authorization endpoint.
I would assume the same core service is used to check the payload, so no
> code duplicati
Hi Janak,
thanks for your feedback to PAR as well.
> On 22. Sep 2019, at 21:51, Janak Amarasena wrote:
>
> Hi,
>
> Since the /as/par endpoint is intended to be used to store the actual
> authorization request I feel that validating the authorization request as
> mentioned in point 2 section
23 matches
Mail list logo
