I'm not personally convinced that it's possible to boil it down to
"domain checking". That said, we probably should start a new thread with
use cases:)
On 3/17/16 12:34 PM, Phil Hunt wrote:
+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 <http://example.com>. It
presumes there are no open redirect servers in the example.com
<http://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
<mailto: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/v2/userinfo
https://example.org/some/api/endpoint
etc., then the AS may provide
https://example.com/apis/
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]*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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
