+1 for Nat's last few emails (avoiding generating too much traffic :-). Re: below, this is where I was thinking of masking/filter in bound config. The main thing that needs to be checked at configuration time is whether the client has a valid set of server host names to prevent a malicious proxy.
So all the examples you mention below do boil down to https://example.org or https://example.com It’s not that the AS needs to return them. It simply needs to match them. If one of them matches, then the oauth config can be returned. I do agree re-directs (of the ESPN scenario) can become an issue if a discovery system matches on *.example.com. It presumes there are no open redirect servers in the example.com domain. As I mention in another email, we should discuss what happens when any oauth connection is redirected. Should the client re-validate the configuration? Phil @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Mar 16, 2016, at 11:42 PM, Nat Sakimura <n-sakim...@nri.co.jp> wrote: > > IMHO, list of URIs that represent the partial paths under the same authority > would not be too onerous. <> > > e.g., if you have > > https://example.com/apis/v1/userinfo <https://example.com/apis/v1/userinfo> > https://example.com/apis/v2/userinfo <https://example.com/apis/v2/userinfo> > https://example.org/some/api/endpoint <https://example.org/some/api/endpoint> > > etc., then the AS may provide > > https://example.com/apis/ <https://example.com/apis/> > https://example.org/ <https://example.org/> > > or something like that in the audiences. > > A completely new domain should not be trusted blindly. > The resource should at least make sure to provide the domain as being under > the same authority. > > Bearer Token is a Password. It should not be shared among different > authorities. > > Best, > > Nat > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of George Fletcher > Sent: Wednesday, March 16, 2016 3:15 AM > To: John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>; Brian > Campbell <bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>> > Cc: <oauth@ietf.org <mailto:oauth@ietf.org>> <oauth@ietf.org > <mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-bound-config-00.txt > > (..snip..) > > I'm not sure passing the full endpoint to the AS will help with my > concerns... The AS could potentially do a webfinger on the resource URI and > determine if it's an RS that it supports... though that requires all RS's to > support webfinger. What I really want to avoid is the AS having this list of > URIs to RS that is almost assuredly to get out of sync. > > > (..snip..) > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
