[Specs-cx] Encryption

[nara hideki]

Thanks a lot, experts.

I've got the problem of compatibility of  the signature base string format.
I'd like to know other issues after the best signature base string
format will be taken as the standard.

Thanks in advance.
-----
hdknr

2010/7/6 David Recordon <recordond at gmail.com>:
> 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
>>
>>
>
>