Thanks for your review and feedback on this one too, Richard. Replies are inline below...
On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes <r...@ipv.sx> wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: 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-jwt-bearer/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As with draft-ietf-oauth-assertions, the requirement for an "aud" claim > seems entirely unnecessary. Holding this DISCUSS point pending that > discussion > and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify > the Authorization Server"? Does the specified <Audience> need to match > the > entire URL of the relevant OAuth endpoint? Just the origin? Just the > domain? > Does the URL need to be canonicalized? > > No c14n, as it says, "... compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986." Basically the AS is at liberty to determine how it identifies itself. Some guidance on using the token endpoint is provided but it's ultimately up to the AS (or the larger deployment in which the AS exists). The acceptable value is one of a few bits of information that must be exchanged for this profile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 Some more explanation/discussion of it is in the middle(ish) of this reply to a similar comment from Stephen Farrell http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "MAC" > Yep. > > Both this and the SAML document could save a lot of bits by just being > subsections of the -assertions document. > The structure and relationship of the documents was decided on by the WG nearly three years ago. There is some duplication but it's believed to be more approachable this way - particularly for those implementing just one assertion type.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
