We should not be prescriptive about how the AS recognizes request URIs from itself. Trusted authority or custom URI scheme are fine as examples, but ultimately this is an internal implementation of the AS. It could just as easily be using data URIs containing a symmetrically encrypted database record ID.
> On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > > On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote: >> The mitigations of 10.4.1 are related, but the section heading is about >> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF >> attacks too or else add another section with similar mitigations. >> >> Mitigation (a) is a bit vague as to what an "unexpected location" is. >> Perhaps specific wording that it should be a URI that has been >> pre-registered for the client (and validated at that time) or is otherwise >> known to be safe (e.g., is a URI scheme controlled by the AS itself as with >> PAR). > > pedantic nit: "URI scheme" is probably not what we want, as the authority > component of the URI (per RFC 3986) seems more likely to match "controlled > by the AS itself" > > -Ben > >> In addition for this to be effective the AS should not follow redirects when >> fetching the URI. It's not clear to me whether that is implied by "not >> perform recursive GET" so it may be worth explicitly spelling that out. >> > > _______________________________________________ > 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
