Or to add another link for the rest of us: http://tools.ietf.org/html/draft-jones-json-web-encryption
I found the presentation to be a little sketchy. The table is difficult to parse. I think that the table is constraining how you describe the parameters, and I'm concerned that underspecification here will hurt. The second and third columns don't seem to add much over the description (the second column is all "string"). I'd suggest that you give each parameter a numbered section. That way, they appear in the TOC. The x5u parameter identifies what exactly? Is it the URI for a resource that, upon retrieval (e.g., HTTP GET), produces an X.509 certificate (chain)? I think that's what you mean. The example seems to use base64url encoding, which seems pointless. "Utilizing TLS" also needs to be expanded. You obviously need to ensure that the authority providing the resource is authenticated and that the representation you retrieve is free from modification, so say that. The "typ" parameter seems a little underspecified. The epk parameter isn't a string by its description, though the table indicates that it is. ...unless you wanted to base64url encode the JSON object. The alg and enc parameters use StringOrURI as their definition. There are no URIs defined for either. I suspect that there is something in there you are wanting to get at, but I recommend that just "String" is sufficient. After all, someone is going to have to decide if "alg": "http://foo"; is equal to "alg": "HTTP://FOO" and I don't want to have to be that guy. Saying that you character-wise compare the strings for equality is really, really good. That doesn't preclude the definition of a scheme where URIs are used to prevent collisions in the namespace, but I suspect that your existing text on public/private use of codes is sufficient. BTW, I like your decision to make all parameters mandatory. This is less a concern with encryption as it is with signature, but it seems like it's better to be consistent across the two. --Martin On 2011-09-07 at 14:37:56, Mike Jones wrote: > I'm pleased to announce the publication of the first draft > <http://self-issued.info/docs/draft-jones-json-web-encryption-00.html> > of the JSON Web Encryption (JWE) > <http://self-issued.info/docs/draft-jones-json-web-encryption.html> > specification. It enables JSON-based encryption of content in a > parallel manner to how the JSON Web Signature (JWS) <http://self- > issued.info/docs/draft-jones-json-web-signature.html> > specification enables JSON-based signing of content. > > My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe > Hildebrand for helping make this initial version a reality! > > The specification is available at these locations: > > * > http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption- > 00.t > xt > > * > http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption- > 00.x > ml > > * > http://self-issued.info/docs/draft-jones-json-web-encryption-00.html > > * > http://self-issued.info/docs/draft-jones-json-web-encryption-00.txt > > * > http://self-issued.info/docs/draft-jones-json-web-encryption-00.xml > > * > http://self-issued.info/docs/draft-jones-json-web-encryption.html > (will point to new versions as they are posted) > > * > http://self-issued.info/docs/draft-jones-json-web-encryption.txt (will > point to new versions as they are posted) > > * > http://self-issued.info/docs/draft-jones-json-web-encryption.xml (will > point to new versions as they are posted) > > * > http://svn.openid.net/repos/specifications/json_web_encryption/1.0/ > (Subversion repository, with html, txt, and html versions available) > > > > I also posted about this at http://self-issued.info/?p=538 > <http://self-issued.info/?p=538> . > > > > -- Mike > > _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
