You can already sign arbitrary content using a body hash with the current spec.
— Justin > On Oct 24, 2016, at 8:38 AM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > > Maybe if we reworked the signing doc so content types like xml and json could > be signed? > > This would cover for the majority of web api cases. > > Wonder what the advice of the http wg would be on this. > > Phil > > On Oct 24, 2016, at 8:29 AM, Samuel Erdtman <sam...@erdtman.se > <mailto:sam...@erdtman.se>> wrote: > >> +1 on doing PoP work in this working group, including HTTP signing/MACing, I >> don´t think the old HTTP signature document was that far from useful. >> >> With the ACE work I like when it is possible to just map work done in the >> OAuth and other working groups to the more optimized protocols. Some would >> maybe say that it is sub-optimal that the protocol was not initially >> designed for the constrained environment but I think the benefit of concept >> validation from web is a bigger plus. >> >> //Samuel >> >> On Sat, Oct 22, 2016 at 7:47 PM, Justin Richer <jric...@mit.edu >> <mailto:jric...@mit.edu>> wrote: >> I believe that the PoP work should stay in the working group, and that >> without a usable presentation mechanism such as an HTTP message signature >> the whole work is pointless. I agree with Mike that we should learn from our >> own mistakes — and that is precisely the direction that the current HTTP >> signing draft took. As a result, the base level of functionality is signing >> the token itself (with a timestamp/nonce) using the key. All of the fiddly >> HTTP bits that trip people up? Not only are they optional, but it’s >> explicitly declared what’s covered. Why? Because we’re learning from past >> mistakes. >> >> I think that token binding is relying on a lot of “ifs” that aren’t real >> yet, and if those “ifs” become reality then it will be to the benefit of >> large internet companies over everyone else. Additionally, token binding in >> OAuth is far from the simple solution that it’s being sold as. The very >> nature of an access token goes against the original purpose of tying an >> artifact to a single presentation channel. OAuth clients in the real world >> need to be able to deal with multiple resource servers and dynamically >> deployed APIs, and the token binding protocol fundamentally assumes a world >> where two machines are talking directly to each other. >> >> All that said, this working group has consistently shown resistance to >> solving this problem for many years, so the results of this query don’t at >> all surprise me. >> >> — Justin >> >> > On Oct 19, 2016, at 11:45 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net >> > <mailto:hannes.tschofe...@gmx.net>> wrote: >> > >> > Hi all, >> > >> > two questions surfaced at the last IETF meeting, namely >> > >> > 1) Do we want to proceed with the symmetric implementation of PoP or, >> > alternatively, do we want to move it over to the ACE working group? >> > >> > 2) Do we want to continue the work on HTTP signing? >> > >> > We would appreciate your input on these two questions. >> > >> > Ciao >> > Hannes & Derek >> > >> > _______________________________________________ >> > 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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> 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
