For new extensions, giving the key uri a new name would seem to work the
same as we have different names for different endpoints.
The cow is out of the barn for current work though.
ᐧ
On Fri, Jan 10, 2020 at 1:22 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:
> Having different
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.
Right we just don't say to put the iss there in OIDC if it's symetricly
encrypted.
On Fri, Jan 10, 2020, 9:41 PM Mike Jones
wrote:
> The technique of replicating JWT claims that need to be publicly visible
> in an encrypted JWT in the header is defined at
>
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.)
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
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
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
Vladimir,
For that very case the payload claims may be repeated in the JWE protected
header. An implementation wanting to handle this may look for iss/client_id
there.
Odesláno z iPhonu
> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>
> I just realised there is one class of JARs where it's
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
I just realised there is one class of JARs where it's practially
impossible to process the request if merge isn't supported:
The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
for that and specs a method for deriving the shared key from the
client_secret:
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
It may be a challenge to change text saying that the contents of the
resource could be something other than a request object.
If not a request object then what and how is that interoperable are likely
AD questions.
I could perhaps see changing it to must be a request object, or other
format
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.
To restate my previous point, we may not be able to change what is
currently specified and deployed, but we can for future extensions such as
RAR and PAR.
To paraphrase Annabelle, this ship may have already sailed.
On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt wrote:
> The metadata document is
The metadata document is declarative, and can easily be yet another
separate role in the AS.
In large organizations, different people are empowered different roles, so
the team owning the metadata document could be different from the team
generating ID tokens, and different from the team
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
Agree and agree. But given that the change suggested by Annabelle has no
impact on the client or interoperability, perhaps Nat or John could work
the change into the draft during the edits that happen during the final
stages of things?
On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt 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
Can the keys in the document at the jwks_uri indicate what they are for?
Either by adding other top-level properties next to "keys" or by specifying
a property on a key itself? At least that way implementations that expect
just one value of jwks_uri wouldn't have to change.
Aaron
On Fri, Jan
Yes. Thanks for clarifying.
ᐧ
On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> You mean additional JWKS URIs, for example?
>
> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>
>
> Perhaps I am misunderstanding what Annabelle was getting at, but having
>
You mean additional JWKS URIs, for example?
> Am 10.01.2020 um 19:09 schrieb Dick Hardt :
>
>
> Perhaps I am misunderstanding what Annabelle was getting at, but having more
> than one key in the metadata document would solve the the issue. IE,
> extensions would define their own key instead
Perhaps I am misunderstanding what Annabelle was getting at, but having
more than one key in the metadata document would solve the the issue. IE,
extensions would define their own key instead of using the same one.
The metadata document itself was an extension.
On Fri, Jan 10, 2020 at 9:58 AM
> Am 10.01.2020 um 18:23 schrieb Dick Hardt :
>
> As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
> Provider, and the access token is being defined. These extensions have
> assumed all of this functionality is a monolith.
>
> I'm not suggesting that we MUST make changes
OAuth 1.0 assumed the RS and AS were a monolith.
OAuth 2.0 separated the RS and the AS. It put them in separate boxes. It
also did not define the access token, allowing an implementation to keep
them as a monolith, or allow separation of duties. There was no impact on
the client, but it was a
I would argue that the AS being monolithic, as seen by outside parties, is a
core assumption in OAuth 2. While there are deployments that, for example,
split the authorization and token endpoints into different domains and servers,
the client still sees them as a single entity.
I think it’s
+1 to this being a security consideration
— Justin
> On Jan 8, 2020, at 3:46 PM, Richard Backman, Annabelle
> wrote:
>
> I almost included text to that effect, but thought it was getting too wordy.
> However your suggestion is simple and concise. +1
>
> Given all of this discussion, we
Yes that is what it comes down to.
Is that a feature having a fixed set of parameters in the signed JAR and
some number of OAuth parameters unsigned outside the JAR, that people want
badly enough for us to pull the spec back and restart IESG review.
I think Torsten is speculating that is not a
This is an interesting point.
I think OAuth has historically assumed that the AS is a monolithic system, or
at least can be treated like one by clients. I think we might have to revisit
quite a lot if we drop this assumption and adopt a threat model in which the AS
is itself composed of a
But merge gives us the ability, which has been stated here before, to have a
fixed core set of parameters inside the JAR and a mixed set of variable
parameters outside the JAR.
What if by “merge” we really mean “you can’t repeat things in both places but
you can have fields in either”.
—
I just want to add that the requirement to validate the request at PAR the same
way as you would at the auth endpoint is something that I want to see relaxed,
and I hope it doesn’t make it through to the final standard.
Also keep in mind that this is barely started as a WG document so any
I haven't seen any real use of merge. It happens with Connect as a side
effect of OAuths current requirement to have some of the parameters outside
the JAR.
Nothing stops servers from ignoring parameters outside JAR or acting on
query parameters outside the JAR if they are not in the OAuth
+1
With the comment that there’s going to be a lot of coordination between this
and other components already in OAuth 2 (scope, resource, aud/audience, JAR
stuff) and anything that might come out of TxAuth. Those are two of my main
goals as co-author of this work.
— Justin
> On Jan 6, 2020,
I believe the IESG was incorrect in their review and what’s in the text now is
not what the WG agreed to.
Question is, what’s our next step, then?
— Justin
> On Jan 6, 2020, at 5:50 PM, John Bradley wrote:
>
> My take would be that any paramater in the OAuth registy is a OAuth
> paramater.
33 matches
Mail list logo
