Re: [woes] Proposed charter, post-Quebec edition

[Phillip Hallam-Baker <[e-mail]>]

Since we are doing encryption as well, there are two problems needing a
common solution.


Let us say we are encrypting a blob of data - 200K or so. Do we really want
to have a JSON structure with the data blob JSON encoded?

For that and for the signing case I think we are going to want a structure
that is something like:

Package
    [Type=JSON Length=203 bytes]
        <Encryption stuff>
    [ID=2as9uas9u9 Length=293939933 bytes]
        <Binary blob>

Ascii encoding for control data is good, it helps debugging etc. But Ascii
encoding JPEG bytes does not really help me much.

The package could even be as simple as a JSON control block that gives the
length of a data blob that is to follow immediately.


On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[e-mail]> wrote:

> XPath is NOT the way to go.  No argument from me.
>
> The JWS spec has admittedly been focused on allowing JSON to be used as
> tokens for OAuth and openID.
>
> Those need to be passed around in a URL safe way,  so we need a
> serialization that supports that.
>
> In Quebec we did touch on alternate serializations that may be more
> suitable for other use cases.
>
> I suspect that signing a manifest/reference is something we should be able
> to support in the JOSE spec.
>
> Finding the best way to accommodate they without complicating the simpler
> cases is something that should be explored.
>
> John B.
>
> On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:
>
>
>
> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[e-mail]> wrote:
>
>> In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url
>> encoded blobs.
>>
>> In most cased we intend for those to be JSON, but nothing prevents this
>> from being used with XML similar to the failed SAML simple sign.
>>
>> With JSON payloads we really wanted to avoid touching the payload.
>>  Inserting elements, canonicalization  and other things that touch the
>> payload are highly problematic.
>>
>
> I really want to avoid C18N as well. The problem is how to do it.
>
> If the data object is small it is no big deal base64 encoding it and
> storing it as an attribute.
>
> But if the data object is larger (XML document, image, etc.) then some form
> of indirection is going to be necessary. For example take the digest of the
> data and sign that or if multiple objects are involved some sort of manifest
> scheme.
>
>
> I really don't want to have to BASE64 a multimedia stream. So I think I am
> going to need some MIME like packaging scheme that allows us to send a JSON
> structure with attachments. I think that is going to be a very common
> requirement for others as well and I would like that to be a part of the
> standards toolkit rather than have to re-invent it for each protocol.
>
>
> Another very common corner case that is related is how to take a standard
> data object such as a JPEG, sign it and then attach the signature inside the
> data object.
>
> The blunder committed in XML Signature was to use XPath for that which
> introduced a mechanism for arbitrary transformations - yuk!
>
> I really don't want to specify the precise means of embedding signatures in
> various media types but I certainly need an approach that makes it possible
> to use the spec as a basis for doing that.
>
>
> --
> Website: http://hallambaker.com/
>
>
>


-- 
Website: http://hallambaker.com/