A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : JWT Response for OAuth Token Introspection
Authors : Torsten Lodderstedt
Hi Filip,
In my understanding, duplication of request parameters outside of the request
object was necessary in the OIDC variant in order to retain OAuth compliance.
JAR as an OAuth extension will not require the client to duplicate OAuth
request parameters outside of the request object.
The
I can get by not having to have the minimum oauth request parameters, but the
current language does not imply that one can use the parameters if they’re not
present in the Request Object.
That derails JAR from its OIDC variant.
Odesláno z iPhonu
28. 8. 2019 v 10:48, Torsten Lodderstedt :
>
Hi Rhemco,
> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius
> wrote:
>
> Hello Thorsten,
>
> Thank you for your response. I have a few more questions/comments as
> follow-up...
>
> You state that RFC7519 and RFC7662 "just" define different representations
> for token data. If the dr
Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Pl
Mirja Kühlewind has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Plea
Thanks for the review and not objectionable ballot, Mirja.
I wasn't aware of Alexey's comment until I saw your message here and went
to the tracker
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ballot/
to find it. I think maybe an email got lost somewhere or didn't send or
Filip, for better or worse, I believe your assessment of the situation is
correct. I know of one AS that didn't choose which of the two to follow but
rather implemented a bit of a hybrid where it basically ignores everything
outside of the request object per JAR but also checks for and enforces the
Well it kind of blows, doesn't it? I wasn't able to find the "why" anywhere
in the mailing list archive around the time this was changed.
My take on satisfying both worlds looks like this
- allow just JAR - no other params when possible.
(which btw isn't possible to do with request_uri when e
It would be fine not allowing that across the board but rather through a
language like so
‘Authorization Servers MAY allow per-transaction parameters such as “state” and
“nonce” to be sent outside of the Request Object using regular OAuth 2.0
parameter syntax, the specific parameters are at the
FWIW, as best I can remember the change in question came as I result
of directorate/IESG
review rather than a WG decision/discussion. Which is likely why you can't
find the "why" anywhere in the mailing list archive.
On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan wrote:
> Well it kind of blows, do
11 matches
Mail list logo
