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

John Bradley jbradley at mac.com
Tue Oct 5 16:36:10 UTC 2010


The advantage of wrapping the JSON to be signed inside of an element  is that we remove the possibility of namespace collisions.

The goal is to be able to sign any JSON not just oAuth tokens. 

It is also possible to have multiple signers.

If we flip it around we need to use a URI or some other mechanism to avoid collisions.  

I dont think reserving env as a element name will work other than in some special cases.

I agree that including the signature info in the signed token looks simpler.

John B.
On 2010-10-05, at 11:56 AM, Nat Sakimura 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101005/043e38d7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101005/043e38d7/attachment-0001.bin>


More information about the Openid-specs-ab mailing list