On the topic of relay protection we added "jti" (JWT ID) Claim to the JWT spec so that we would have a claim to use for replay detection on assertions.
In the Connect profile of the JWT assertions spec for client authentication we did make it required for the sender to include it, but gave some flexibility to the server in interpreting it. For self signed assertions used as client authentication I think allowing the server to detect replay attacks is probably a good thing. For authorization assertions the issues get more complicated and, probably shouldn't be locked down at this layer. There may be reasons for not detecting replay for authentication as well that I am not aware of. I suspect that as Connect did applications using these specifications will profile them to include replay protection if required. I am bothered by it not being required in these specs. I do remember a discussion on this, but would have a hard time pointing to it now. John B. On Oct 21, 2014, at 6:33 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-assertions-18: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks for adding the MTI algorithms to the saml and jwt docs > to clear the discuss I put on this one. > > I didn't check the comments below. > > - general: What prevents/detects conflicts between the oauth > scope parameter and the saml or jwt equivalent? Are there > other bits of replicated data that could be the basis for a > vulnerability? > > (The comment below applies for both saml and jwt so > putting it here.) > > - The no replay protection issue was debated in the > WG wasn't it? (I think I recall it, not sure.) Seems like a > bad plan to me to not require at least implementation of > replay protection in the AS so that it can be turned on. Can > you point me at where that was discussed on the list? > > > _______________________________________________ > 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
