[Specs-cx] Encryption

[David Recordon]

Yeah, take a look at the thread which starts with
http://www.ietf.org/mail-archive/web/oauth/current/msg03289.html around
base64url versus just url encoded. We're not finding base64url
implementations across platforms which means that you're doing string
replace or url encoding anyway. :-\


On Mon, Jul 5, 2010 at 4:17 PM, John Bradley <john.bradley at wingaa.com>wrote:

> 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/40aa6876/attachment.html>