Re: [OAUTH-WG] RAR & multiple resources?

[Dick Hardt]

That’s what I thought. Thanks for the clarification.

On Mon, Jan 13, 2020 at 6:20 PM Justin Richer  wrote:

> Multiple access tokens are outside the scope of RAR. The request is
> intended to describe the access for a single returned access token. If
> semantics for multiple access tokens are agreed upon, then it can use the
> RAR structure, the Resources parameter, and the Scope parameter all in
> parallel again.
>
>  — Justin
>
> > On Jan 13, 2020, at 8:31 PM, Dick Hardt  wrote:
> >
> > Torsten / Justin / Brian
> >
> > In my reading of the ID, it appears that there is a request for just one
> access token, and the authorization_details array lists one or more
> resources that the one access token will provide access to. Correct?
> >
> > I have heard anecdotally that there is interest in granting access to
> multiple resources, and having multiple access tokens, which would enable
> different components of a client to have different access tokens.
> >
> > Do you consider multiple access tokens out of scope of RAR?
> >
> > /Dick
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Benjamin Kaduk]

On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree that we 
> shouldn’t specify that “it’s a JWT” or something of that nature. But if we 
> call the result of PAR “thing X” and the target of request_uri “thing X” in 
> JAR, then we’re compatible without saying what “thing X” needs to be in all 
> cases. 
> 

That seems fair.  What properties would a given "thing X" need to have in
order to work, though -- uniqueness over a specific period of time?
Unpredictability?  More?

-Ben

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

[Aaron Parecki]

Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be
fine to include additional keys that are used for something other than
access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a
decent extension mechanism.



On Mon, Jan 13, 2020 at 6:26 PM Justin Richer  wrote:

> I would rather see extensions define a key ID than a new key set URI.
> Otherwise what’s the point of having more than one key in the set, with
> unique identifiers?
>
> It would’ve been nice if JWK could’ve agreed on a URL-based addressing
> format for individual keys within the set, but that ship’s sailed..
>
>
>  — Justin
>
> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
>
> I was not saying that there was anything special about keys, nor that we
> needed to change OAuth.
>
> While using one key and controlling where it us used via access control
> works, it is not ideal.
>
> OAuth could have had just one endpoint, and done access control for
> different roles -- but it did not. We enabled flexibility by separating the
> authorization endpoint and the token endpoint. The dynamic client
> registration extension defined a new endpoint, the registration endpoint.
>
> I don't think we can change what has been deployed today -- but NEW
> extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
>
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden 
> wrote:
>
>> Sure, but we know how to run resilient services. My point is that there’s
>> nothing particularly special about cryptographic keys: if you want to
>> control how they are used there is a whole range of normal access control
>> methods you can apply to them without needing to change anything in OAuth.
>>
>> Neil
>>
>> On 10 Jan 2020, at 18:50, Dick Hardt  wrote:
>>
>> 
>> There are many other factors to resiliency than multiple instances.
>>
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden 
>> wrote:
>>
>>>
>>>
>>> > On 10 Jan 2020, at 17:22, Dick Hardt  wrote:
>>> [...]
>>> >
>>> > As to the suggestion of using a JWT-decryption-microservice, another
>>> goal would be increased resiliency of the components. If the
>>> JWT-decryption-microservice is unavailable, the whole system is
>>> unavailable. If there are separate keys, then a failure in one component
>>> does not fail the entire system.
>>>
>>> Well you can run more than one instance - it’s a completely stateless
>>> service. You can also run a separate instance (or set of instances) per key
>>> if you like.
>>>
>>> Neil
>>
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

[Justin Richer]

I would rather see extensions define a key ID than a new key set URI. Otherwise 
what’s the point of having more than one key in the set, with unique 
identifiers?

It would’ve been nice if JWK could’ve agreed on a URL-based addressing format 
for individual keys within the set, but that ship’s sailed.

 — Justin

> On Jan 10, 2020, at 9:34 PM, Dick Hardt  wrote:
> 
> I was not saying that there was anything special about keys, nor that we 
> needed to change OAuth.
> 
> While using one key and controlling where it us used via access control 
> works, it is not ideal.
> 
> OAuth could have had just one endpoint, and done access control for different 
> roles -- but it did not. We enabled flexibility by separating the 
> authorization endpoint and the token endpoint. The dynamic client 
> registration extension defined a new endpoint, the registration endpoint.
> 
> I don't think we can change what has been deployed today -- but NEW 
> extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
> 
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden  > wrote:
> Sure, but we know how to run resilient services. My point is that there’s 
> nothing particularly special about cryptographic keys: if you want to control 
> how they are used there is a whole range of normal access control methods you 
> can apply to them without needing to change anything in OAuth. 
> 
> Neil
> 
>> On 10 Jan 2020, at 18:50, Dick Hardt > > wrote:
>> 
>> 
>> There are many other factors to resiliency than multiple instances. 
>> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden > > wrote:
>> 
>> 
>> > On 10 Jan 2020, at 17:22, Dick Hardt > > > wrote:
>> [...]
>> > 
>> > As to the suggestion of using a JWT-decryption-microservice, another goal 
>> > would be increased resiliency of the components. If the 
>> > JWT-decryption-microservice is unavailable, the whole system is 
>> > unavailable. If there are separate keys, then a failure in one component 
>> > does not fail the entire system. 
>> 
>> Well you can run more than one instance - it’s a completely stateless 
>> service. You can also run a separate instance (or set of instances) per key 
>> if you like. 
>> 
>> Neil

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

Re: [OAUTH-WG] RAR & multiple resources?

[Justin Richer]

Multiple access tokens are outside the scope of RAR. The request is intended to 
describe the access for a single returned access token. If semantics for 
multiple access tokens are agreed upon, then it can use the RAR structure, the 
Resources parameter, and the Scope parameter all in parallel again.

 — Justin

> On Jan 13, 2020, at 8:31 PM, Dick Hardt  wrote:
> 
> Torsten / Justin / Brian
> 
> In my reading of the ID, it appears that there is a request for just one 
> access token, and the authorization_details array lists one or more resources 
> that the one access token will provide access to. Correct?
> 
> I have heard anecdotally that there is interest in granting access to 
> multiple resources, and having multiple access tokens, which would enable 
> different components of a client to have different access tokens. 
> 
> Do you consider multiple access tokens out of scope of RAR?
> 
> /Dick

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

Re: [OAUTH-WG] [EXTERNAL] RAR & multiple resources?

[Mike Jones]

Please don’t use RAR as a pandora’s box to introduce unrelated new semantics, 
including issuing multiple access tokens.

   -- Mike

From: OAuth  On Behalf Of Dick Hardt
Sent: Monday, January 13, 2020 5:32 PM
To: Torsten Lodderstedt ; Brian Campbell 
; Justin Richer 
Cc: oauth@ietf.org
Subject: [EXTERNAL] [OAUTH-WG] RAR & multiple resources?

Torsten / Justin / Brian

In my reading of the ID, it appears that there is a request for just one access 
token, and the authorization_details array lists one or more resources that the 
one access token will provide access to. Correct?

I have heard anecdotally that there is interest in granting access to multiple 
resources, and having multiple access tokens, which would enable different 
components of a client to have different access tokens.

Do you consider multiple access tokens out of scope of RAR?

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

Re: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession tokens

[Dick Hardt]

3/4 options are at the same time on the same day of the week. More options
would be nice!

On Mon, Jan 13, 2020 at 9:19 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> at the Singapore IETF meeting we talked about setting time aside for
> discussing proof-of-possession tokens.
>
>
>
> To schedule a call we put a Doodle poll together:
>
> https://doodle.com/poll/sqhbeeg6knp435ag
>
>
>
> Please let us know by the end of the week what dates work for you.
>
>
>
> Ciao
>
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you. IMPORTANT NOTICE: The contents of
> this email and any attachments are confidential and may also be privileged.
> If you are not the intended recipient, please notify the sender immediately
> and do not disclose the contents to any other person, use it for any
> purpose, or store or copy the information in any medium. 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-WG] RAR & multiple resources?

[Dick Hardt]

Torsten / Justin / Brian

In my reading of the ID, it appears that there is a request for just one
access token, and the authorization_details array lists one or more
resources that the one access token will provide access to. Correct?

I have heard anecdotally that there is interest in granting access to
multiple resources, and having multiple access tokens, which would enable
different components of a client to have different access tokens.

Do you consider multiple access tokens out of scope of RAR?

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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Brian Campbell]

+1

On Mon, Jan 13, 2020, 4:15 PM Richard Backman, Annabelle  wrote:

> My original suggestion was to remove this requirement from cases where the
> AS originally provided the request_uri, because in these cases, the
> request_uri resolution becomes an internal implementation detail of the AS.
> I still think that’s the best criterion to use for when this requirement
> should apply. This criterion covers all JAR implementations, as the JAR
> endpoint is explicitly defined as being part of the AS.
>
>
>
> Note that “AS” refers to a role within OAuth, and that role may be
> implemented by a collection of micro services and/or third party services..
> From an interop standpoint, it doesn’t matter that the PAR endpoint and
> authorization endpoint are hosted on separate micro services; it’s still
> the AS vending out a request_uri for its own consumption later. Whether
> that request_uri is resolved via a local DB lookup, internal web service
> call, or HTTP request to an S3 bucket is irrelevant.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Justin Richer <
> jric...@mit.edu>
> *Date: *Monday, January 13, 2020 at 9:33 AM
> *To: *Vladimir Dzhuvinov 
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle" 
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
>
>
> To be clear, I’m not saying we suggest a particular form, and I agree that
> we shouldn’t specify that “it’s a JWT” or something of that nature. But if
> we call the result of PAR “thing X” and the target of request_uri “thing X”
> in JAR, then we’re compatible without saying what “thing X” needs to be in
> all cases.
>
>
>
> In cases where you do a remote look up, we want “thing X” to be formatted
> as a JWT.
>
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believe
> that’s been backed off now and made conditional.
>
>
>
>  — Justin
>
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov 
> wrote:
>
>
>
> My suggestion is to abstain from specifying the concrete form of the
> resource pointed to by the PAR URI. Regardless of URI type (URN,
> downloadable https URL or something else), and even if the PAR endpoint and
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
>
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
>
> Even if we eventually end up in microservice world, or allow the PAR
> endpoint to be managed by some external entity, the PAR URI - its
> interpretation, validation and potentially resource retrieval (JWT or other
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
>
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end..
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, without
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
>
>
> The normative language I think should focus on maintaining the OAuth 2.0
> contract for the entire logical authZ request, together with the basic
> contracts of 1) JAR and the 2) authZ endpoint.
>
>
>
> Vladimir
>
>
>
> On 10/01/2020 22:55, Justin Richer wrote:
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it’s a JWT and instead
> say it’s a request object. Or we define a new term for this authorization
> request blob thing.
>
>
>
> Or PAR could at least say that if it’s dereferenced over a remote protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That’s
> where the real interop concerns come in.
>
>
>
>  — Justin
>
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=40amazon@dmarc.ietf.org> wrote:
>
>
>
> Correct. The problem becomes pretty clear in the context of PAR, where the
> AS is generating and vending out the URI at the PAR endpoint, and consuming
> it at the authorization endpoint. From an interoperability standpoint, it’s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *John Bradley 
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell 
> *Cc: *Torsten Lodderstedt , Nat Sakimura <
> n...@sakimura.org>, "Richard Backman, Annabelle" ,
> oauth 
> *Subject:

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

To be clear, I’m not saying we suggest a particular form, and I agree that we 
shouldn’t specify that “it’s a JWT” or something of that nature. But if we call 
the result of PAR “thing X” and the target of request_uri “thing X” in JAR, 
then we’re compatible without saying what “thing X” needs to be in all cases. 

In cases where you do a remote look up, we want “thing X” to be formatted as a 
JWT. 

We had a case of similarly unintentional limiting in JAR previously, saying 
that you had to do an HTTP lookup on the request_uri, but I believe that’s been 
backed off now and made conditional.

 — Justin

> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov  
> wrote:
> 
> My suggestion is to abstain from specifying the concrete form of the resource 
> pointed to by the PAR URI. Regardless of URI type (URN, downloadable https 
> URL or something else), and even if the PAR endpoint and the authZ endpoint 
> are managed by two different entities (microservice or other scenario).
> 
> In the Connect2id implementation of PAR the returned URI doesn't point to a 
> request object and it doesn't point to a JWT either. It points to an 
> internally stored "pre-processed" authZ request, which the authZ endpoint 
> then picks up to complete the authZ.
> 
> Even if we eventually end up in microservice world, or allow the PAR endpoint 
> to be managed by some external entity, the PAR URI - its interpretation, 
> validation and potentially resource retrieval (JWT or other blob), is an 
> "internal contract" on the AS side. This doesn't concern the client, and in 
> OAuth 2.0 the role of AS is indivisible.
> 
> 
> 
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request: the 
> client submits an authZ request and gets an authZ response at the end. The 
> URI is necessary for the client to proceed from the 1st to the 2nd step. If 
> we manage to frame / word the PAR URI in this logical way, without getting 
> stuck in the JAR definition / framing of what the request_uri / object is, it 
> would be great.
> 
> 
> 
> The normative language I think should focus on maintaining the OAuth 2.0 
> contract for the entire logical authZ request, together with the basic 
> contracts of 1) JAR and the 2) authZ endpoint.
> 
> 
> 
> Vladimir
> 
> 
> 
> On 10/01/2020 22:55, Justin Richer wrote:
>> So we could solve this by saying the resulting data object of a PAR is a 
>> request object. Which might also contain a request object internally as 
>> well. In that case JAR should back off from saying it’s a JWT and instead 
>> say it’s a request object. Or we define a new term for this authorization 
>> request blob thing.
>> 
>> Or PAR could at least say that if it’s dereferenced over a remote protocol 
>> then it MUST be a JWT, but otherwise it can be whatever you want. That’s 
>> where the real interop concerns come in.
>> 
>>  — Justin
>> 
>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle 
>>> >> > wrote:
>>> 
>>> Correct. The problem becomes pretty clear in the context of PAR, where the 
>>> AS is generating and vending out the URI at the PAR endpoint, and consuming 
>>> it at the authorization endpoint. From an interoperability standpoint, it’s 
>>> analogous to the AS vending an authorization code at the authorization 
>>> endpoint and consuming it at the token endpoint.
>>> – 
>>> Annabelle Richard Backman
>>> AWS Identity
>>>  
>>>  
>>> From: John Bradley mailto:ve7...@ve7jtb.com>>
>>> Date: Friday, January 10, 2020 at 12:29 PM
>>> To: Brian Campbell >> >
>>> Cc: Torsten Lodderstedt >> >, Nat Sakimura >> >, "Richard Backman, Annabelle" 
>>> mailto:richa...@amazon.com>>, oauth >> >
>>> Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must 
>>> become JWTs
>>>  
>>> If we assume the client posts a JAR and gets back a reference.  Then the 
>>> reference is to a JAR. 
>>>  
>>> I think I see the problem.  If the server providing the reference is 
>>> associated with the AS then the server dosen't need to dereference the 
>>> object via HTTP, so it could be a URN as an example. 
>>>  
>>> So yes it is not a interoperability issue for the client.  
>>>  
>>> I will think about how I can finesse that. 
>>>  
>>> I agree it is not a change in intent. 
>>>  
>>> I will see if I can get our AD to accept that.
>>>  
>>> John B. 
>>>  
>>>  
>>>  
>>>  
>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell >> > wrote:
 Sure but the text proposed (or something like it) qualifies it such that 
 there aren't interoperability questions because it's only an 
 implementation detail to the AS who both produces the URI and consumes its 
 content.
  
 On Fri, Jan 10, 2020 at 12:48 PM John Bradley >>> > wrote:
> It may be a challenge to change text saying that the conten

[OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession tokens

[Hannes Tschofenig]

Hi all,

at the Singapore IETF meeting we talked about setting time aside for discussing 
proof-of-possession tokens.

To schedule a call we put a Doodle poll together:
https://doodle.com/poll/sqhbeeg6knp435ag

Please let us know by the end of the week what dates work for you.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you. IMPORTANT NOTICE: The contents of this email and any 
attachments are confidential and may also be privileged. If you are not the 
intended recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or copy the 
information in any medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

John, thanks, much appreciated!

On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header. 
>
> I will see if i can add something in final edits to call that out.
>
> John B.
>
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>
>> Thanks Mike for the rfc7519 section-5.3
>>  pointer. Can this
>> parameter replication be used for client_id or the client_id ass
>> "iss" even though it isn't explicitly mentioned in the JAR spec?
>>
>> On 11/01/2020 02:58, John Bradley wrote:
>>> Right we just don't say to put the iss there in OIDC if it's
>>> symetricly encrypted.
>>
>> OIDC doesn't have the symmetric key selection issue, I suppose that
>> why the possibility to replicate params to the JWE header isn't
>> mentioned at all. OIDC requires the top-level query params to
>> represent a valid OAuth 2.0 request, and there client_id is required.
>> If the client_id is present the client registration together with any
>> present client_secret can be retrieved.
>>
>> I reread the JAR spec, this is the only place that mentions handling
>> of symmetric JWE.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>
>>>(b)  Verifying that the symmetric key for the JWE encryption is the
>>> correct one if the JWE is using symmetric encryption.
>>
>>
>> Vladimir
>>
>>
>>>
>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>> mailto:michael.jo...@microsoft.com>>
>>> wrote:
>>>
>>> The technique of replicating JWT claims that need to be publicly
>>> visible in an encrypted JWT in the header is defined at
>>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to
>>> Dick Hardt for bringing this need to my attention as we were
>>> finishing the JWT spec.)
>>>
>>>  
>>>
>>>    -- Mike
>>>
>>>  
>>>
>>> *From:* OAuth >> > *On Behalf Of * John Bradley
>>> *Sent:* Friday, January 10, 2020 2:15 PM
>>> *To:* Vladimir Dzhuvinov >> >
>>> *Cc:* IETF oauth WG mailto:oauth@ietf.org>>
>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>>> Request (JAR) vs OIDC request object
>>>
>>>  
>>>
>>> The intent was to do that, but specs change once the OAuth WG
>>> and IESG get there hands on them.  
>>>
>>>  
>>>
>>> Being backwards compatible with OIDC is not a compelling
>>> argument to the IESG.
>>>
>>>  
>>>
>>> We were mostly thinking of asymmetric encryption.  
>>>
>>>  
>>>
>>> Specifying puting the issuer and or the audience in the headder
>>> has come up in the past but probably is not documented.  
>>>
>>>  
>>>
>>> John B 
>>>
>>>  
>>>
>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>> mailto:vladi...@connect2id.com>> wrote:
>>>
>>> Yes, putting the client_id into the JWE header is a way
>>> around the need
>>> to have the client_id outside the JWE as top-level authZ
>>> request parameter.
>>>
>>> Unfortunately this work around isn't mentioned anywhere, I
>>> just checked
>>> the most recent draft-ietf-oauth-jwsreq-20.
>>>
>>> Our DDoS attack mitigation (for OIDC request_uri) also
>>> relies on the
>>> presence of client_id as top-level parameter, together with
>>> requiring
>>> RPs to register their request_uri's (so that we don't need
>>> to build and
>>> store an index of all request_uri's). I just had a look at
>>> "DDoS Attack
>>> on the Authorization Server" and also realised the request_uri
>>> registration isn't explicitly mentioned as attack prevention
>>> ("the
>>> server should (a) check that the value of "request_uri"
>>> parameter does
>>> not point to an unexpected location").
>>>
>>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
>>> 
>>> 
>>>
>>> To be honest, I feel quite bad about the situation with JAR
>>> we are in
>>> now. For some reason I had the impression that OAuth JAR was
>>> going to be
>>> the OIDC request / request_uri for general OAuth 2.0 use, as
>>> with other
>>> OIDC bits that later became general purpose OAuth 2.0 specs.
>>>
>>> I find it unfortunate I didn't notice this when I was
>>> reviewing the spec
>>> in the past.
>>>
>>> Vladimir
>>>
>>>
>>> On 10/01/2020 22:39

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

[Matthew De Haast]

+1 for adoption

Matt

On Mon, Jan 6, 2020 at 9:38 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
>
> Please, let us know if you support or object to the adoption of this
> document as a working group document by Jan 20th.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> 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