[Openid-specs-ab] signing

Nat Sakimura sakimura at gmail.com
Mon Nov 1 11:57:07 UTC 2010

John and Mike, 

(Added specs-ab in the distribution)

To allow multiple signatures, we made both signature parameters (envelope parameters) and signatures both arrays.  So, jwt-env needs to be an array also, I suppose.

We have added types based on the feedback from a few developers that they want to switch the routines based on them. It is not only for JSS and JSE but consistent throughout Artifact Binding. We are actually typing the JSON object explicitly so that we can validate as well. Including it inside env breaks this pattern. This is one of the drawback in including it within the env. 

We did not add types in the JWT serialization because we assumed that the main use cases are in the HTTP headers and HTTP header has a standard mechanism to indicate them. When JSON is stored in a file system, we do not have such an mechanism. Thus, we have added these in the JSON serialization. 

The other drawback is that in case of multiple signatures, it will be verbose. We have only one data, so we do not need to repeat the types in each element of the env array. 

Considering all these, I feel that having types outside the jwt-env is a better design. 

=nat via iPad

On 2010/10/27, at 8:05, John Bradley <jbradley at mac.com> wrote:

> This is a example JSON serialized token
> {
>     "type": "http://openid.net/specs/ab/1.0#jss",
>     "data_type": "application/json",
>     "data": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0",
>     "sig_params": [
>         {
>             "key_id": "example.com",
>             "algorithm": "HMAC-SHA256"
>         }
>     ],
>     "sigs": [
>         "cfXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso"
>     ]
> }
> The main difference is that we have two types one for the signed object and a separate one for the container.
> If we allow things other than JWT claims envelopes to be signed then you windup overloading the singe type element.
> We have a single payload, the data element that is the base64 encoded string of the JSON object.  
> You were more specific about converting it to UTF8 first.  Good idea. 
> I have the sig parameters nested because that is cleaner for dealing with multiple signatures. 
> The JSON  serialization is very close to the base64 one.
> I suppose we could do something like:
> {
>  "jwt-env": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2F",
>  "jwt-data":"eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2F",
>  "jwt-sigs": [ "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2F" ]
> }
> It is harder to read and to edit the envelope info for adding a sig but is consistent with the other serialization.
> John B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101101/d2674e61/attachment.html>

More information about the Openid-specs-ab mailing list