Thanks for writing this up Dirk.
I would suggest that the token be:
payload "." envelope "." signature
This enables the payload to be encrypted and independent from the envelope.
Token signing, verification, encryption and decryption code can then be generic
and not understand the payload of the token.
I would only include issuer, key_id and alg in the envelope.
Audience, scope, nonce, and validation time information etc. would be in the
payload.
-- Dick
On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote:
> Hi guys,
>
> I think I owe the list a proposal for signatures.
>
> I wrote something down that liberally borrows ideas from Magic Signatures,
> SWT, and (even the name from) JSON Web Tokens.
>
> Here is a short document (called "JSON Tokens") that just explains how to
> sign something and verify the signature:
> http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4
>
> Here is an extension of JSON Tokens that can be used for signed OAuth tokens:
> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU
>
> Here is a different extension of JSON Tokens that can be used for 2-legged
> flows. The idea is that this could be used as a drop-in replacement for SAML
> assertions in the OAuth2 assertion flow:
> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
>
> I also have started to write some code to implement this as a
> proof-of-concept.
>
> Thoughts? Comments?
>
> Dirk.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
