<div dir="ltr"><div>Hi Anders,</div><div><br></div>The goal of 

<a href="https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05</a> is to ensure integrity on HTTP exchanges (i.e. on a request/response pair)<div><br></div><div>The main goal of this, as stated in the draft is to have a response to a request "<span style="color:rgb(0,0,0);font-size:13.3333px">treated as authoritative for that </span><span style="color:rgb(0,0,0);font-size:13.3333px">origin, even if it was transferred over a connection that isn't </span><span style="color:rgb(0,0,0);font-size:13.3333px">authoritative</span>" </div><div><br></div><div>In short, when you retrieve a response from a cache, you want to be sure that what was cached has not been tampered with</div><div><br></div><div>It's completely different from what we need to achieve in the context of FAPI, and more generally in the context of API security, where we're looking for single message itegrity (be they erquests or responses)</div><div><br></div><div>HTH,</div><div><br></div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 6:13 PM Anders Rundgren via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-03-13 17:25, Joseph Heenan via Openid-specs-fapi wrote:<br>
> I presume the interoperability issues are solvable one way or another?<br>
> <br>
> The early reports about OBUK’s signing algorithm seem to be cautiously pessimistic. I’m not sure if OB gave any reasons for not using the IETF cavage draft.<br>
> <br>
> I know we’ve discussed it before, but it does seem like the FAPI working group should try and favour one standard, which would also allow us to build interoperability/certification tests for that standard. I think the oauth working group feels similarly. Justin Richer pulled together some of the thoughts at IETF 101 ( <a href="https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessa-http-signing-00" rel="noreferrer" target="_blank">https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessa-http-signing-00</a> ) but I’m not sure if the conversation moved on from there.<br>
<br>
Hi Joseph,<br>
thank you for providing this information; it was news to me at least!<br>
<br>
If <a href="https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-05</a> would become "the" HTTP signature standard, we would be in big trouble. I can't even "decipher" it :-(<br>
<br>
BTW, where does the FAPI signature solution stand standards-wise?<br>
<a href="https://openid.net/specs/openid-financial-api-part-2.html#request" rel="noreferrer" target="_blank">https://openid.net/specs/openid-financial-api-part-2.html#request</a><br>
It is not obvious that the FAPI signature solution actually is RESTful; maybe I'm missing something here?<br>
<br>
Anders<br>
<br>
<br>
<br>
> <br>
> Perhaps it’s one to put on the agenda for the oauth security workshop face-to-face?<br>
> <br>
> Joseph<br>
> <br>
> <br>
<br>
<br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div>