Thanks for your review and feedback on this one too, Stephen. Replies are inline below...
On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Putting one discuss here rather than one on each of the other > docs. We can fix that as appropriate after we chat. Where are > the MTI signature and mac algs for these specified? If those > can be tracked back via the SAML and jose docs that's fine, > but I'm not sure if they are. > > I believe they can be. JOSE Implementation Requirements for JWS are in the table in JWA §3.1 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1 And there's §5 SAML and XML Signature Syntax and Processing http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 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.) > Scope is not represented inside the assertion (JWT or SAML) so there's no potential for conflict. > > - 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? > > I described my recollection and justification of the optionality of one particular type of replay protection in a message yesterday: http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html It's worth mentioning that there are different ideas of what replay is and what to protect against. The one particular type mentioned above is pretty narrow - checking to see if the same token is used again at the same relying party. There are other kinds of more sinister replay which are prevented by properly audience restricting the assertions. The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere where it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
