Re: [OAUTH-WG] PAR and client metadata

[Torsten Lodderstedt]

wfm - thanks.


Brian Campbell  schrieb am Mo.
27. Apr. 2020 um 21:06:

> require_pushed_authorization_requests works for me and is maybe/arguably a
> bit better by being more consistent with other names.
>
> On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan  wrote:
>
>> Alternatively, `require_pushed_authorization_requests`. Since we already
>> have the `*require_*request_uri_registration` server and `*require_*
>> auth_time` client metadata properties.
>>
>> WDYT?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org> wrote:
>>
> Hi all,
>>>
>>> I think this topic has several aspects:
>>> - Is the client required to use PAR only? Doesn’t this also mean it is
>>> required to use request_uri only?
>>> - Is there a need to separate those to questions or shall we treat this
>>> as the same?
>>> - Who decides whether PAR and request_uri are required? The client for
>>> its instances or the AS for the whole deployment?
>>>
>>> I’m in favour of coupling enforced PAR use with enforced request_uri use
>>> even though it means the setting is useful with PAR only, not with all
>>> JAR-based clients.
>>> I think both the client as well as the AS should be able to declare
>>> forced PAR. If the AS is able to basically turn of traditional
>>> authorization requests, it can consequently utilize the changed protocol
>>> properties in terms of security and robustness in its deployment. This
>>> means, for example, the AS no longer needs to require pre-registered
>>> redirect URIs for confidential clients. It also means, the AS can use
>>> voluminous claims/authorization details objects without worrying about
>>> fragile long request URLs.
>>>
>>> So here is my proposal:
>>>
>>> 1) Add server metadata parameter “pushed_authorization_requests_only” of
>>> type boolean - It requires any client to use PAR, the AS will refuse to
>>> process any authorization request containing parameters other than
>>> request_uri + client_id (as required by
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
>>> request parameters need to be passed via PAR.
>>> 2) Add client registration parameter
>>> “pushed_authorization_requests_only” - It requires this client to use PAR
>>> only. The AS won’t accept any authorization request containing more than
>>> request_uri + client_id for that particular client.
>>>
>>> What are your thoughts?
>>>
>>> best regards,
>>> Torsten.
>>>
>>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
>>> wrote:
>>> >
>>> > In a off-list conversation Torsten floated the idea of letting
>>> confidential PAR-only clients register without a redirect_uris and having
>>> this "PAR only" parameter will enable that.
>>> >
>>> > A "PAR only" parameter will also prevent client developers from
>>> accidentally making plain authz requests (for clients that rely on PAR for
>>> the extra security).
>>> >
>>> > Vladimir
>>> >
>>> > On 16/04/2020 18:39, Brian Campbell wrote:
>>> >>
>>> >>
>>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle >> 40amazon@dmarc.ietf.org> wrote:
>>> >> As I think through this, I’m struggling to identify the threats this
>>> actually helps mitigate.
>>> >>
>>> >> A client metadata parameter implies that the value may be different
>>> for different clients, and that any given client won’t already know via
>>> other means whether or not it needs to use PAR. That means we’re only
>>> talking about dynamic clients since statically registered clients already
>>> have some proprietary out-of-band registration mechanism (e.g., a developer
>>> console).
>>> >>
>>> >> As I tried to articulate in the original email and Filip also
>>> mentioned in a different fork of this email thread, defining metadata can
>>> be beneficial even when it's not used dynamically at runtime. So we're not
>>> only talking about dynamic clients.
>>> >>
>>> >>
>>> >>
>>> >> A client metadata parameter also implies that the AS allows some
>>> clients to make non-PAR requests (otherwise it would be an AS metadata
>>> parameter).
>>> >>
>>> >> A per client setting seems necessary for existing ASs to roll out PAR
>>> support over time or just generally in support of diverse client
>>> capabilities and requirements.
>>> >>
>>> >>
>>> >> If that’s the case then presumably a malicious party could register
>>> their own client that doesn’t use PAR.
>>> >>
>>> >> So it seems to me that the only scenario that this parameter would
>>> protect against is a malicious party impersonating a dynamically registered
>>> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
>>> the attacker uses its own client.
>>> >>
>>> >> This client metadata parameter is meant to be something that would
>>> prevent a malicious actor from controlling the content of the authz request
>>> parameters, which could be done by crafting the link and tricking a user
>>> into following it. I mentioned mix-up as an example because the first
>>> variant

Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

require_pushed_authorization_requests works for me and is maybe/arguably a
bit better by being more consistent with other names.

On Mon, Apr 27, 2020 at 12:58 PM Filip Skokan  wrote:

> Alternatively, `require_pushed_authorization_requests`. Since we already
> have the `*require_*request_uri_registration` server and `*require_*
> auth_time` client metadata properties.
>
> WDYT?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>> I think this topic has several aspects:
>> - Is the client required to use PAR only? Doesn’t this also mean it is
>> required to use request_uri only?
>> - Is there a need to separate those to questions or shall we treat this
>> as the same?
>> - Who decides whether PAR and request_uri are required? The client for
>> its instances or the AS for the whole deployment?
>>
>> I’m in favour of coupling enforced PAR use with enforced request_uri use
>> even though it means the setting is useful with PAR only, not with all
>> JAR-based clients.
>> I think both the client as well as the AS should be able to declare
>> forced PAR. If the AS is able to basically turn of traditional
>> authorization requests, it can consequently utilize the changed protocol
>> properties in terms of security and robustness in its deployment. This
>> means, for example, the AS no longer needs to require pre-registered
>> redirect URIs for confidential clients. It also means, the AS can use
>> voluminous claims/authorization details objects without worrying about
>> fragile long request URLs.
>>
>> So here is my proposal:
>>
>> 1) Add server metadata parameter “pushed_authorization_requests_only” of
>> type boolean - It requires any client to use PAR, the AS will refuse to
>> process any authorization request containing parameters other than
>> request_uri + client_id (as required by
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
>> request parameters need to be passed via PAR.
>> 2) Add client registration parameter “pushed_authorization_requests_only”
>> - It requires this client to use PAR only. The AS won’t accept any
>> authorization request containing more than request_uri + client_id for that
>> particular client.
>>
>> What are your thoughts?
>>
>> best regards,
>> Torsten.
>>
>> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
>> wrote:
>> >
>> > In a off-list conversation Torsten floated the idea of letting
>> confidential PAR-only clients register without a redirect_uris and having
>> this "PAR only" parameter will enable that.
>> >
>> > A "PAR only" parameter will also prevent client developers from
>> accidentally making plain authz requests (for clients that rely on PAR for
>> the extra security).
>> >
>> > Vladimir
>> >
>> > On 16/04/2020 18:39, Brian Campbell wrote:
>> >>
>> >>
>> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle > 40amazon@dmarc.ietf.org> wrote:
>> >> As I think through this, I’m struggling to identify the threats this
>> actually helps mitigate.
>> >>
>> >> A client metadata parameter implies that the value may be different
>> for different clients, and that any given client won’t already know via
>> other means whether or not it needs to use PAR. That means we’re only
>> talking about dynamic clients since statically registered clients already
>> have some proprietary out-of-band registration mechanism (e.g., a developer
>> console).
>> >>
>> >> As I tried to articulate in the original email and Filip also
>> mentioned in a different fork of this email thread, defining metadata can
>> be beneficial even when it's not used dynamically at runtime. So we're not
>> only talking about dynamic clients.
>> >>
>> >>
>> >>
>> >> A client metadata parameter also implies that the AS allows some
>> clients to make non-PAR requests (otherwise it would be an AS metadata
>> parameter).
>> >>
>> >> A per client setting seems necessary for existing ASs to roll out PAR
>> support over time or just generally in support of diverse client
>> capabilities and requirements.
>> >>
>> >>
>> >> If that’s the case then presumably a malicious party could register
>> their own client that doesn’t use PAR.
>> >>
>> >> So it seems to me that the only scenario that this parameter would
>> protect against is a malicious party impersonating a dynamically registered
>> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
>> the attacker uses its own client.
>> >>
>> >> This client metadata parameter is meant to be something that would
>> prevent a malicious actor from controlling the content of the authz request
>> parameters, which could be done by crafting the link and tricking a user
>> into following it. I mentioned mix-up as an example because the first
>> variant of it desribed at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>> does something along those lines.
>> >>
>> >>
>> >>
>> >> If a client can do PAR, the

Re: [OAUTH-WG] PAR and client metadata

[Filip Skokan]

Alternatively, `require_pushed_authorization_requests`. Since we already
have the `*require_*request_uri_registration` server and `*require_*
auth_time` client metadata properties.

WDYT?

S pozdravem,
*Filip Skokan*


On Sun, 26 Apr 2020 at 16:58, Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn’t this also mean it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this as
> the same?
> - Who decides whether PAR and request_uri are required? The client for its
> instances or the AS for the whole deployment?
>
> I’m in favour of coupling enforced PAR use with enforced request_uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare forced
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs for
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter “pushed_authorization_requests_only” of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter “pushed_authorization_requests_only”
> - It requires this client to use PAR only. The AS won’t accept any
> authorization request containing more than request_uri + client_id for that
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR for
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
> >>
> >> As I tried to articulate in the original email and Filip also mentioned
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that’s the case then presumably a malicious party could register
> their own client that doesn’t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically registered
> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz request
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we’re further limited to scenarios where the attacker does not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> —
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pin

Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

I think your proposal hits the right level of granularity and usefulness.
And I'm thrilled that you went ahead and offered up a name.

On Sun, Apr 26, 2020 at 8:58 AM Torsten Lodderstedt  wrote:

> Hi all,
>
> I think this topic has several aspects:
> - Is the client required to use PAR only? Doesn’t this also mean it is
> required to use request_uri only?
> - Is there a need to separate those to questions or shall we treat this as
> the same?
> - Who decides whether PAR and request_uri are required? The client for its
> instances or the AS for the whole deployment?
>
> I’m in favour of coupling enforced PAR use with enforced request_uri use
> even though it means the setting is useful with PAR only, not with all
> JAR-based clients.
> I think both the client as well as the AS should be able to declare forced
> PAR. If the AS is able to basically turn of traditional authorization
> requests, it can consequently utilize the changed protocol properties in
> terms of security and robustness in its deployment. This means, for
> example, the AS no longer needs to require pre-registered redirect URIs for
> confidential clients. It also means, the AS can use voluminous
> claims/authorization details objects without worrying about fragile long
> request URLs.
>
> So here is my proposal:
>
> 1) Add server metadata parameter “pushed_authorization_requests_only” of
> type boolean - It requires any client to use PAR, the AS will refuse to
> process any authorization request containing parameters other than
> request_uri + client_id (as required by
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). Extension
> request parameters need to be passed via PAR.
> 2) Add client registration parameter “pushed_authorization_requests_only”
> - It requires this client to use PAR only. The AS won’t accept any
> authorization request containing more than request_uri + client_id for that
> particular client.
>
> What are your thoughts?
>
> best regards,
> Torsten.
>
> > On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov 
> wrote:
> >
> > In a off-list conversation Torsten floated the idea of letting
> confidential PAR-only clients register without a redirect_uris and having
> this "PAR only" parameter will enable that.
> >
> > A "PAR only" parameter will also prevent client developers from
> accidentally making plain authz requests (for clients that rely on PAR for
> the extra security).
> >
> > Vladimir
> >
> > On 16/04/2020 18:39, Brian Campbell wrote:
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
> >>
> >> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
> >>
> >> As I tried to articulate in the original email and Filip also mentioned
> in a different fork of this email thread, defining metadata can be
> beneficial even when it's not used dynamically at runtime. So we're not
> only talking about dynamic clients.
> >>
> >>
> >>
> >> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS metadata
> parameter).
> >>
> >> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
> >>
> >>
> >> If that’s the case then presumably a malicious party could register
> their own client that doesn’t use PAR.
> >>
> >> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically registered
> client that uses PAR. That wouldn’t apply to Mix-Up, since in that attack
> the attacker uses its own client.
> >>
> >> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz request
> parameters, which could be done by crafting the link and tricking a user
> into following it. I mentioned mix-up as an example because the first
> variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> does something along those lines.
> >>
> >>
> >>
> >> If a client can do PAR, then it can do authorization code grant and
> PKCE, so we’re further limited to scenarios where the attacker does not
> need to be able to redeem the authorization code themselves. What threats
> fall into this category?
> >>
> >> —
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >>
> >>> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >>>
> >>> 
> >>> CAUTION: This email origi

Re: [OAUTH-WG] PAR and client metadata

[Torsten Lodderstedt]

Hi all, 

I think this topic has several aspects: 
- Is the client required to use PAR only? Doesn’t this also mean it is required 
to use request_uri only?
- Is there a need to separate those to questions or shall we treat this as the 
same? 
- Who decides whether PAR and request_uri are required? The client for its 
instances or the AS for the whole deployment? 

I’m in favour of coupling enforced PAR use with enforced request_uri use even 
though it means the setting is useful with PAR only, not with all JAR-based 
clients.
I think both the client as well as the AS should be able to declare forced PAR. 
If the AS is able to basically turn of traditional authorization requests, it 
can consequently utilize the changed protocol properties in terms of security 
and robustness in its deployment. This means, for example, the AS no longer 
needs to require pre-registered redirect URIs for confidential clients. It also 
means, the AS can use voluminous claims/authorization details objects without 
worrying about fragile long request URLs.  

So here is my proposal:

1) Add server metadata parameter “pushed_authorization_requests_only” of type 
boolean - It requires any client to use PAR, the AS will refuse to process any 
authorization request containing parameters other than request_uri + client_id 
(as required by https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21). 
Extension request parameters need to be passed via PAR.
2) Add client registration parameter “pushed_authorization_requests_only” - It 
requires this client to use PAR only. The AS won’t accept any authorization 
request containing more than request_uri + client_id for that particular 
client. 

What are your thoughts?

best regards,
Torsten. 

> On 19. Apr 2020, at 10:09, Vladimir Dzhuvinov  wrote:
> 
> In a off-list conversation Torsten floated the idea of letting confidential 
> PAR-only clients register without a redirect_uris and having this "PAR only" 
> parameter will enable that.
> 
> A "PAR only" parameter will also prevent client developers from accidentally 
> making plain authz requests (for clients that rely on PAR for the extra 
> security).
> 
> Vladimir
> 
> On 16/04/2020 18:39, Brian Campbell wrote:
>> 
>> 
>> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle 
>>  wrote:
>> As I think through this, I’m struggling to identify the threats this 
>> actually helps mitigate.
>> 
>> A client metadata parameter implies that the value may be different for 
>> different clients, and that any given client won’t already know via other 
>> means whether or not it needs to use PAR. That means we’re only talking 
>> about dynamic clients since statically registered clients already have some 
>> proprietary out-of-band registration mechanism (e.g., a developer console).
>> 
>> As I tried to articulate in the original email and Filip also mentioned in a 
>> different fork of this email thread, defining metadata can be beneficial 
>> even when it's not used dynamically at runtime. So we're not only talking 
>> about dynamic clients.
>> 
>>  
>> 
>> A client metadata parameter also implies that the AS allows some clients to 
>> make non-PAR requests (otherwise it would be an AS metadata parameter).
>> 
>> A per client setting seems necessary for existing ASs to roll out PAR 
>> support over time or just generally in support of diverse client 
>> capabilities and requirements. 
>> 
>>  
>> If that’s the case then presumably a malicious party could register their 
>> own client that doesn’t use PAR.
>> 
>> So it seems to me that the only scenario that this parameter would protect 
>> against is a malicious party impersonating a dynamically registered client 
>> that uses PAR. That wouldn’t apply to Mix-Up, since in that attack the 
>> attacker uses its own client.
>> 
>> This client metadata parameter is meant to be something that would prevent a 
>> malicious actor from controlling the content of the authz request 
>> parameters, which could be done by crafting the link and tricking a user 
>> into following it. I mentioned mix-up as an example because the first 
>> variant of it desribed at 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>  does something along those lines. 
>> 
>>  
>> 
>> If a client can do PAR, then it can do authorization code grant and PKCE, so 
>> we’re further limited to scenarios where the attacker does not need to be 
>> able to redeem the authorization code themselves. What threats fall into 
>> this category?
>> 
>> —
>> Annabelle Backman (she/her)
>> AWS Identity
>> 
>>> On Apr 14, 2020, at 2:44 PM, Brian Campbell 
>>>  wrote:
>>> 
>>> 
>>> CAUTION: This email originated from outside of the organization. Do not 
>>> click links or open attachments unless you can confirm the sender and know 
>>> the content is safe.
>>> 
>>> 
>>> I was hoping to get to a rough consensus in support of the idea before 
>>> coming up with a name that everyone will hate :) 
>>> 
>>> In the m

Re: [OAUTH-WG] PAR and client metadata

[Vladimir Dzhuvinov]

In a off-list conversation Torsten floated the idea of letting
confidential PAR-only clients register without a redirect_uris and
having this "PAR only" parameter will enable that.

A "PAR only" parameter will also prevent client developers from
accidentally making plain authz requests (for clients that rely on PAR
for the extra security).

Vladimir

On 16/04/2020 18:39, Brian Campbell wrote:
>
>
> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle
>  > wrote:
>
> As I think through this, I’m struggling to identify the threats
> this actually helps mitigate.
>
> A client metadata parameter implies that the value may be
> different for different clients, and that any given client won’t
> already know via other means whether or not it needs to use PAR.
> That means we’re only talking about dynamic clients since
> statically registered clients already have some proprietary
> out-of-band registration mechanism (e.g., a developer console).
>
>
> As I tried to articulate in the original email and Filip also
> mentioned in a different fork of this email thread, defining metadata
> can be beneficial even when it's not used dynamically at runtime. So
> we're not only talking about dynamic clients.
>
>  
>
>
> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS
> metadata parameter).
>
>
> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
>
>  
>
> If that’s the case then presumably a malicious party could
> register their own client that doesn’t use PAR.
>
> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically
> registered client that uses PAR. That wouldn’t apply to Mix-Up,
> since in that attack the attacker uses its own client.
>
>
> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz
> request parameters, which could be done by crafting the link and
> tricking a user into following it. I mentioned mix-up as an example
> because the first variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> does something along those lines.
>
>  
>
>
> If a client can do PAR, then it can do authorization code grant
> and PKCE, so we’re further limited to scenarios where the attacker
> does not need to be able to redeem the authorization code
> themselves. What threats fall into this category?
>
> —
> Annabelle Backman (she/her)
> AWS Identity
>
>> On Apr 14, 2020, at 2:44 PM, Brian Campbell
>> > > wrote:
>>
>> 
>>
>> *CAUTION*: This email originated from outside of the
>> organization. Do not click links or open attachments unless you
>> can confirm the sender and know the content is safe.
>>
>>
>> I was hoping to get to a rough consensus in support of the idea
>> before coming up with a name that everyone will hate :)
>>
>> In the meantime, however, name suggestions are of course welcome.
>>
>>
>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> I'm all for that.
>>
>> I suppose you have already thought of a suitable name? :)
>>
>> Vladimir
>>
>> On 14/04/2020 23:08, Brian Campbell wrote:
>>> Using PAR can facilitate improved security by giving clients
>>> a (relatively) simple means for sending a confidential,
>>> integrity protected, and (for confidential clients anyway)
>>> authenticated authorization request.
>>>
>>> It seems like some of that improved security could be
>>> undermined by a malicious actor somehow getting a user to
>>> navigate to a URL of a regular old parameterized
>>> authorization request. One variation of the Mix-Up Attack
>>> does this
>>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>> 
>>> 
>>> for example and email, social media, online forums, etc.,
>>> are other ways a user might be tricked into following a
>>> maliciously crafted link. 
>>>
>>> Following from that it seems logical that an authorization
>>> server might want to restrict some clients from sending a
>>> regular parameterized authorization request and instead
>>> require use of the PAR endpoint to initiate an authorization
>>> request. Something like this could, of course, be
>>> implemented as custom policy or configuration in any AS. But
>>

Re: [OAUTH-WG] PAR and client metadata

[George Fletcher]

I don't know about a PAR "requirement", but it feels like the PAR spec 
is the right place to put this. My understanding of what's being asked 
is... how does the AS advertise to it's clients that it will ONLY accept 
PAR based request_uris and other authn/authz request methods will fail.


On 4/17/20 3:22 AM, Torsten Lodderstedt wrote:

Is this really a PAR requirement? I’m asking since the client in the end is 
required to use an authorization request in the fron channel but with a PAR 
request_uri. So one could see this as a constrained on the authorisation 
request itself. Another question is whether this request_uri must be PAR based 
or whether it could be any other request_uri.


On 16. Apr 2020, at 23:05, George Fletcher  
wrote:

Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe 
whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" and "par" 
(redirect not being quite right:) which allows for expansion in the future. That way the AS could 
easily signal whether it supports both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:

But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?

___
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

Re: [OAUTH-WG] PAR and client metadata

[Torsten Lodderstedt]

Is this really a PAR requirement? I’m asking since the client in the end is 
required to use an authorization request in the fron channel but with a PAR 
request_uri. So one could see this as a constrained on the authorisation 
request itself. Another question is whether this request_uri must be PAR based 
or whether it could be any other request_uri.

> On 16. Apr 2020, at 23:05, George Fletcher 
>  wrote:
> 
> Maybe if we make it an array of authorization "flows" supported? A bit like 
> the AS can describe whether it supports "pairwise", "public" or both?
> 
> Not sure what to name it though:) Possible values could be "redirect" and 
> "par" (redirect not being quite right:) which allows for expansion in the 
> future. That way the AS could easily signal whether it supports both or just 
> one. It does mean the discovery doc is redundant in specifying that the AS 
> supports PAR but that's probably ok.
> 
> On 4/16/20 4:50 PM, Brian Campbell wrote:
>> But do you think that an AS-wide policy
>> signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
>> needed or sufficiently useful?
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[George Fletcher]

Maybe if we make it an array of authorization "flows" supported? A bit 
like the AS can describe whether it supports "pairwise", "public" or both?


Not sure what to name it though:) Possible values could be "redirect" 
and "par" (redirect not being quite right:) which allows for expansion 
in the future. That way the AS could easily signal whether it supports 
both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.


On 4/16/20 4:50 PM, Brian Campbell wrote:

But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

On Thu, Apr 16, 2020 at 2:15 AM Filip Skokan  wrote:

> I would support defining a client level property. I would also support an
> AS discovery property for an AS-wide policy that is signalled to all
> clients (and maybe that one would be enough).
>

I do think there needs to be something at the client level for it to be
useful. My thinking was that one AS-wide policy would be too broad to be of
much use. Many existing ASs will need to roll out PAR support over time or
more generally just support diverse clients with different capabilities and
requirements including PAR forever. The AS can advertise support for PAR by
including a "pushed_authorization_request_endpoint" parameter. Which is
roughly consistent with other AS metadata that's mostly about advertising
the set of supported capabilities. But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


> FWIW (and this touches my earlier responses about the dpop scheme)
> defining metadata (both AS and Client) is beneficial not only for runtime
> (DCR, discovery) but in general supports developers using these specs, when
> they read about a possible behaviour in the document and there's a
> mentioned metadata property, they know what to look for in readmes, API
> documentation, UI etc. It saves time, theirs, and mine when i develop those
> behaviour toggles - i don't have to start mixing configuration objects so
> far composed entirely of IANA registered properties with proprietary ones,
> i don't need to come up with property names (and we know what a PITA that
> is) and it also saves time in the long run because it's less likely someone
> will open an issue about it.
>

That is good and useful perspective, thanks for sharing that.


Best,
> *Filip*
>
>
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Using PAR can facilitate improved security by giving clients a
>> (relatively) simple means for sending a confidential, integrity protected,
>> and (for confidential clients anyway) authenticated authorization request.
>>
>> It seems like some of that improved security could be undermined by a
>> malicious actor somehow getting a user to navigate to a URL of a regular
>> old parameterized authorization request. One variation of the Mix-Up Attack
>> does this
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>> for example and email, social media, online forums, etc., are other ways a
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might
>> want to restrict some clients from sending a regular parameterized
>> authorization request and instead require use of the PAR endpoint to
>> initiate an authorization request. Something like this could, of course, be
>> implemented as custom policy or configuration in any AS. But I'm thinking
>> it might be common enough to warrant adding a client metadata parameter to
>> the PAR draft specifically for it. The metadata (and registered extensions)
>> defined by Dynamic Client Registration [RFC7591] has come to imply a
>> general data model and expected associated behaviors for clients that is
>> useful for authorization server implementations, even when the Dynamic
>> Client Registration Protocol isn't directly in play. This particular
>> situation seems like a good potential candidate for a new such client
>> metadata parameter that would indicate that the given client can only use a
>> request_uri value obtained from the PAR endpoint to initiate an
>> authorization request. And that a regular old fashioned authorization
>> request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a
>> worthwhile addition to the PAR draft?
>>
>>
>>
>>
>>
>> *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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

-- 
_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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle  wrote:

> As I think through this, I’m struggling to identify the threats this
> actually helps mitigate.
>
> A client metadata parameter implies that the value may be different for
> different clients, and that any given client won’t already know via other
> means whether or not it needs to use PAR. That means we’re only talking
> about dynamic clients since statically registered clients already have some
> proprietary out-of-band registration mechanism (e.g., a developer console).
>

As I tried to articulate in the original email and Filip also mentioned in
a different fork of this email thread, defining metadata can be beneficial
even when it's not used dynamically at runtime. So we're not only talking
about dynamic clients.



>
> A client metadata parameter also implies that the AS allows some clients
> to make non-PAR requests (otherwise it would be an AS metadata parameter)..
>

A per client setting seems necessary for existing ASs to roll out PAR
support over time or just generally in support of diverse client
capabilities and requirements.



> If that’s the case then presumably a malicious party could register their
> own client that doesn’t use PAR.
>
> So it seems to me that the only scenario that this parameter would protect
> against is a malicious party impersonating a dynamically registered client
> that uses PAR. That wouldn’t apply to Mix-Up, since in that attack the
> attacker uses its own client.
>

This client metadata parameter is meant to be something that would prevent
a malicious actor from controlling the content of the authz request
parameters, which could be done by crafting the link and tricking a user
into following it. I mentioned mix-up as an example because the first
variant of it desribed at
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4..1
does something along those lines.



>
> If a client can do PAR, then it can do authorization code grant and PKCE,
> so we’re further limited to scenarios where the attacker does not need to
> be able to redeem the authorization code themselves. What threats fall into
> this category?
>
> —
> Annabelle Backman (she/her)
> AWS Identity
>
> On Apr 14, 2020, at 2:44 PM, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
> 
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> I was hoping to get to a rough consensus in support of the idea before
> coming up with a name that everyone will hate :)
>
> In the meantime, however, name suggestions are of course welcome.
>
>
> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> I'm all for that.
>>
>> I suppose you have already thought of a suitable name? :)
>>
>> Vladimir
>> On 14/04/2020 23:08, Brian Campbell wrote:
>>
>> Using PAR can facilitate improved security by giving clients a
>> (relatively) simple means for sending a confidential, integrity protected,
>> and (for confidential clients anyway) authenticated authorization request.
>>
>> It seems like some of that improved security could be undermined by a
>> malicious actor somehow getting a user to navigate to a URL of a regular
>> old parameterized authorization request. One variation of the Mix-Up Attack
>> does this
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>> 
>> for example and email, social media, online forums, etc., are other ways a
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might
>> want to restrict some clients from sending a regular parameterized
>> authorization request and instead require use of the PAR endpoint to
>> initiate an authorization request. Something like this could, of course, be
>> implemented as custom policy or configuration in any AS. But I'm thinking
>> it might be common enough to warrant adding a client metadata parameter to
>> the PAR draft specifically for it. The metadata (and registered extensions)
>> defined by Dynamic Client Registration [RFC7591] has come to imply a
>> general data model and expected associated behaviors for clients that is
>> useful for authorization server implementations, even when the Dynamic
>> Client Registration Protocol isn't directly in play. This particular
>> situation seems like a good potential candidate for a new such client
>> metadata parameter that would indicate that the given client can only use a
>> request_uri value obtained from the PAR endpoint to initiate an
>> authorization request. And that a regular old fashioned authorization
>> request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a
>> worthwhile addition to 

Re: [OAUTH-WG] PAR and client metadata

[Sascha Preibisch]

I am also in favour of such metadata.

I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_uri only. This may be
a implementation detail of the AS, just wanted to mention it.

Regards,
Sascha

On Thu, 16 Apr 2020 at 01:16, Filip Skokan  wrote:
>
> I would support defining a client level property. I would also support an AS 
> discovery property for an AS-wide policy that is signalled to all clients 
> (and maybe that one would be enough).
>
> FWIW (and this touches my earlier responses about the dpop scheme) defining 
> metadata (both AS and Client) is beneficial not only for runtime (DCR, 
> discovery) but in general supports developers using these specs, when they 
> read about a possible behaviour in the document and there's a mentioned 
> metadata property, they know what to look for in readmes, API documentation, 
> UI etc. It saves time, theirs, and mine when i develop those behaviour 
> toggles - i don't have to start mixing configuration objects so far composed 
> entirely of IANA registered properties with proprietary ones, i don't need to 
> come up with property names (and we know what a PITA that is) and it also 
> saves time in the long run because it's less likely someone will open an 
> issue about it.
>
> Best,
> Filip
>
>
> On Tue, 14 Apr 2020 at 22:09, Brian Campbell 
>  wrote:
>>
>> Using PAR can facilitate improved security by giving clients a (relatively) 
>> simple means for sending a confidential, integrity protected, and (for 
>> confidential clients anyway) authenticated authorization request.
>>
>> It seems like some of that improved security could be undermined by a 
>> malicious actor somehow getting a user to navigate to a URL of a regular old 
>> parameterized authorization request. One variation of the Mix-Up Attack does 
>> this 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>  for example and email, social media, online forums, etc., are other ways a 
>> user might be tricked into following a maliciously crafted link.
>>
>> Following from that it seems logical that an authorization server might want 
>> to restrict some clients from sending a regular parameterized authorization 
>> request and instead require use of the PAR endpoint to initiate an 
>> authorization request. Something like this could, of course, be implemented 
>> as custom policy or configuration in any AS. But I'm thinking it might be 
>> common enough to warrant adding a client metadata parameter to the PAR draft 
>> specifically for it. The metadata (and registered extensions) defined by 
>> Dynamic Client Registration [RFC7591] has come to imply a general data model 
>> and expected associated behaviors for clients that is useful for 
>> authorization server implementations, even when the Dynamic Client 
>> Registration Protocol isn't directly in play. This particular situation 
>> seems like a good potential candidate for a new such client metadata 
>> parameter that would indicate that the given client can only use a 
>> request_uri value obtained from the PAR endpoint to initia
 te an authorization request. And that a regular old fashioned authorization 
request from the given client would result in an error.
>>
>> Do the folks of this fine WG think something like this would be a worthwhile 
>> addition to the PAR draft?
>>
>>
>>
>>
>>
>> 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
>> 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

Re: [OAUTH-WG] PAR and client metadata

[Filip Skokan]

I would support defining a client level property. I would also support an
AS discovery property for an AS-wide policy that is signalled to all
clients (and maybe that one would be enough).

FWIW (and this touches my earlier responses about the dpop scheme) defining
metadata (both AS and Client) is beneficial not only for runtime (DCR,
discovery) but in general supports developers using these specs, when they
read about a possible behaviour in the document and there's a mentioned
metadata property, they know what to look for in readmes, API
documentation, UI etc. It saves time, theirs, and mine when i develop those
behaviour toggles - i don't have to start mixing configuration objects so
far composed entirely of IANA registered properties with proprietary ones,
i don't need to come up with property names (and we know what a PITA that
is) and it also saves time in the long run because it's less likely someone
will open an issue about it.

Best,
*Filip*


On Tue, 14 Apr 2020 at 22:09, Brian Campbell  wrote:

> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[Brian Campbell]

I was hoping to get to a rough consensus in support of the idea before
coming up with a name that everyone will hate :)

In the meantime, however, name suggestions are of course welcome.


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov 
wrote:

> I'm all for that.
>
> I suppose you have already thought of a suitable name? :)
>
> Vladimir
> On 14/04/2020 23:08, Brian Campbell wrote:
>
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request..
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4..4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] PAR and client metadata

[Vladimir Dzhuvinov]

I'm all for that.

I suppose you have already thought of a suitable name? :)

Vladimir

On 14/04/2020 23:08, Brian Campbell wrote:
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity
> protected, and (for confidential clients anyway) authenticated
> authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a
> regular old parameterized authorization request. One variation of the
> Mix-Up Attack does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other
> ways a user might be tricked into following a maliciously crafted link. 
>
> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular
> parameterized authorization request and instead require use of the PAR
> endpoint to initiate an authorization request. Something like this
> could, of course, be implemented as custom policy or configuration in
> any AS. But I'm thinking it might be common enough to warrant adding a
> client metadata parameter to the PAR draft specifically for it. The
> metadata (and registered extensions) defined by Dynamic Client
> Registration [RFC7591] has come to imply a general data model and
> expected associated behaviors for clients that is useful for
> authorization server implementations, even when the Dynamic Client
> Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only
> use a request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> /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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth