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

nara hideki hdknr at ic-tact.co.jp
Tue Oct 5 19:42:36 UTC 2010


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
>
>


More information about the Openid-specs-ab mailing list