[Openid-specs-ab] The other JSS envelope structure

nara hideki hdknr at ic-tact.co.jp
Tue Oct 5 21:15:12 UTC 2010


Thanks John,

I might misunderstood something, but there doesn't  seems to be
namespace collision because the whole (root) JSON object
including envelope JSON object is to be canonicalized in base64url
format and set to "data" in JSON Serialization.

I'd like to know the reason why  envelope JSON MUST not be included in
signature base string.

Regards

----
hdknr


2010/10/6 John Bradley <jbradley at mac.com>:
> True, but we still have the problem of conflicting with elements in the object that we are trying to sign.
>
> It is also harder to recover the original object at the end of the process if you don't keep it separate.
>
> I see this as an enveloping signature where the original JSON is contained in a single element and can be easily extracted.
>
> You are going for more of an enveloped style where the signature elements become part of the object.
>
> If we weren't forced to base64 the entire thing for calculating the signature over I would probably favour your method.
>
> It would allow for you to receive an object and ignore the sig if you don't care about it.
>
> We cant do that in this case because the receiver must always unwrap the base64 encoding.
>
> So the most you can get out of the enveloped signature method is that after you receive JSON object and extract the encoded JSON object you have almost the object that you had when you started the signing process.
>
> In the Enveloping signature method you still need to extract the JSON form the payload.   The advantage is what goes in comes out, and there are no namespace issues.
>
> I am not super attached to the idea, but that is my reasoning.
>
> John B.
> On 2010-10-05, at 3:42 PM, nara hideki wrote:
>
>> John, Nat , Thank you for your description.
>>
>> For multiple signers, this may work as well:
>>
>> {
>>     "param1" : "xxxxx",
>>     "param2" : "xxxxx",
>>      ....
>>     "env1":  {
>>            "type": "http://jsonenc.info/jss/",
>>             "key_id": "signer1.com",
>>             "algorithm": "HMAC-SHA256"
>>              ...
>>      },
>>     "env2":  {
>>            "type": "http://jsonenc.info/jss/",
>>             "key_id": "signer2.com",
>>             "algorithm": "HMAC-SHA256"
>>              ...
>>      },
>> }
>>
>> In the above implementation, "env1" and "env2" can be used as
>> identifiers(indexer) for signature
>> in JSON Serialization later.
>>
>>
>> For arbitrary binary enveloping,  we can freely put any base64url-ed
>> string in JSON fields anyway.
>> For simplicity, I think that JSS should target on only JSON.
>>
>> ----
>> hdknr
>>
>> 2010/10/6 Nat Sakimura <sakimura at gmail.com>:
>>> There actually was another reason for having "payload" as a parameter.
>>> As a generic signature mechanism, we may want to sign arbitrary binary
>>> data.
>>> In such a case, we can base64url encode it and put it into "payload"
>>> parameter.
>>> =nat
>>>
>>> On Wed, Oct 6, 2010 at 12:56 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>>>>
>>>> In this example:
>>>> {
>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>    "not_after": 12345678,
>>>>    "user_id": 1223,
>>>>    "profile_id": 1223 ,
>>>>    "env" :
>>>>    {
>>>>        "type": "http://jsonenc.info/jss/",
>>>>        "sig_params": [
>>>>            {
>>>>                "key_id": "example.com",
>>>>                "algorithm": "HMAC-SHA256"
>>>>            }
>>>>        ]
>>>>    }
>>>> }
>>>> I do not think we need env. That would simplify.
>>>> The reason why we put everything inside the payload was that we thought it
>>>> would be easier to process. I am open to both ways.
>>>> What do others think?
>>>> =nat
>>>> On Wed, Oct 6, 2010 at 12:40 AM, nara hideki <hdknr at ic-tact.co.jp> wrote:
>>>>>
>>>>> Hi, Nat,
>>>>>
>>>>> This revision of envelope is literally "envelope" in which parameters
>>>>> in concern are held as JSON object in "payload".
>>>>> But it looks more simpler to me if all signing parameters are held as
>>>>> a JSON object in the concerned data.  I mean that the following sample
>>>>> :
>>>>>
>>>>> {
>>>>>    "type": "http://jsonenc.info/jss/",
>>>>>    "sig_params": [
>>>>>        {
>>>>>            "key_id": "example.com",
>>>>>            "algorithm": "HMAC-SHA256"
>>>>>        }
>>>>>    ],
>>>>>    "payload": {
>>>>>        "oauth_token": "asdfjklsdfjwoIjfk",
>>>>>        "not_after": 12345678,
>>>>>        "user_id": 1223,
>>>>>        "profile_id": 1223
>>>>>    }
>>>>> }
>>>>>
>>>>> can be simplified in this JSON:
>>>>>
>>>>> {
>>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>>    "not_after": 12345678,
>>>>>    "user_id": 1223,
>>>>>    "profile_id": 1223 ,
>>>>>    "env" :
>>>>>    {
>>>>>        "type": "http://jsonenc.info/jss/",
>>>>>        "sig_params": [
>>>>>            {
>>>>>                "key_id": "example.com",
>>>>>                "algorithm": "HMAC-SHA256"
>>>>>            }
>>>>>        ]
>>>>>    }
>>>>> }
>>>>>
>>>>> because if the original parameters without a signature can be following :
>>>>>
>>>>> {
>>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>>    "not_after": 12345678,
>>>>>    "user_id": 1223,
>>>>>    "profile_id": 1223
>>>>> }
>>>>>
>>>>>> From the programming effort's point of view, it doesn't make any
>>>>> difference.
>>>>> But JSON text looks simpler.
>>>>>
>>>>> We don't have to define holding parameter name as "env" because JSS
>>>>> JSON object MUST have
>>>>> "type". In Python, this code can be tell whether a JSON is JSS-envloped
>>>>> or not:
>>>>>
>>>>>>>> j=simplejson.loads( source_json_text )
>>>>>>>> True in [  type(v)==dict and v.has_key('type') and v['type'] ==
>>>>>>>> "http://jsonenc.info/jss/" for k,v in j.iteritems()]
>>>>> True
>>>>>
>>>>> A drawback is a fact that "env" dosen't look literally an envelope.
>>>>>
>>>>> ---
>>>>> hideki
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>> http://twitter.com/_nat_en
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


More information about the Openid-specs-ab mailing list