On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes <r...@ipv.sx> wrote: > > > 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." >
I'll add the suggested text. > > 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? > > It was discussed but it's not simple for reasons I've tried to articulate many times. Note that the specific profiling or usage of these specs can constrain or dictate the values of this and other the things that needing out of band negotiation and can be more in the spirit of the Internet to the extent that they define dynamic exchange/discovery/registration/etc. of required information. But these little documents need to fit into such larger contexts not try and define them. > --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
