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
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 that could be used in
the wrong way
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM)
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:
Thanks Mike!
Then lets take it to the next level :)
//Samuel
On Thu, Mar 10, 2016 at 12:33 PM, Mike Jones
wrote:
> Thanks for your comments, Samuel. Yes, you’re right that jwks_uri should
> be OPTIONAL, since not all use cases need keys. Likewise,
> registration_endpoint should be OPTIONAL,
I agree with Samuel's comments wrt jwks_uri and registration_endpoint; and
support the name change to “OAuth 2.0 Authorization Server Discovery
Metadata” (or possibly “OAuth 2.0 Authorization Server Discovery”; but I'd
rather narrow down the scope to only talk about metadata, without discovery
mech
Thanks for your comments, Samuel. Yes, you’re right that jwks_uri should be
OPTIONAL, since not all use cases need keys. Likewise, registration_endpoint
should be OPTIONAL, rather than RECOMMENDED.
The grant_type values are defined in OAuth Dynamic Client Registration [RFC
7591] and are ident
Hi all,
we would like to conclude this call for adoption.
Based on the feedback we would believe that this document should become
a working group document and thereby a starting point for further work.
We do, however, take the feedback from Mike Schwartz serious. He raises
a good point regarding
13 matches
Mail list logo
