On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin
wrote:
> This is not discovery, its simply metadata, […], I don’t understand the
> rush to get this document out when we already know it’s incomplete
>
+1
___
OAuth mailing list
OAuth@ietf.org
https://www.
pbell
> ; John Bradley
> Cc: oauth
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
> We agreed upon a discovery specification that the WG would work on, we did
> not agree upon what this has turned out to actually be, so at the minimum the
incomplete
There are still documents from Nat, and I believe there will be one from Phil
and maybe others.
From: Mike Jones
Sent: Saturday, March 12, 2016 8:29 AM
To: Anthony Nadalin ; Brian Campbell
; John Bradley
Cc: oauth
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
The
.
-- Mike
From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones ; Brian Campbell
; John Bradley
Cc: oauth
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
We agreed upon a discovery specification that the WG would work on, we did not
agree
From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin ; Brian Campbell
; John Bradley
Cc: oauth
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
The draft enables easy configuration of OAuth clients with an AS. For
instance, the Microsoft “ADAL” OAuth
.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell ; John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Disagree, what purpose is this activity solving
March 11, 2016 3:59 PM
> *To:* Anthony Nadalin
> *Cc:* John Bradley ; oauth
>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> That *is* the scope of the current document, which a majority of folks
> have agreed with. I was reiterating
Sorry but not true, this started out as “discovery” and now it’s not
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 11, 2016 3:59 PM
To: Anthony Nadalin
Cc: John Bradley ; oauth
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
That *is* the
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley
>
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to)
, March 11, 2016 3:11 PM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
I tend to agree with John that addressing the concerns Phil raises should be
part of (extension to) the core protocol. And that those kinds of concerns
don't manife
estination
> in the first place and returned both dst and scope in the response all
> along, so this is update that is consistent with the eisting architecture
> of OAuth 2.
>
> Lets keep the two issues separate.
>
> John B.
>
>
>
>
> On Mar 11, 2016, at 12:07 AM, A
>> more token meta-data to the token response and that takes care of the
>> problem. Honestly we probably should have separated scope and destination
>> in the first place and returned both dst and scope in the response all
>> along, so this is update that is co
, March 10, 2016 9:09 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
I strongly oppose. 2 major issues.
This is not service discovery this is configuration lookup. The client must
have already discovered the oauth issuer uri and the
; Lets keep the two issues separate.
>
> John B.
>
>
>
>
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin wrote:
>>
>> The relationship between AS and RS need to be scoped to “does this RS accept
>> tokens from this AS” as a list is too much information t
unt (IDM)
> Cc: oauth
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
> Phil,
>
> Right. So what my conditional approvals (11 conditions in total) said was to
> drop the word "discovery" from everywhere. This is not a discovery spec. Th
I am strongly against requiring the AS to know about RS URIs and
managing that based on a client request for a token. I've stated my
reasons previously.
Happy to agree to disagree:)
Thanks,
George
On 3/10/16 10:17 PM, Phil Hunt (IDM) wrote:
Nat,
Agree with your points.
Regarding the last,
+1 for these changes and finishing the doc
On 3/10/16 10:45 AM, Nat Sakimura wrote:
+1 in proceeding with the following changes:
1. Change name to "*OAuth 2.0 Authorization Server Metadata*",
aligning with section 2.
2. Have the AS dictate the URI path suffix through link header in the
On 18 February 2016 at 14:40, Hannes Tschofenig
wrote:
> Hi all,
>
> This is a Last Call for comments on the OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 we
Nat,
Agree with your points.
Regarding the last, I am not sure an AS should release the set of valid rs's. I
think the returned data has to be limited somehow. Maybe by aud uri or maybe
just a yes/no to a uri the client provides. This needs discussion.
Am worried about the resource side disc
)
Cc: oauth
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Phil,
Right. So what my conditional approvals (11 conditions in total) said was to
drop the word "discovery" from everywhere. This is not a discovery spec. This
is a configuration lookup spec as you
Phil,
Right. So what my conditional approvals (11 conditions in total) said was
to drop the word "discovery" from everywhere. This is not a discovery spec.
This is a configuration lookup spec as you correctly points out. So, I am
with you here.
Also, my 2nd conditiion is essentially saying to dro
I strongly oppose. 2 major issues.
This is not service discovery this is configuration lookup. The client must
have already discovered the oauth issuer uri and the resource uri.
The objective was to provide a method to ensure the client has a valid set of
endpoints to prevent mitm of endpoint
I support the document moving forward, and agree with the proposal to
rename it to "OAuth 2.0 Authorization Server Discovery Metadata".
Personally I was fine with re-using 'openid-configuration' for
compatibility, but I suppose it's not a big burden for everyone who is
already using that to setup
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:
> +1
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg
> wrote:
>
>> I support this document being moved forward with these two changes:
>>
>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>> propos
+1 in proceeding with the following changes:
1. Change name to "*OAuth 2.0 Authorization Server Metadata*", aligning
with section 2.
2. Have the AS dictate the URI path suffix through link header in the
HEAD response to AS or OOB mechanism.
3. Align the title of section 3 to section
+1
On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg
wrote:
> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
I support this document being moved forward with these two changes:
- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of
’openid-configuration’ as proposed by Justin.
> 18 feb 2016 kl. 14:
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth@ietf.org
> *Subject:* Re: [
well-known/oauth-authorization-server”
> identifier, as discussed in that thread.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tsch
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
Hi,
I sent a few comments two weeks ago that has not been explicitly commented on.
(I might have sent them in the wrong way, if so sorry about that)
https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
Most
Hi,
I sent a few comments two weeks ago that has not been explicitly commented
on. (I might have sent them in the wrong way, if so sorry about that)
https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
Most of the comments are minor but I would like to se
jwks_uri to be change
Hi all,
This is a Last Call for comments on the OAuth 2.0 Discovery specification:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
Since this document was only adopted recently we are running this last
call for **3 weeks**.
Please have your comments in no later than March 10th.
Ciao
32 matches
Mail list logo
