Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Sep 2019 13:02:01 +0200

Hi all, 

I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat Sakimura and I wrote. 

https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00

It proposes a new endpoint, called "pushed authorization request endpoint”, that allows the client to push the Authorization Request payload with the AS on a backchannel connection instead of a front channel interaction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization requests to refer to the pushed request data. 

We believe this simple mechanism will significantly increase OAuth security and robustness since any application can use it by just sending the parameters in the same encoding as used at the authorisation endpoint over a HTTPS-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used to push signed and encrypted request objects to the AS, i.e. it provides an interoperable way to use request objects managed at the AS for use cases requiring an even higher security level.

We look forward to getting your feedback. 

kind regards,
Torsten. 

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
> Date: 21. September 2019 at 12:47:28 CEST
> To: "Nat Sakimura" <[email-masked]>, "Brian Campbell" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>, "Dave Tonge" <[email-masked]>, "Filip Skokan" <[email-masked]>
> 
> 
> A new version of I-D, draft-lodderstedt-oauth-par-00.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name:		draft-lodderstedt-oauth-par
> Revision:	00
> Title:		OAuth 2.0 Pushed Authorization Requests
> Document date:	2019-09-21
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
> 
> 
> Abstract:
>   This document defines the pushed authorization request endpoint,
>   which allows clients to push the payload of an OAuth 2.0
>   authorization request to the authorization server via a direct
>   request and provides them with a request URI that is used as
>   reference to the data in a subsequent authorization request.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Janak Amarasena <[email-masked]>
Date: Mon, 23 Sep 2019 01:21:58 +0530

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 2.1(Request) should not be a
responsibility of the /as/par endpoint and that it should not validate
the authorization request. Also, the majority case could be the endpoint
receiving valid requests and the validation process will be duplicated at
the authorization endpoint.

Also since section 2.2 (Successful Response) states;

The "request URI" MUST be bound to the "client_id" of the client that
posted the authorization request.

Wouldn't it be good to enforce the use of the clientId in section 4
(Authorization Request) when the authorization request is made with the "
request_uri" parameter?

GET /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2*&client_id=s6BhdRkqt3*
HTTP/1.1

Best Regards,
Janak Amarasena

On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <[email-masked]>
wrote:

> It proposes a new endpoint, called "pushed authorization request
> endpoint”, that allows the client to push the Authorization Request payload
> with the AS on a backchannel connection instead of a front channel
> interaction. The AS provides the client with a request URI (according to
> draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization
> requests to refer to the pushed request data.
>
> We believe this simple mechanism will significantly increase
> OAuth security and robustness since any application can use it by just
> sending the parameters in the same encoding as used
> at the authorisation endpoint over a HTTPS-protected and
> (for confidential clients) mutually authenticated connection to the AS. It
> can also be used to push signed and encrypted request objects to the AS,
> i.e. it provides an interoperable way to use request objects managed at the
> AS for use cases requiring an even higher security level.
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-lodderstedt-oauth-par-00.txt*
> *Date: *21. September 2019 at 12:47:28 CEST
> *To: *"Nat Sakimura" <[email-masked]>, "Brian Campbell" <
> [email-masked]>, "Torsten Lodderstedt" <
> [email-masked]>, "Dave Tonge" <[email-masked]>, "Filip Skokan" <
> [email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
>
>
> Abstract:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 23 Sep 2019 20:17:02 +0200

Hi Janak,

thanks for your feedback to PAR as well. 

> On 22. Sep 2019, at 21:51, Janak Amarasena <[email-masked]> 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 2.1(Request) should not be a responsibility of the /as/par endpoint and that it should not validate the authorization request.

Why do you think so?

Validating the request data at the pushed authorisation request endpoint has the advantage that the AS can refuse the process early. It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation).  

> Also, the majority case could be the endpoint receiving valid requests and the validation process will be duplicated at the authorization endpoint.

I would assume the same core service is used to check the payload, so no code duplication required.

> The "request URI" MUST be bound to the "client_id" of the client that posted the authorization request.
> Wouldn't it be good to enforce the use of the clientId in section 4 (Authorization Request) when the authorization request is made with the "request_uri" parameter?
> GET /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=s6BhdRkqt3 HTTP/1.1

There is no need for an additional client id since the request URI is already bound to the client_id passed to and, in case of a confidential client, authenticated in the pushed authorization request.

best regards,
Torsten.
 
> 
> 
> Best Regards,
> Janak Amarasena
> 
> On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <[email-masked]> wrote:
> Hi all, 
>

---

From: Janak Amarasena <[email-masked]>
Date: Tue, 24 Sep 2019 00:15:31 +0530

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 duplication required.

At the time what I meant was that the authorization request validation will
be done twice. Once at the /as/par endpoint and again at the authorization
endpoint.

It also means the authorisation endpoint of the AS can safely assume all
> request URIs sent in Authorization Request that are minted by the same AS
> (which is detected based on its structure), are pre-checked and can be
> trusted (regarding the input validation).

I see, so if the authorization request is validated at the /as/par endpoint
the validation can be omitted at the authorization endpoint if the request
contains a "request_uri" (given that it belongs to the AS). If this is the
case I think it might be good to mention this in the spec with something
like "The authorization server MAY decided to omit the validation of the
authorization request if the uri sent in the request_uri parameter belongs
to the authorization server." WDYT?

Best Regards,
Janak Amarasena

On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt <
[email-masked]> wrote:

> > Since the /as/par endpoint is intended to be used to store the actual
> mentioned in point 2 section 2.1(Request) should not be a responsibility of
> the /as/par endpoint and that it should not validate the authorization
> request.
>
> Why do you think so?
>
> Validating the request data at the pushed authorisation request endpoint
> has the advantage that the AS can refuse the process early. It also means
> the authorisation endpoint of the AS can safely assume all request URIs
> sent in Authorization Request that are minted by the same AS (which is
> detected based on its structure), are pre-checked and can be trusted
> (regarding the input validation).
>
> > Also, the majority case could be the endpoint receiving valid requests
> and the validation process will be duplicated at the authorization endpoint.
>
> (Authorization Request) when the authorization request is made with the
> "request_uri" parameter?
> > GET
> /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=s6BhdRkqt3
> HTTP/1.1
>
> There is no need for an additional client id since the request URI is
> already bound to the client_id passed to and, in case of a confidential
> client, authenticated in the pushed authorization request.
>
> best regards,
> Torsten.
>
> >
> >
> > Best Regards,
> > Janak Amarasena
> >
> > We believe this simple mechanism will significantly increase OAuth
> security and robustness since any application can use it by just sending
> the parameters in the same encoding as used at the authorisation endpoint
> over a HTTPS-protected and (for confidential clients) mutually
> authenticated connection to the AS. It can also be used to push signed and
> encrypted request objects to the AS, i.e. it provides an interoperable way
> to use request objects managed at the AS for use cases requiring an even
> higher security level.
> >
> >> To: "Nat Sakimura" <[email-masked]>, "Brian Campbell" <

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 23 Sep 2019 21:40:32 +0200

> Am 23.09.2019 um 20:46 schrieb Janak Amarasena <[email-masked]>:
> 
> 
> 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.
>  
> 
> At the time what I meant was that the authorization request validation will be done twice. Once at the /as/par endpoint and again at the authorization endpoint. 
> 
> 
>> It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation).   
> 
> I see, so if the authorization request is validated at the /as/par endpoint the validation can be omitted at the authorization endpoint if the request contains a "request_uri" (given that it belongs to the AS). If this is the case I think it might be good to mention this in the spec with something like "The authorization server MAY decided to omit the validation of the authorization request if the uri sent in the request_uri parameter belongs to the authorization server." WDYT?

WFM

>  
> 
> Best Regards,
> Janak Amarasena
> 
>> On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi Janak,
>>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 26 Sep 2019 17:30:15 +0200

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-ESC0w8acc191e-Y1LTC2"

Is it acceptable for the AS to return just an opaque string, rather
than something prefixed with "uri:*"? I don't think anyone would be
confused about copypasting the exact string from the "request_uri"
response into the "request_uri" parameter even if it didn't start with
"urn:". 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" then developers will end up
using the text "example" because they don't understand why it's there,
and then it serves no purpose really.

> The pushed authorization request endpoint shall be a RESTful API

I would drop the term RESTful and just say "HTTP API", as this
description is arguably RESTful at best.

> Depending on client type and authentication method, the request might
>   also include the "client_id" parameter.

I assume this is hinting at the difference between public clients
sending only the "client_id" parameter and confidential clients
sending only the HTTP Basic Authorization header which includes both
the client ID and secret? It would probably be helpful to call out
these two common examples if I am understanding this correctly,
otherwise it seems pretty vague.

> The "request_uri" value MUST be generated using a cryptographically
>   strong pseudorandom algorithm

I assume this includes the use of a random number inside of a JWT, in
case the AS wants to use JWTs as the "request_uri" parameter"? If so,
it's probably worth spelling that out as it kind of reads like it has
to be literally a random string at first glance.

That's all for now, thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Sep 2019 16:49:22 +0000

Aaron, some comments inline.

— Justin

On Sep 26, 2019, at 8:30 AM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

Hi Torsten,

and then it serves no purpose really.’

This field must be a URI, as per JAR:

   request_uri  The absolute URI as defined by RFC3986<https://tools.ietf.org/html/rfc3986> [RFC3986<https://tools.ietf.org/html/rfc3986>] that
      points to the Request Object (Section 2.1<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) that holds
      authorization request parameters stated in section 4<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4> of OAuth 2.0
      [RFC6749<https://tools.ietf.org/html/rfc6749>].

Somewhat awkwardly, the JAR spec currently states that the AS has to do an HTTP GET on the request URI, so that will need to be fixed in JAR before it goes forward. I don’t think that was always the case though, and I’m not sure how that changed.

As for the namespace, “example” is ok for an example URN. The problem with URNs is that nobody really understands how to do domain-safe fully compliant URNs. So perhaps we should instead use “urn:fdc:example.com<http://example.com>:….” Instead (as per https://tools.ietf.org/html/rfc4198).

Not quite, those differences are for the token endpoint, and this is capturing things from the authorization endpoint. I don’t quite understand the differentiation listed here either, though.

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.

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk

Hi all,

kind regards,
Torsten.

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 26 Sep 2019 19:03:40 +0200

> 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,…

I thought this language was explicitly to allow the use of structured
values for the request_uri? From the introduction:

> but it also allows clients requiring an even
> higher security level, especially cryptographically confirmed non-
> repudiation, to explicitly adopt JWT-based request objects.

----
Aaron Parecki
aaronparecki.com

On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <[email-masked]> wrote:
> On Sep 26, 2019, at 8:30 AM, Aaron Parecki <[email-masked]> wrote:
>
> Hi Torsten,
>
>    request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
>       points to the Request Object (Section 2.1) that holds
>       authorization request parameters stated in section 4 of OAuth 2.0
>       [RFC6749].
>
> As for the namespace, “example” is ok for an example URN. The problem with URNs is that nobody really understands how to do domain-safe fully compliant URNs. So perhaps we should instead use “urn:fdc:example.com:….” Instead (as per https://tools.ietf.org/html/rfc4198).
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Sep 2019 21:23:39 +0000

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 26, 2019, at 10:03 AM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

----
Aaron Parecki

— Justin

Hi Torsten,

----
Aaron Parecki
aaronparecki.com
@aaronpk

Hi all,

kind regards,
Torsten.

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Sep 2019 10:22:02 -0700

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 easier to throw compute at a DDOS attack to verify a signature,
than DB capacity.

ᐧ

On Thu, Sep 26, 2019 at 2:24 PM Justin Richer <[email-masked]> wrote:

> 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 26, 2019, at 10:03 AM, Aaron Parecki <[email-masked]> wrote:
>
> 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.
>
>
> Somewhat awkwardly, the JAR spec currently states that the AS has to do an
> HTTP GET on the request URI, so that will need to be fixed in JAR before it
> goes forward. I don’t think that was always the case though, and I’m not
> sure how that changed.
>
> As for the namespace, “example” is ok for an example URN. The problem with
> URNs is that nobody really understands how to do domain-safe fully
> compliant URNs. So perhaps we should instead use “urn:fdc:example.com:….”
> Instead (as per https://tools.ietf.org/html/rfc4198).
>
>
> Not quite, those differences are for the token endpoint, and this is
> capturing things from the authorization endpoint. I don’t quite understand
> the differentiation listed here either, though.
>
>
> 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.
>
>

---

From: Dave Tonge <[email-masked]>
Date: Mon, 30 Sep 2019 11:52:56 +0200

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" value MUST be either URN as defined in*
> *   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230*
> *   [RFC7230] .  The "request_uri" value MUST be reachable by the**
>  Authorization Server.*

So this is why in the spec we have example of a URN and we have an ongoing
discussion as to whether we should have a standard urn namespace that we
recommend implementers use.

In the interest of keeping the specs in sync I think it makes sense to keep
it a URN for this spec, but with more of an explanation as to why?

Dave

On Fri, 27 Sep 2019 at 19:22, Dick Hardt <[email-masked]> wrote:

>> 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
>> The URI is intended to be a reference not a value.. If the client could
>> Somewhat awkwardly, the JAR spec currently states that the AS has to do
>> an HTTP GET on the request URI, so that will need to be fixed in JAR before
>> it goes forward. I don’t think that was always the case though, and I’m not
>> sure how that changed.
>>
>> As for the namespace, “example” is ok for an example URN. The problem
>> with URNs is that nobody really understands how to do domain-safe fully
>> <https://tools.ietf..org/html/draft-lodderstedt-oauth-par-00>
>> Htmlized:

--

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Sep 2019 08:52:02 -0600

> description is arguably RESTful at best.

+1

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Sep 2019 09:21:32 -0600

> otherwise it seems pretty vague.

What this is trying to convey is that because client authentication at this
Pushed Authorization Request Endpoint happens the same way as at the token
endpoint (and other endpoints called directly by the client) the client_id
parameter will sometimes be present but not necessarily as some types of
client auth use the client_id parameter (none, client_secret_post,
tls_client_auth, self_signed_tls_client_auth) and some don't
(client_secret_basic, client_secret_jwt, private_key_jwt).

Although the draft does later say "The AS MUST validate the request the
same way as at the authorization endpoint" which I think could reasonably
be interpreted as requiring client_id.  e.g.,
https://tools.ietf.org/html/rfc6749?#section-4.1.1 &
https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_id be
a required parameter at the PAR endpoint.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Sep 2019 08:33:25 -0700

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 is meaningless to the client. Perhaps I am missing something
else?
ᐧ

On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <[email-masked]>
wrote:

> In the interest of keeping the specs in sync I think it makes sense to
> keep it a URN for this spec, but with more of an explanation as to why?
>
> Dave
>
>>> [email-masked]>, "Dave Tonge" <[email-masked]>, "Filip Skokan"
>>> <[email-masked]>
>>>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Sep 2019 09:45:40 -0600

On Thu, Sep 26, 2019 at 10:50 AM Justin Richer <[email-masked]> wrote:

>  If, for whatever reason, it is required that this value is
>    request_uri  The absolute URI as defined by RFC3986 <https://tools.ietf.org/html/rfc3986> [RFC3986 <https://tools.ietf.org/html/rfc3986>] that
>       points to the Request Object (Section 2.1 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) that holds
>       authorization request parameters stated in section 4 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4> of OAuth 2.0
>       [RFC6749 <https://tools.ietf.org/html/rfc6749>].
>

JAR does have a somewhat awkward allowance for not doing a GET in
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying
an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the
referenced Request Object, unless it is stored in a way so that it can
retrieve it through other mechanism securely."

So I'm guessing maybe nothing actually changed but it's just hard to find
in the document.

> Instead (as per https://tools.ietf.org/html/rfc4198).

Something else to consider additionally or alternately is that the document
could provide some suggestions/guidance or even requirements on the
structure of the URN for this self referential case. It could, for example,
use the RFC6755 subnamespace and registry and be of the form
urn:ietf:params:oauth:request_uri:<handle> or
urn:ietf:params:oauth:request_uri;<handle> or
urn:ietf:params:oauth:request_uri?value=<handle> or
urn:ietf:params:oauth:request_uri#<handle> or however the proper way to do
that would be.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 30 Sep 2019 08:57:12 -0700

I wouldn't call it an API. What about just calling it an "HTTP endpoint"?

> On 30. Sep 2019, at 07:52, Brian Campbell <[email-masked]> wrote:
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 30 Sep 2019 08:59:39 -0700

What if PAR would use another parameter? It could even return the actual authorization URL.

> On 30. Sep 2019, at 08:45, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 
> 
>       points to the Request Object (
> Section 2.1
> ) that holds
>       authorization request parameters stated in 
> section 4
>  of OAuth 2.0
>       [
> RFC6749
> ].
> 
> JAR does have a somewhat awkward allowance for not doing a GET in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the referenced Request Object, unless it is stored in a way so that it can retrieve it through other mechanism securely." 
> 
> So I'm guessing maybe nothing actually changed but it's just hard to find in the document.
> 
>  
> Something else to consider additionally or alternately is that the document could provide some suggestions/guidance or even requirements on the structure of the URN for this self referential case. It could, for example, use the RFC6755 subnamespace and registry and be of the form urn:ietf:params:oauth:request_uri:<handle> or urn:ietf:params:oauth:request_uri;<handle> or urn:ietf:params:oauth:request_uri?value=<handle> or urn:ietf:params:oauth:request_uri#<handle> or however the proper way to do that would be.
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Sep 2019 10:00:14 -0600

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 <[email-masked]>
wrote:

> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Sep 2019 10:14:45 -0600

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 <[email-masked]>
wrote:

> > On 30. Sep 2019, at 08:45, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >
> >
> >
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3
> saying an AS "MUST send an HTTP "GET" request to the request_uri to
> retrieve the referenced Request Object, unless it is stored in a way so
> that it can retrieve it through other mechanism securely."
> >
> > Something else to consider additionally or alternately is that the
> document could provide some suggestions/guidance or even requirements on
> the structure of the URN for this self referential case. It could, for
> example, use the RFC6755 subnamespace and registry and be of the form
> review, use, distribution or disclosure by others is strictly prohibited..
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > [email-masked]