On #1, I know some have pushed for having the transformation options so I
don't know if dropping it will work. But, if not removed entirely, the
transformation stuff could definitely be deemphasized in favor of what will
be the most common case of the client sending a random string value on the
Hi James and Brian,
First, I apologize for taking a long time to respond to James.
My responses inline:
2014-09-03 2:49 GMT+09:00 Brian Campbell bcampb...@pingidentity.com:
On #1, I know some have pushed for having the transformation options so I
don't know if dropping it will work. But, if
I don't think the inclusion of a MAC transform to protect the request is
necessary for it to be called proof of possession.
The other way to protect the request is with a signed/encrypted request object.
That is heaver weight than the HMAC transform.
I may have come up with the trick of
I support the use of public key. As I remember, our discussion started
there.
I still believe this is something that is needed to be standardized.
However, for spop use case, we have determined that is overkill and best
left for another draft.
It looks like there is a strong support in the
Couple of comments on draft-ietf-oauth-spop-00:
The draft defines a nice little mechanism to link two requests: one from
app-to-browser-to-server, the other from app-to-server.
1.
The spec defines the bearer token version of linking the requests: pick a
random value and send it in both
