On Mon, Jun 21, 2010 at 6:22 AM, Nat Sakimura <sakim...@gmail.com> wrote:
> Hi Dirk, > > In addition to Ben's questions, I have another. For X.509, you seem to > be using DER. How do you express the entire certificate chain using > DER? > (With PEM, you can just concatenate ... ) > Good question: strawman answer: Don't put cert chains into the server info document. The verifier hopefully fetches the server info document over SSL, and can verify all the cert chains it wants in the SSL layer. We simply need a public key in the server info document. The option to include a certificate is purely there in case it's easier for you to generate an X.509 cert than a Magic Key. For example, if you already have concatenated PEMs, throw all but the first away, remove the newlines, prepend "X509." and you have a valid representation of a public key, as far as JSON Tokens are concerned. What do you think? Dirk. > And here is some comments: > > If body_hash is not used, it seems it is just doing the client > authentication via asymmetric crypto. > This is a valid use case, and actually is quite nice. I think this is > the main use case. > > If we wanted to make sure that the request itself is not tampered, we > need to sign the body. > For this, I somehow feel that Magic Signatures is more interoperable > since it actually sends the armored ASCII strings with it. > > =nat > > > > On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie <b...@google.com> wrote: > > On 21 June 2010 08:04, Dirk Balfanz <balf...@google.com> wrote: > >> Hi guys, > >> I think I owe the list a proposal for signatures. > >> I wrote something down that liberally borrows ideas from Magic > Signatures, > >> SWT, and (even the name from) JSON Web Tokens. > >> Here is a short document (called "JSON Tokens") that just explains how > to > >> sign something and verify the signature: > >> > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > > > "signature is a base64-encoded string of the signature bits." should > > be websafe-base64? > > > > "the current time is not after the expiration time of the token > > (defined as not_before + session_length)" should be not_before + > > token_lifetime, right? But I'd prefer a not_after instead. > > > > What is a Service Descriptor? Is this something to do with webfinger, > > or something else? > > > > In the HMAC keys section you describe the keys as symmetric, which is > > strictly accurate, but more normally called shared keys for this use. > > > > Obviously you'll need to be a bit more specific about what you mean by > > "RSA-SHA256". > > > >> Here is an extension of JSON Tokens that can be used for signed OAuth > >> tokens: > >> > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > > > As you know, I hate the term "non-repudation". Can't you just call it > "signing"? > > > > "Protection against leaked authentication tokens: Protocols such as > > OAuth2 use bearer tokens, which may leak when used over non-SSL. > > Signing requests when using bearer tokens lets the recipient of such a > > request verify that the issuer of the request was a legitimate holder > > of the bearer token." - only true if you make the checking of the > > nonce a MUST instead of "may". And even then, MitM wins, of course. > > > > Why is body_hash optional? > > > >> Here is a different extension of JSON Tokens that can be used for > 2-legged > >> flows. The idea is that this could be used as a drop-in replacement for > SAML > >> assertions in the OAuth2 assertion flow: > >> > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > > > You use the abbreviation AS before the full name Authorization Server. > > > >> I also have started to write some code to implement this as a> > proof-of-concept. > >> > >> Thoughts? Comments? > > > > Nice. > > > >> Dirk. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
