Hi Mike
That answer makes the most sense to me as those values are often required when
processing a payload as well, and they should be consistent. I'd be interested
to hear any other opinions though!
-- Dick
On May 1, 2013, at 3:48 PM, Mike Jones wrote:
> Thanks for writing this, Dick. I t
Thanks for writing this, Dick. I think I understand your requirements and why
they exist.
One question you didn't answer that will come up is whether these fields must
also be present in the JWT claims set if they're present in the JWE header.
The logical answer to me seems to be something li
"iss" and "aud" would be optional parameters in a JWE. These parameters are in
the payload, but since it is encrypted, the payload must be decrypted before
they can be read. Some times knowing these parameters is required to be able to
decrypt the payload …
These would be additions to 9.3.1 in
I just rev'd the OAuth Introspection draft to cover some of the issues
outstanding, such as alignment with JWT claim types, fields for token
types (copied from revocation), and TLS restrictions.
-- Justin
Original Message
Subject: New Version Notification for
draft-richer
I find the text confusing regarding client auth.
>> "A client MAY use the "client_id" request parameter to identify itself
>> when sending requests to the token endpoint"
It seems to suggest client auth is optional due to the MAY when in fact it is
just referring to the client_id identifier whi
Just trying to close the loop on this thread (six weeks later, sorry). New
drafts were published last month that (hopefully) have more clear text
about the treatment of client_id. And it's been removed from examples where
it's optional.
http://www.ietf.org/mail-archive/web/oauth/current/msg11213.h
