On Tue, Jun 22, 2010 at 2:28 AM, Ben Laurie <b...@google.com> wrote: > 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? >
webfinger is for resolving email-like identifiers. Sometimes, that's all you have (e.g., when you have a login box and users insist on typing email addresses into that login box). But we can make things much simpler if the identifiers that need to be resolved are already http(s) URLs (and we don't assume that they need to resolve to display-able HTML). If we're in that situation (and I'm arguing that here we can be if we want to) then "discovery" basically disappears as a problem - you simply fetch the URL and you have the information you want right there. Dirk. > > >> 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
