Rather than focus on headers and URL param signing, focus on specifying how content is signed in the context of PoP.
I think there might be a clearer path for example if we new that signing for application/json and application/xml worked well. As we’ve been discussing signing headers and URL params is theoretically do-able, but it probably has more limited use and would remain experimental. Phil @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Oct 24, 2016, at 1:06 PM, Justin Richer <jric...@mit.edu> wrote: > > 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 >> <mailto: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
