The JOSE -26 and JWT -20 drafts address a few editorial issues recently
identified by reviewers, hopefully further clarifying these aspects of the
specifications. No normative changes were made.
See the Document History entries for details on the specific changes made.
The specifications are a
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : JSON Web Token (JWT)
Authors : Michael B. Jones
John Bradley
The "jwks" meta-data parameter may also be required for some of the Proof of
Possession flows. Allowing a client to register its public key is important
for reducing the number of long term symetric keys that need to be maintained.
On Apr 30, 2014, at 5:15 PM, Brian Campbell wrote:
> As Mike
Somewhat related is the client_secret_expires_at parameter. It seems a
little odd to have that in this protocol that offers no way to deal with
the expiration other than a completely new reregistration. It also seems
like it should be more general than just the expiration of the secret and
apply to
As Mike and Torsten have said, and for the same reasons, I would also like
to see the "jwks" metadata parameter added.
On Sun, Apr 20, 2014 at 4:14 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi all,
>
> I also believe both documents should be merged.
>
> Nevertheless, here are
I agree with Mike's point about flexibility. If OpenID Connect expects JWT and
specific claim semantics, that makes sense in the context of its use case, but
there are lots of other choices that can be made. For example, UMA's MTI token
profile* defines a mechanism for conveying JSON-formatted p
