[Specs-cx] Encryption

John Bradley john.bradley at wingaa.com
Mon Jul 5 23:17:43 UTC 2010


We specified base64url encoding of the encrypted message as a single string, to be consistent with Google magic signature.

There are a couple of extra options you need for encryption with asymmetric keys,  but other than that it is consistent with JSON magic signature.

That may or may not be a good thing.

John B.
On 2010-07-05, at 6:08 PM, David Recordon wrote:

> Have you done work around how the JSON payload is sent over the wire from an encoding perspective? There's a debate about this on the OAuth 2 list right now as we're looking at using JSON envelopes for signatures.
> 
> Thanks,
> --David
> 
> 
> On Mon, Jul 5, 2010 at 9:01 PM, nara hideki <hdknr at ic-tact.co.jp> wrote:
> Hi, David,
> 
> Let me know what you mentioned more precisely.
> We're using JSON Encryption Envelop to exchange privacy data.
> (Spec is here :
> http://bitbucket.org/Nat/jsonenc/src/tip/draft-sakimura-jsonenc-00.txt
> )
> It encrypt shared key in public key encryption and the payload
> of canonicalized JSON string is encrypted with that shared key.
> 
> I think if those shared key is known, the payloads can be decrypted.
> You might have talked about other security issues which I'm missing.
> 
> Best regards.
> ---
> hdknr
> 
> 
> 2010/6/28 David García <david.garcia at tractis.com>:
> > Hi Nat,
> >
> > in those cases where public keys cannot be used, because parties are not
> > known yet, maybe using PBE (password based encryption) with random generated
> > pass could fit this need.
> > Those passwords could be stored bound to the contract and delivered to the
> > party after a challenge has been passed (f.ex auth process).
> >
> > Best regards
> >
> > Dave
> >
> > 2010/6/25 Nat Sakimura <sakimura at gmail.com>
> >>
> >> I had a talk with Hide yesterday.
> >> We were talking on how to preserve the privacy of the end user among
> >> bunch of services.
> >>
> >> The agreement we had was that we should encrypt the portion of the
> >> agreement specific to each server with different symmetric keys, then
> >> encrypt the symmetric keys with respective server's public key and
> >> OP's public key.
> >>
> >> We are still discussing over the cases where parties are not
> >> determined at the time of the proposal and disclosing the parties to
> >> other parties are privacy risk.
> >> It is a bit challenging.
> >>
> >> --
> >> Nat Sakimura (=nat)
> >> http://www.sakimura.org/en/
> >> http://twitter.com/_nat_en
> >> _______________________________________________
> >> Specs-cx mailing list
> >> Specs-cx at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-cx
> >
> >
> >
> > --
> > David Garcia
> > CTO
> > Tractis - Online contracts you can enforce
> > http://www.tractis.com
> > --
> > Email: david.garcia at tractis.com
> > Skype: deiffbcn
> > Blog: http://blog.negonation.com
> > Linkedin: http://www.linkedin.com/in/davebcn
> >
> >
> >
> > _______________________________________________
> > Specs-cx mailing list
> > Specs-cx at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-cx
> >
> >
> _______________________________________________
> Specs-cx mailing list
> Specs-cx at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-cx
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20100705/f0e0a8d5/attachment.html>


More information about the Specs-cx mailing list