There is also existing software that expects to be able to act/respond based
only on the WWW-Authenticate header. See
https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header)
> On Jul 20, 2018, at 2:33 AM, n-sakimura wrote:
>
> I did not quite follow why CORS is relevant here. We are just talking about
> the client to server communication, and there are no embedded resources in
> the response. Could you kindly elaborate a little, please?
Sure! It is
Hi all,
after several discussions we believe that we now have a proposal for moving
forward on this topic.
We plan to update the expired draft
and
(1) remove the audience parameter and replace it with a separately-specified
resource parameter,
(2) remove the alg parameter,
(3) update the
There are a few places where multiple resources could be used:
One is in the code flow where it is desirable to optimize the user
experience so that the user is granting authorization once, and not
multiple times.
The second is in the access token request, which leads to the third
instance,
As far as I can tell, there has been no response to this. The document
revision just updated a reference to reflect an rfc having been published.
Apologies if I missed a response.
RjS
On 6/11/18 12:20 PM, Robert Sparks wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits
I am the
I +1 this,
but at the same time, I'm wondering what happened with the argument that
this should be solved by Token Exchange instead of Introspect?
Cheers!
Mark
On 20/07/18 17:39, Phil Hunt wrote:
> +1 adoption
>
> I have always been concerned about clients doing introspection. Use of
> jwt
+1 adoption
I have always been concerned about clients doing introspection. Use of jwt
helps because responses further restricted rather than less (jwe).
Phil
> On Jul 20, 2018, at 7:25 AM, Rob Otto
> wrote:
>
> I support this as well
>
>> On Fri, 20 Jul 2018 at 15:22, Brian Campbell
>>
While I agree that a single requested resource is the common case, enough
people have spoken up with a need for multiple requested resources over the
years that I think everyone will be better served by leaving the ability to
specify multiple requested resources in the specification.
I support this as well
On Fri, 20 Jul 2018 at 15:22, Brian Campbell wrote:
> +1
>
> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <
> wdenniss=40google@dmarc.ietf.org> wrote:
>
>> I support adoption of this document by the working group.
>>
>>
>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat
+1
On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <
wdenniss=40google@dmarc.ietf.org> wrote:
> I support adoption of this document by the working group.
>
>
> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <
> rifaat.i...@gmail.com> wrote:
>
>> Hi all,
>>
>> This is the call for
> Am 20.07.2018 um 16:06 schrieb Anthony Nadalin
> :
>
> I’m concerned over the security implications of a client being able to
> introspect a token, for bearer tokens this can be very problematic, so unless
> the issues with possible token theft can be addressed I don’t support this as
> a
The current draft does allow multiple "resource" parameters. However, there
seemed to be consensus in the WG meeting yesterday that only a single
"resource" parameter was preferable and that a client could obtain an
access token per resource (likely using a refresh token). I'm personally
I am in favor of adoption.
Sent from Mail for Windows 10
From: Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 1:44 PM
To: oauth
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth
TokenIntrospection"
Hi all,
This is the call for adoption of the 'JWT Response for OAuth Token
I’m concerned over the security implications of a client being able to
introspect a token, for bearer tokens this can be very problematic, so unless
the issues with possible token theft can be addressed I don’t support this as a
WG draft
From: OAuth On Behalf Of Rifaat Shekh-Yusef
Sent:
Hi David,
Thanks for the comment, and sorry for the delay in my reply.
Doing it with Web Linking [RFC8288] has several advantages.
1. It is standard based ☺ It is just a matter of registering link relations
to the IANA Link Relation Type Registry, and it is quite widely used.
2. No or
Hi Torsten,
> Multiple "resource" parameters may be used to indicate that the issued
token is intended to be used at multiple resource servers.
That's already in. Furthermore what about logical names for target
services? Like was added in -03 of token exchange?
Best,
*Filip Skokan*
On Fri,
I support adoption of this document.
I would like to point out (again) a single resource is not sufficient for most
use cases I implemented in the last couple if years. I‘m advocating for
enhancing the draft to support multiple resources and a clear definition of the
relationship between
+1
> Am 20.07.2018 um 08:21 schrieb n-sakimura :
>
> And if it were not obvious, YES J
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
> Sent: Friday, July 20, 2018 6:12 AM
> To: Rifaat Shekh-Yusef
> Cc: oauth
> Subject: Re: [OAUTH-WG] Call for adoption for
And if it were not obvious, YES ☺
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, July 20, 2018 6:12 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"
I'm supportive. :)
On Thu, Jul 19, 2018 at 4:05 PM,
+1
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth
2.0"
I support adoption of this document.
On Thu, Jul 19, 2018 at 4:01
20 matches
Mail list logo
