2.3 should be removed from RFC6750. There is no reason to do it now. When we started the work, there was a lot of feature phones with no capability to do header, but it has been 6 years now and they have largely disappeared.
2016年3月18日(金) 18:56 John Bradley <ve7...@ve7jtb.com>: > RFC 6750 Sec 2.3. > > I wish clients used the header, the reality is that the majority of > client developers use a query paramater because it is easy. > > Form encoding is also allowed. > > If the RS has user hosted content the web server may helpfully make the > headder available anyway to the web page. > > Query is the worst. In those cases the token will leak if someone gets at > the HTTP logs. > > This is one of the reasons a specific audiance in the token is important > to limit the loss if a RS is compromised. > > John B. > On Mar 17, 2016 11:56 PM, "Nat Sakimura" <sakim...@gmail.com> wrote: > >> We are talking about resource accesses here, right? There's no query >> parameter from the point of view of OAuth: the access token is sent as >> Authorize header over TLS, so I am a bit puzzled by your comment... >> >> Nat >> >> 2016年3月18日(金) 2:49 John Bradley <ve7...@ve7jtb.com>: >> >>> It is not just redirects that are a threat. Any user hosted content >>> could potentially extract an access token from a query parameter. >>> >>> John B. >>> >>> On Mar 17, 2016, at 1:34 PM, Phil Hunt <phil.h...@oracle.com> 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. 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 >>> 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/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 <oauth-boun...@ietf.org>] *On >>> Behalf Of *George Fletcher >>> *Sent:* Wednesday, March 16, 2016 3:15 AM >>> *To:* John Bradley <ve7...@ve7jtb.com>; Brian Campbell < >>> bcampb...@pingidentity.com> >>> *Cc:* <oauth@ietf.org> <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 >>> 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
