A couple of advantages of separating: 1) everything but the envelope data (key_id, signer, algorithm) gets encrypted
2) if the encrypted data is an object in the JSON, then it has been base64 encoded, and then gets base64 encoded again. Much more efficient to include the base64 encoded binary of the encrypted data as a separate field (this is what motivated me to this separation to begin with -- Dick On Mon, Jun 21, 2010 at 10:54 AM, Justin Smith <justi...@microsoft.com>wrote: > I'm not emphatic about either, but my vote is to remove the envelope. > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Brian Eaton > Sent: Monday, June 21, 2010 9:49 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures > > On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > > 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 think you can still do that even if payload and envelope are combined. > > the signed json would become: > > { > signer: <whoever-signed> > encrypted_for: <intended-destination> > encrypted_payload: <the-encrypted-payload> } > _______________________________________________ > 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
