On 2010-09-25, at 7:52 PM, Eve Maler wrote:
It seems like you figured it out pretty quickly, given the message you sent
immediately after. :-)
Referencing another spec from the core spec using normative text is
effectively including it by reference. I meant that I'm sympathetic (+1) to
-1 to including a signature mechanism in OAuth2 core
+1 to OAuth2 being clear about how it can deliver a secret key (and algorithm
id etc) that can be used by a signature mechanism
Firstly -- a mechanism to sign HTTP requests would be great, but should not be
dependent on methods for users to
http://peoplesearch.in.telstra.com.au/peoplesearch/UserDetail.aspx?Employee
Number=3799878 James Manger
mailto:james.h.man...@team.telstra.com james.h.man...@team.telstra.com
Chief Technology Office - Telstra
Phone: +61 3 8649 2442
Mobile: +61 4 1754 1870
Web:
Mike,
A couple of comments on JWT: (I had to send something after accidentally
sending an empty message to the list ;-)
Section 4.1 Reserved claim names
There isn't a JSON integer type, just a number type.
The examples use a string value for exp, while I expected a number (I
expected
Did you intentionally decide not to support encrypting the token?
On 2010-09-23, at 5:22 PM, Mike Jones wrote:
Recognizing that there is substantial interest in representing sets of claims
in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token
(JWT) spec for that
I'd be open to a proposal for also supporting encryption. The draft was
intended to be a starting point for productive discussion - not a finished
product.
Your thoughts?
-- Mike
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent:
Don't put the signature information in the token, put it in a separate
component (an envelope) that describes how the token is either signed or
encrypted. See discussion from June:
http://www.ietf.org/mail-archive/web/oauth/current/msg03211.html
On 2010-09-26, at 9:20 PM, Mike Jones wrote:
