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 <sakim...@gmail.com> 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) <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> >>> 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> >>>> 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 >>>>>> : >>>>>> >>>>>> 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 >>>>>> OAuth@ietf.org >>>>>> 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 >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
