On 2010-07-10, at 1:42 PM, David Recordon wrote: > On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > On 2010-07-10, at 1:21 PM, David Recordon wrote: >> On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > >>> * the signature comes before the payload >>> * we used the key 'algorithm' instead of 'alg' and 'expires' instead of >>> 'not_before' >> >> Good points to add to the discussion. Perhaps you would articulate why you >> made those choices? >> >> I think Naitik talked about the signature coming before the payload in this >> thread. Through implementations we've found that lsplit is easier in some >> languages. > > I think having an envelope as the first blob enables a parser to know what to > do with the rest of the blobs, and that this trumps the mionor lsplit > argument. > > And we think that adding an envelope creates unnecessary complexity for both > server and client developers for the signature use cases.
Obviously anything besides what you need for your use case adds complexity. The question is: are you willing to accept some complexity so that it works for use cases than yours? If not, then perhaps you should just define your own signature mechanism. I don't see parsing two base64url encoded JSON strings as being that much more complex than parsing one. Repeating one step that then enables extensibility for the future as to how to parse the rest of the token, and enables the same code to look at encrypted tokens in addition to tokens that have only been signed. The alternative is the client and server have to know ahead of time what is being sent and can't mix them -- that adds complexity later on. -- Dick
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
