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, 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 discovery and how much we can
intrude here. It may have similar issues disclosing approved ASs.
Finally since we might not control rs discovery it may be possible
that the discovery is fake. Maybe this is where something like
software statements comes into play as it would at least prevent a
mitm from changing the assertions in its discovery. It would not have
the RS's private key and this signed statements might build trust.
Phil
On Mar 10, 2016, at 18:24, Nat Sakimura <[email protected]
<mailto:[email protected]>> wrote:
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 drop section 3.
One thing that I overlooked and am with you is that we need to be
able to express the AS-RS relationships. I have been preaching this
in the other thread for so many times as you know so I thought I
pointed it out, but missed apparently in my previous comment. So, I
would add my 12th condition:
12. A way to express a list of valid RSs for this AS needs to be
added to section 2.
Best,
Nat
2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <[email protected]
<mailto:[email protected]>>:
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 endpoints like the
token endpoint to the resource server.
The draft does not address the issue of a client being given a
bad endpoint for an rs. What we end up with is a promiscuous
authz service giving out tokens to an unwitting client.
Phil
On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov
<[email protected] <mailto:[email protected]>> wrote:
+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<[email protected]>
<mailto:[email protected]>
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
’openid-configuration’ as proposed by Justin.
18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <[email protected]
<mailto:[email protected]>
:
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
Hannes & Derek
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
— Roland
”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
