Then the sentence should not open extension points even for confidential
clients,
- by mention OIDC notice explicitly
- by allowing currently existing alternatives only (and prohibit new ones)
etc.
iPadから送信
> 2020/05/15 8:36、Aaron Parecki のメール:
>
>
>> There is no specific mechanism right now.
>
> There is no specific mechanism right now.
> But future developers won’t be able to read the reason why the extension
> point is given only for confidential clients.
This is not a compelling argument.
The current situation is that we know of a handful of threats and attacks,
we know that PKCE
I agree with Nov that obscuring the language in 9.7 would be a disservice to
developers.
The Security BCP, which has already going the WGLC, explicitly calls out the
use of nonce as part of the best practices. OAuth 2.1 should do no less.
The 9.7 language that Aaron proposed was the result of
Denis,
You are rehashing the same issues that you have already discussed on the
mailing list multiple times,
You could not get the WG to agree with your points, because the WG
believe that this issue is outside the scope of this document.
The best the chairs can do at this stage is to capture you
Hi Vittorio,
I am referring to the email you sent on April the 29 th which is copied
below.
1) You wrote:
/> targeting of access tokens/
Let me think about that a bit longer.
I acknowledge that the decision of including an audience has the
effect of letting the AS track when the
Hi Vittorio,
I raised the following question:
In the future, if additional parameters are included in the request,
will the "sub" claim necessarily be present in the access token ?
The answer to this question does not seem to be present in the draft.
Would you be able to provide an answe
Denis, the change you mentioned is basically a typo, which I did fix but
did not publish a new draft for- that doesn’t change the substance of the
consensus (and is something that will be fixed in the subsequent phases of
the process).
Whether the sub should be mandatory has been discussed for two
The current version of this draft is
"draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.
This means that comments sent later on on the list have not been
incorporated in this draft.
In particular, this one sent on April the 28 th:
*1) *The title of this spec. is:
JSON Web To
There is no specific mechanism right now.
But future developers won’t be able to read the reason why the extension point
is given only for confidential clients.
> On May 14, 2020, at 18:32, Torsten Lodderstedt
> wrote:
>
> Are you aware of any suitable mechanism? I’m asking since from my persp
Sure. That's possible.
https://tools.ietf.org/html/draft-ietf-oauth-rar-01#section-3.1 states
"The request parameter can be used to specify authorization
requirements in all places where the "scope" parameter is used for
the same purpose, examples include:
…
Access token requests as spe
Are you aware of any suitable mechanism? I’m asking since from my perspective
this clause is mainly intended to allow existing OpenID Connect deployments to
use nonce instead of PKCE in combination with OAuth 2.1. It’s a compromise. I
think we should not encourage others to invent their own OAut
RFC6749 allows scopes to be presented at the token endpoint for cases like
client credentials grants.
It's not clear how this could be achieved with the current RAR spec though
when a Client using Client Credentials wants to request fine grained access
using authorization_details. Or should this e
Hi,
Why not allowing public clients use "other suitable mechanisms” then?
OAuth WG can allow both type of clients do so, then OIDF will define nonce as
the alternative only for confidential clients.
> 2020/05/14 15:56、Torsten Lodderstedt
> のメール:
>
> Hi all,
>
> I would also like to thank ever
13 matches
Mail list logo
