- From: peter williams <home_pw@msn.com>
- Date: Tue, 22 Feb 2011 15:22:09 -0800
- To: "'Dan Brickley'" <danbri@danbri.org>, "'WebID XG'" <public-xg-webid@w3.org>
Makes perfect sense to me. Once one expresses the X.509 signature macro as json signature, one has json certs (and any other signed type). Its not much of a step more to then do json-based ssl handshakes - since its just a msg exchange protocol. But one notices that they are being sensible, but not arguing against the actual infrastrcuture that exists in billions of PCs : X.509 certs in their funky old format, and managed by the APIs that already exist (for hierarchical trust, peer trust etc). There is migration strategy towards native json certs (if they ever happen). First focus on what matters : the json signature [macro] for arbitrary types/values Let's remember, that this is in the tradition of the WRAP token - the attempt to dumb down the SAML assertion to it can be easily consumed by a restful webservice, built out a bit of javascript running in a page frame perhaps (yes page as service, not consumer...). Whereas SAML token essentially require stateful sessions, folks want for REST a lightweight token that can be evaluated each presentation (usually because its HMAC signed) Now contemplate a variant of webid protocol that does NOT use SSL client authn service delivered by the transport socket, up-delivered to the web page by a javascript socket. But, it continues to use the client authn procedure of a SSL handshake msg exchange formulated and exchanged between javascript layer 7 entities that do their own crypto and own ssl msg formatting (coded in json syntax, vs the old netscape presentation format). Would we care? Its still client authn Its still an https (using json-embodiment of ssl) pickup Its still a foaf card in some notation (RDFa, or some json encoding of the triples) Im quite excited. Presumably a json value can be a string, that conveys javascript. Ive wanted the activeCert for years. -----Original Message----- From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Dan Brickley Sent: Tuesday, February 22, 2011 2:58 PM To: WebID XG Subject: Fwd: [woes] Background on JSON Web Tokens (JWTs) Did this one come past already? http://self-issued.info/docs/draft-jones-json-web-token.html Dan ---------- Forwarded message ---------- From: Mike Jones <Michael.Jones@microsoft.com> Date: 22 February 2011 23:45 Subject: [woes] Background on JSON Web Tokens (JWTs) To: "woes@ietf.org" <woes@ietf.org> In preparations for our discussions in Prague, I wanted to give some context for the JSON Web Token (JWT) spec. JWT (pronounced like the English word “jot”) is a simple, compact JSON based token format designed for use with OAuth, OpenID, and other emerging specifications. We are explicitly not proposing an equivalent to CMS/PKCS7 - just a simple compact token representation and similarly simple and compact JSON-based signing and encryption functionality. A new draft of the JWT spec where the token format is cleanly separated from the signing algorithms, and where an encryption capability is also added, will be published before Prague. Best wishes, -- Mike _______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes
Received on Tuesday, 22 February 2011 23:22:43 UTC