Post by Justin RicherThe reason that thereâs a lot of discussion on headers and query
parameters and not a lot of discussion on the content is that thereâs
nothing special for signing the body whether itâs XML or JSON or HTML: itâs
just a hash of the entity body, sent as the âbâ parameter in the JWS. The
body is less likely to be transformed than the headers or parameters, and
getting into âhow to sign XMLâ or âhow to sign JSONâ beyond âjust take the
body as a byte array and hash itâ is problematic. I donât think we want to
get into the business of normalization or canonicalization of the message
body.
Keep in mind that this is all for the HTTP *request* from the client and
not the HTTP *response* from the RS.
â Justin
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
You can already sign arbitrary content using a body hash with the current spec.
â Justin
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
+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
Post by Justin RicherI 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 <
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth