On Mon, Jun 21, 2010 at 4:18 AM, 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? >
Yes. > > "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? Yes. > But I'd prefer a not_after instead. > Either way is fine with me. I picked token_lifetime b/c it tends to take up a little less space than a not_after, but I don't feel strongly about it. > > What is a Service Descriptor? Is this something to do with webfinger, > or something else? > Something else. I'm proposing that an OAuth Client be identifiable by a URL. You resolve the URL, you get everything you need to know about that Client. Simpler than webfinger. > 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". > Right. Any suggestions what RSA-SHA256 should specifically refer to? If I stick that into a Signature.getInstance() call in Java, it returns _something_. Any idea what that is? I'd like say that whatever that is is what I 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"? > What would you say is the advantage of public-key signatures over shared-key signatures? I do want to point out that this proposal includes public-key signatures, and therefore brings to advantages to the table. > > "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. > MITM wins while the token is valid as per not_before and token_lifetime (or not_after). > Why is body_hash optional? > Maybe some Clients/PRs don't care? I remember that in OAuth 1, we couldn't ever get agreement on what to do about POST body signing, so I made it optional. I'm not going to stand in the way if people want this to be required. > > > 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. > Oops - sorry. :-) I'll try to do a revision later tonight... Thanks for the feedback! Dirk. > > 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
