On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <bcampb...@pingidentity.com> wrote:
> 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 > Sigh. "Negotiate it out of band" is a terrible, non-scalable, not-in-the-spirit-of-the-Internet answer. But I guess I might clear on this if you could add something like the following: "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings to be used as the Audience for a given Authorization Server must be configured out-of-band by the Authorization Server and the Issuer of the assertion." But is there seriously no answer that the WG could agree on? This seems like it should be a pretty simple question. Was it even discussed? --Richard > 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
