Brian, thanks for reading through the document and setting fire to the strawman
within.
Very good call on the hash inputs, I think you’re definitely right. I’m not
sure how best to handle that apart from some kind of out-of-band delimiter.
Maybe we should hash a dot-separated base64 encoded
Yeah, that kind of escaping really burned people in OAuth 1.0, and I’d like to
avoid it. One problem is that it’s hard to tell whether something’s been
escaped or not.
— Justin
On Jul 21, 2015, at 5:31 PM, John Bradley ve7...@ve7jtb.com wrote:
I was thinking that escaping would
... by Matias Woloski of Auth0. Check it out!
https://auth0.com/blog/2015/07/21/jwt-json-webtoken-logo/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Derek,
Just looking at the issue you mentioned earlier. I think you also wanted to add
in that a resource server A might be legitimately trying to re-use the token
with an unintended “audience”, resource server B. Correct?
If so, here is a possible amendment to the case in 3.1:
Original
A short status update: I have added another agenda item about the work
currently doing in the OpenID Foundation about token revocation. William
is going to give us an update and maybe there is some work for us in the
area since it could be useful beside OpenID Connect.
Ciao
Hannes
On 07/13/2015
Just use the token at your target API and see if it works. Your client’s going
to need to be able to get a new token if this one expires mid-session anyway,
so you’re not saving anything by doing an introspection request.
— Justin
On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com
I think I said, at the last meeting, that I would review
draft-ietf-oauth-signed-http-request, which was maybe foolish of me, but I
thought I should be timely and send something before the meeting tomorrow.
Even though the document isn't on the agenda.
Let me first say that I honestly don't know
