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.h...@oracle.com> Cc: oauth <oauth@ietf.org> 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 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) <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>: 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 <vladi...@connect2id.com<mailto:vladi...@connect2id.com>> 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 <roland.hedb...@umu.se><mailto:roland.hedb...@umu.se> 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 <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net> : 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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> — Roland ”Everybody should be quiet near a little stream and listen." >From ’Open House for Butterflies’ by Ruth Krauss _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d> -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6FVmdN7ad0YzoYKSNF%2fDO%2ffG2EF1haj5aOHiMid6UMI%3d> @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
