On 22 June 2010 02:14, Dirk Balfanz <balf...@google.com> wrote: > > > 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.
I think there are a couple of other places that also need this change. >> "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. not_after is in line with X.509, and also means implementations are a few characters shorter :-) >> 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. Why? What's wrong with 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. RSA in Java Signature means a PKCS#1 signature (see http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#Signature). Of course, there are actually two PKCS#1 signature schemes, and the Java docs are quite unclear about which they use, but reading between the lines, I'd say that "SHA256withRSA" (presumably what you meant by "RSA-SHA256"?) yields a PKCS1_v1_5 signature (what they call RSASSA-PKCS1_v1_5) and "SHA256withRSAandMGF1" yields an RSASSA-PSS signature, which is recommended for new applications. >> > 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. Well, the advantages are that a) the signature cannot be forged by the verifier (assuming no key leakage). b) verifying key distribution is easier (since it is public). I don't know of a short way to describe this other than "public key" or "asymmetric". >> "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). Right. >> 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
