On Wed, Oct 23, 2019 at 2:11 PM Brian Campbell
wrote:
> I agree with Ben here that it's not at all clear that the OAuth MTLS document
> should have defined a protocol from proxy to backend.
Shouldn't it at least normalitvely reference some other spec then? If
that reference is not defined
On Fri, Oct 25, 2019 at 10:02:41AM -0400, Rifaat Shekh-Yusef wrote:
> You might want to look at RFC7239, which is trying to address the issue of
> the loss of information by proxies.
> https://tools.ietf.org/html/rfc7239
>
> The document does not have a parameter to carry the client certificate
>
You might want to look at RFC7239, which is trying to address the issue of
the loss of information by proxies.
https://tools.ietf.org/html/rfc7239
The document does not have a parameter to carry the client certificate
information, but it allows for new parameters to be defined.
Would that help
On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote:
>I also agree. Would it be possible to get this pushed to http or tls? It
>would be more appropriate there, and very helpful to have a general spec
>for this.
I think it's possible to get such work done in one of those
I also agree. Would it be possible to get this pushed to http or tls? It would
be more appropriate there, and very helpful to have a general spec for this.
— Justin
On Oct 23, 2019, at 2:10 PM, Brian Campbell
mailto:bcampbell=40pingidentity@dmarc.ietf.org>>
wrote:
I agree with Ben here
I agree with Ben here that it's not at all clear that the OAuth MTLS
document should have defined a protocol from proxy to backend. I'd go so
far as to say it's well outside the scope of the document and even the
working group. Admittedly It would be nice if such a thing existed but it
would have
Just on one narrow point:
On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote:
> On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
> > Open: How would one implement sender constrained access tokens in that
> > case? I’m asking since the receiving RS obviously has no access to the
>
On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt
wrote:
> Hi Travis,
Hey there, Torsten. Sorry for the slow reply. Still jet lagged ;-)
> > On 26. Sep 2019, at 11:26, Travis Spencer wrote:
> Do others have an opinion about this?
https://tools.ietf.org/html/rfc7322#section-3.6
> > * Instead
Hi Travis,
thanks for your feedback!
> On 26. Sep 2019, at 11:26, Travis Spencer wrote:
>
> Some feedback on this draft compared to the last one that I read:
>
> * The acronym RS and the term "resource server" are used
> inconsistently. It would read better IMO if the acronym was always
>
I stand with Ben’s contention that introspection should be about getting
information :about: a token, and not about getting a new token. In fact, this
was one of the core issues that I had with the draft as originally proposed.
If there are problems with token exchange, they should be fixed
On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk wrote:
> On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
> > * Last but certainly not least is the restriction that the current
> > version places on disallowing of the introspection JWT response as an
> > access token. This is done
On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
> * Last but certainly not least is the restriction that the current
> version places on disallowing of the introspection JWT response as an
> access token. This is done in numerous places (the note in section 5,
> 8.1, etc.). I
Some feedback on this draft compared to the last one that I read:
* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this
Hi Vladimir,
> On 24. Sep 2019, at 08:03, Vladimir Dzhuvinov wrote:
>
> When implementing 08 a question came up:
>
> * The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"].
>
> * The RS "rs1" is in the expected audience.
>
> Are there any considerations (privacy, etc) about
When implementing 08 a question came up:
* The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"].
* The RS "rs1" is in the expected audience.
Are there any considerations (privacy, etc) about returning the full
audience list ["rs1", "rs2", "rs3"] in the introspection response?
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
16 matches
Mail list logo
