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 <[email protected]> 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 <[email protected]> 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/
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
